Ich denke schon das ich nach role=outer abfragen kann, da folgendes funktionieren soll:
Zum Beispiel:
./osmfilter europe.o5m --parameter-file=my_parameters >line_1.o5m
Datei “my_parameters”:
-v
–keep=
–keep-relations=
all
route=bus
line=1
–drop-tags=
operator=
direction=
–out-o5m
Da Gebäude nach folgendem Schema aufgebaut werden:
Muss man eigentlich auch nach role abfragen können.
Nur wie …???
garnicht 
Gruss
walter
Ich glaube, Du verrennst dich…
Das hilft Dir doch noch nicht weiter, wenn Du da die outer rausfilterst. In der Relation stehen alle Linien drin, die das Gebäude beschreiben. Du brauchst alle davon, die “outer” um den äusseren Rand zu malen und die “inner” um den Innenhof aus der von den “outer” beschriebenen Fläche auszuschneiden.
Und Du brauchst ein Stück Software, das Dir aus den vielen Linien (den outer und den inner) etwas zusammenbaut, was Dein GIS als “Polygon mit Löchern” akzeptiert. Das ist nicht ganz einfach, dazu muss man die inner und outer auseinanderdröseln, in die richtige Reihenfolge bringen, ggf. in die richtige Richtung drehen und zusammensetzen. Werkzeuge dazu kenne ich keine, aber ein paar wurden hier genannt.
Grüße, Max
Genau!
Ich habe nun QGIS installiert. Aber dadurch ändert sich nicht das Problem!
Die Linie die als role=inner attributiert wurde liegt nun als Fläche über der anderen Fläche. Ja, man muss Polygone mit Löchern erzeugen und das automatisch in dem gesamten Datensatz. Also muss ich nach irgendwas filtern um sie zu clippen.
Eine andere Möglichkeit wäre, den Innenbereich transparent darzustellen, aber auch dann muss ich nach dem Attributwert “inner” abfragen können.
Sobald ich aus QGIS die Shape Dateien exportiere, gehen die Relationen flöten.
Wie macht ihr das?
Kann mir nicht vorstellen, dass ich der Erste bin, der nur das eigentliche Gebäude als Fläche haben möchte. Egal ob ArcGIS oder QGIS … von mir aus filtere ich es auch automatisch in QGIS … nur wie???
Hmm, also QGIS scheint tatsächlich MPs nicht zu unterstützen
Du schriebst aber etwas über FME. Dort steht
Und mir hat mal jemand Shape → OSM damit umgewandelt, inkl Löcher → MP
Ich kann am Wochenende mal schauen, ob Global Mapper eine Umsetzung unterstützt. In der Beschreibung steht nichts von MPs, nur
Die meisten hier, die sowas brauchen, z.B. zum Rendern, haben vermutlich eine eigene PostGIS-Datenbank. Vielleicht kann man auch ein GIS dran anschliessen…
Ich würde entweder eine DB im osm2pgsql-Schema aufsetzen. Oder alternativ, falls es unbedingt Shapefiles sein sollen und ich keine Lust auf DB hätte, würde ich einen freundlichen Datenbankbesitzer so lange mit Gummibärchen, Schokolade oder Geld überhäufen, bis er
pgsql2shp -f gebaeude -u Username -P Passwort Datenbankname "select osm_id,name,amenity,building,st_transform(way,4326) from osm_polygon where building is not null and st_contains((select way from osm_polygon where osm_id=-62428 order by st_area(way) desc limit 1),way);"
zip gebaeude.zip gebaeude.*
tippt und mir dann gebaeude.zip schicken lassen. Natürlich mit einer anderen Grenze (Relation 62428 ist das Grenzpolygon für München). Bei mir dauert das 2 Kaffee lang und wirft mir 9 MBytes Häuser und Höfe aus.
Grüße, Max
@Thomas
Global Mapper habe ich leider nicht, es würde mir also leider nicht helfen.
Ich weiß das es mit FME geht, aber nicht wie …
In FME wird eine relation_multipolygon beschrieben, in der die Zuweisung über die ID’s zu den einzelnen Linien erfolgt.
Problem:
Ich kenne nicht den richtigen Transformator der mit daraus wieder eine Geometrie macht.
Hast du noch Kontakt zu demjenigen der dir geholfen hat?
@Max
Kennst du jemanden der eine DB von ganz NRW hat, den ich füttern kann? 
Ich hab eine Wegwerfdatenbank für sowas: Einmal importieren, nie um update oder gar backup kümmern, spielen und irgendwann wieder löschen. Kann ich nur empfehlen, das läuft recht wartungsarm, wenn man es das erste mal installiert hat…
Schau mal, ob Dir diese Gebäude reichen (205MB, aus dem Geofabrik/NRW-Extrakt von heute)
Da steckt alles drin, was “building=irgendwas” ist, also auch “building=no”, “building=Platz des ehemaligen Güterbahnhofs aus dem 11. Jahrhundert” oder was die Leute da sonst so reinschreiben.
Es steckt nichts drin, wo kein building gesetzt ist. Kirchen hab ich noch zusätzlich dazugenommen, weil die sind leider oft nur mit “amenity=place_of_worship” eingetragen ohne das “building=yes/church/…” zu erwähnen. Kraftwerke fehlen im Shapefile. Die haben oft nur “power=generator”, auch wenn sie Häuser sind (bei fehlendem builing=* müsste man da noch Kraftwerke aus Beton von Glasplatten auf der Wiese unterscheiden, das war mir zu mühsam…)
Attribute sind “osm_id, name, amenity, tourism, shop, building, addr:street, addr:housenumber, addr:postcode, addr:city”, sag bescheid wenn du mehr brauchst.
Grüße, Max
Edit: Kirchen dazugenommen, ein paar Attribute mehr reingeschrieben
Warum das Übel nicht an der Wurzel kurieren, indem man klare Strukturen schafft, anstatt an den Symptomen herumzudoktern? Ein weiteres Beispiel für den Multipolygonwahnsinn.
Diese Art von Mapping ist weder wartungs- noch kundenfreundlich. Und was hat es für Vorteile? Mir fallen keine ein. Mit der Einführung dieser eierlegenden Wollmilchsau hat sich OSM keinen Gefallen getan.
Genervte Grüße
Franz
Sooo, ich habe es mit FME geschafft 
Möchte aber von euch bitte noch wissen wofür die Relationen
Welche Objekte gehen mir verloren, wenn ich die beiden Relationen nicht beachte? Möchte nicht wieder irgendwann feststellen das mir Geometrien fehlen. Die fehlenden Gebäude sind auch nur durch Zufall aufgefallen.
Gruß
Dirk
Edit:
Es gibt sogar noch eine dritte Relation, die keine Namenserweiterung trägt.
Wie der Name schon sagt:
http://wiki.openstreetmap.org/wiki/DE:Relation:restriction
http://wiki.openstreetmap.org/wiki/DE:Relation:route
Ok, vielen Dank für die schnelle Antwort.
Restriction interessiert mich nicht und wenn bei “highway” alle Attribute für die Klassifizierung (motorway, primary usw.) vergeben sind ohne über die Relation gehen zu müssen interessiert es mich auch nicht.
Die Relation der Multipolygone hätte mich auch nicht interessiert, wenn nicht das Attribut “building” nur dort versteckt wäre.
Einige Gebäude verstecken sich noch in den Klassen “shops”, “leissure” usw… Erwartet mich dort noch eine Überraschung oder habe ich alle wenn ich nach building <> ‘NULL’ AND building <> ‘no’ filtere?
Wofür ist die dritte Relation?
Bei OSM immer 
So spontan fällt mir wie schon gesagt ein:
“amenity=place_of_worship”: Das sind Kirchen, oft steht da ein “building=church” dabei, aber nicht immer. Manche Leute (ich z.B.) stehen auf dem Standpunkt, ein place_of_worship sei dann ein Freiluftheiligtum, aber in der Praxis sind das in der überwiegenden Mehrheit Gebäude, egal was “building” sagt.
“power=generator”: Das ist ein Kraftwerk, und wird oft ohne zusätzliches “building” eingetragen. Passt auch oft, wenn man das als Gebäude ansieht. Allerdings ist ein “power=generator und generator:source=solar” oft einfach eine Wiese voller Glasplatten, die man nicht als Gebäude auswerten möchte.
Eher selten: “man_made=tower”, “amenity=townhall”
Grüße, Max
Ja, so habe ich es auch erlebt. Bei building findet man fast alles … statt “yes” gab es auch schon “zes” und “jes”
Deswegen meine Idee ob es nicht sinnvoll ist, in jeder Klasse (man_made, amenity, power usw.) nach dem Attribut “building” zu suchen und wenn es vorhanden ist mit SQL nach building <> ‘NULL’ AND building<> ‘no’ zu filtern?
Gruß
Dirk
Hallo Dirk
Bei den Knoten gibt es noch building=entrance, heute besser entrance=yes/…
Teilweise gibt es auch building=yes/… an Knoten. Obwohl das nicht wirklich definiert ist kommt das gelegentlich als Erinnerung vor, dass es an dieser Stelle ein Gebäude gibt. Gelegentlich sind auch Ecken von Gebäude versehentlich mit building=yes/… versehen.
Wenn dich Punkte nicht interesseieren, dann musst du das natürlich nicht weiter beachten.
Edbert (EvanE)
Ich würde nicht in allen Schlüsseln nach building suchen, irgendwo hört es ja auch auf.
Kannst ja mal testen: In NRW gibt es 6 Gebilde mit amenity=building (von 2.1 Mio Gebäuden), die haben alle aber auch building=yes/residential gesetzt. Bei man_made sieht es ähnlich aus (da gibts übrigens den interessanten Fall historic=castle. Ob ein historic=castle automatisch ein Gebäude ist, muss man sich überlegen).
Mit “building <> ‘NULL’ AND building<> ‘no’” und ein paar Ausnahmen (vielleicht fällt anderen noch was ein ausser Kirchen und Kraftwerken) solltest Du 99% der Gebäude erwischen. Da ist zwar auch viel eigenwillig getaggtes dabei (building=“Städtische Galerie”), aber vermutlich meint der Ersteller damit fast immer ein Gebäude. 1% sind halt Ausschuss wegen Rechtschreibfehlern, Feld im Editor verwechselt… und werden nicht ausgewertet.
Grüße, Max
Ich werde aus NRW die Gebäude filtern und die Anzahl der Objekte mit deinem Datensatz vergleichen. Werde mich dann wieder melden.
Lieben Dank an alle für die sehr gute Unterstützung.
Übrigens verstehe ich nicht warum eine Relation für manche Gebäude angewendet wird. Wo ist hier der Vorteil, eigentlich total unnötig und umständlich.
Notwendig ist das, wenn nicht die die gesamte Fläche ein Gebäude ist, sprich bei Gebäuden mit Innenhof.
Edbert (EvanE)
Wir haben keinen Datentyp für Flächen mit Löchern. Eigentlich haben wir nicht mal einen Datentyp für Flächen, sondern nur für Linienzüge. Das wird aber ausgeglichen durch ausgeklügelte Schätzungen, ob ein geschlossener Weg einen Weg im Kreis oder den Umriss einer Fläche abbilden soll.
Damit hören unsere Möglichkeiten aber auch schon auf. Wenn wir eine Fläche mit Loch (ein Haus mit Innenhof), machen wollen, müssen wir eine Relation (type:multipolygon) basteln, die aussagt “Weg A ist Aussenmauer, Weg B gehört auch zu diesem Haus und beschreibt das Loch im Gebäude”.
Es ist auch möglich, nur einen Strich hinzumalen und dann in mehreren Relationen zu verwenden. Dieser Strich ist dann Aussenmauer des Gebäudes in der Relation A und gleichzeitig Aussenmauer der Relation B. Der Strich kann aber in seiner zweiten Verwendung auch ein Ufer des Baches sein, an dem das Haus steht. Ein Haus das durch so eine Relation beschrieben wird hat dann mehrerer Aussenmauern (die member mit role=outer in der Relation) und vielleicht auch noch ein paar Mauern, die die Innenhöfe beschreiben (die role=inner)
Der erste Fall mit Innenhof ist häufig anzutreffen, der zweite ist bei Häusern eher selten, aber möglich.
Weitere Argumente für und wider diese Multipolygonrelationen findet man im Thema “Multipolgonwahnsinn - oder: Durchblick war gestern!” hier nebenan. Bebilderte Beispiele gibts im Wiki.
Ja, das habe ich auch gemerkt. Dafür muss man aber nicht unbedingt Multipolygone verwenden. Ein Fremdschlüssel, der auf weitere Linien die zu einem Gebäude gehören verweist, würde genügen.
Na ja, warum gibt es eigentlich noch die Klasse cycleway? Die Radwege sind doch eigentlich in highway=cycleway hinterlegt? Wieso treffe ich also auf eine gesonderte Klasse?