Geofabrik building-Shape unvollständig, was tun?

Moin,

hier mal meine Workzone in QGIS, OpenStreetMap und building-Shape: http://i.imgur.com/qiOkSCb.png
Da fehlt so einiges an Gebäuden. Grund scheint zu sein, dass einige Gebäude als Multipolygon eingetragen sind.

Liegt der Fehler nun bei der Geofabrik (so sind die Shapes ja sicher nicht gedacht!) oder sind die Daten falsch erfasst? Vielleicht muss ja nicht nur die Relation, sondern auch alle Wege das Attribut building=yes bekommen? So ganz lese ich das aus dem Wiki http://wiki.openstreetmap.org/wiki/DE:Buildings nicht heraus. So wie es jetzt ist kann der Renderer wohl damit umgehen, aber sind die Daten so richtig erfasst? Oder muss das die Geofabrik noch mal ran?

LG,

-moenk

Die (kostenlosen) Shapefiles der Geofabrik enthalten keine Multipolygon-Flächen. Die einzelnen Ways brauchen kein Attribut, nur die Relation.

Als Abhilfe fällt mir nur ein, sich eine osm2pgsql-Datenbank aufzusetzen (kann ja auch eine Wegwerf-Datenbank sein), und mit pgsql2shp seine eignen Shapefiles zu erzeugen (hat zumindest hier ganz gut geklappt).

Grüße, Max

maxbe,

damit sind die Geofabrik-Shapes aber relativ unbrauchbar - Multipolygone/Relationen sind offensichtlich ein besonderer Fetisch einiger Mapper. Den Umweg über die DB möchte ich den Studenten gern ersparen, vielleicht fällt ja jemand noch eine andere Quelle für Shapes ein, wo alle Gebäude drin sind? Muss ja gar nicht tagesaktuell sein.

LG,

-moenk

Da gebe ich dir recht.

Ich halte die Arbeitsweise, bei Multipolygonflächen die Eigenschaften der Outer-Fläche in die Relation zu packen für grundsätzlich falsch und im Vergleich zu anderen Relationstypen auch für unlogisch. Denn so habe ich taglose Flächen, die bei den Geofrabrik-Extrakten nicht drin sind…
Aber das Thema hatten wir schon im Großen Multipolygon-Beitrag.

Mit welchen GIS sollen die Daten verarbeitet werden?

Sven

Mir hatte Frederik hatte mir damals empfohlen die Dinge mit Osmonium aus den OSM Dateien zu rechnen. Allerdings hatte ich nie wirklich einen Einstieg gefunden und daher das nicht weiterverfolgt.

Streckenkundler,

Studenten möchten Gebäude aus Berlin haben - nachdem der Senat sein WFS für Hausumringe nicht gebacken bekommt (es existiert, funktioniert aber zumindest derzeit nicht), war mein nächster Tipp OSM. Natürlich kann ich das vorbereiten, aber das ist nicht Sinn der Sache. Es muss doch irgendwo Gebäude aus der OSM als Shape schon fertig für QGIS zum Download geben. Ich mein auch dass bei den Geofabrik-Downloads früher mal die Relationen mit negativer ID mit dabei waren.

LG,

-moenk

Na QGis kann doch Elemente direkt aus einer *.osm-Datei lesen. Gut, in der der Geofabrik steckt dann erst mal ganz Berlin drin… bekommt man da nicht die Gebäude raus? und dann als shape exportieren?

fragt Sven

Mit Osmium, vermute ich? Ich habe das auch mal durchexerziert, das Ergebnis war durchaus brauchbar. Ich habe das Vorgehen auf meiner Wiki-Benutzerseite festgehalten. Die Software ist aber wohl nicht unwesentlich verändert und weiterentwickelt worden seitdem. Ich denke aber, die Multipolygon-Unterstützung als ein zentrales Feature ist sicher erhalten geblieben.

Ansonsten glaube ich neulich etwas von einem neuen gdal-Tool zum Konvertieren von OSM-Daten gelesen zu haben, keine Ahnung, wie es da mit Multipolygon-Unterstützung aussieht.

Hallo moenk

QGIS kann doch OSM-Daten direkt improtieren. Warum wird dieser Weg nicht genutzt?

Klar muss man dann ein wenig darüber nachdenken, welche Daten man will/braucht (Adresse, shop/craft/…) und wie sie in OSM erfasst sind (geschlossener Weg, Relation). Umriss ist klar aber was ist mit Adress-Knoten oder Eingängen? Ebenso müsste man sich dann mit allfälligen Fehlern wie zum Beispiel nicht geschlossenen Umrissen beschäftigen.

Natürlich wäre ein perfekter Auszug einfacher. Aber vielleicht ist gerade die Erfahrung, dass in der GIS-Welt nicht nur perfekte Datensätze existieren, wertvoll für die Studenten.

Edbert (EvanE)

Hallo Sven

Solange man jeweils geschlossene Wege als inner und outer hat, wäre das in der Tat nicht zwingend notwendig. Aber sobald die Ringe aus mehr als einem Weg bestehen (z.B. große Landuse-Flächen), sehe ich keine andere Möglichkeit, als die Taggs an das Multipolygon zu setzen.

Edbert (EvanE)

ja, das ist auch der einzigste Fall, wo es nicht anders geht. Das ist klar. Sven

Als ich das letzte Mal nachgesehen habe, konnte das qgis-osm-plugin keine Multipolygone auswerten. Ist aber schon ein halbes Jahr her, vielleicht gibt es da Neuigkeiten…

Bei Geofabrik gibt es doch auch osm-Files. Da ist alles drin.

klaro, aber das sind Rohdaten. Da muß man erst aus den gestückelten Multipolygonen echte Flächen machen - und das ist net so einfach.
osm2pgsql erledigt das so nebenbei, daher auch der Vorschlag mit der Temp-DB. Man wird aber kein “Nicht-OSM-Programm” finden, das mit den OSM-spezifischen MP zurecht kommt. Aber schon sind wir wieder beim Thema OGC-Standard :frowning:

Gruss
walter

Ich könnte da mein Java-Programm (open-source) anbieten. Alles mit type=building und role=“outer” wird damit zu einfachen Polygonen aufgeloest. Damit sind Innenhöfe oft unsichtbar, weil Linie ohne tags. Manche Gebäude haben noch role=“part” oder statt outer outline etc., die zahllosen (relativ seltenen) Varianten berücksichtigt mein Programm nicht. Wie vollständig soll das Ganze denn sein?

Ebenso wird landuse=residential etc. aufgelöst. Innenflächen sollten aber aus einem Linienzug bestehen. Nur zurück, vom einfachen Linienzug zum Multipolygon geht nicht. Man könnte das Geänderte nicht wieder auf osm speichern.

Getestet wurde das Programm bisher auf Linux.

Naja, das ist jetzt etwas hart ausgedrueckt, eine ganze Menge Leute scheinen sie schon gebrauchen zu koennen :wink:

Die kostenlosen Shapes werden derzeit naechtlich mit einem sehr einfachen und schnellen Programm (osm2shp) ausgerechnet, das keine Multipolygone kann. Die ordentliche Verarbeitung von Multipolygonen wuerde deutlich laenger (oder mehr Speicher) brauchen, so dass wir nicht mehr jede Nacht den ganzen Planet durchackern koennten.

Daher handhabe ich das im Moment so, dass ich kostenlos halt das rausgebe, was sich schnell und einfach machen laesst, und verkaufen tu ich das, was etwas muehsamer ist - und fand das immer einen einigermassen fairen Kompromiss aus Nutzen-fuers-Projekt und Nutzen-fuer-die-Firma.

Ich sehe natuerlich auch, dass mehr und mehr simple Dinge mit Multipolygonen gemappt werden und dadurch aus den kostenlosen Shapes rausfallen, das kann natuerlich nicht immer so bleiben, sonst werden die echt zu unbrauchbar.

Ich moechte mittelfristig die kostenlosen Shapes umstellen auf ein Datenschema, das zu dem der kostenpflichtigen Shapes kompatibel ist (dokumentiert in http://www.geofabrik.de/data/geofabrik-osm-gis-standard-0.6.pdf)) . Die kostenpflichtigen haben derzeit deutlich mehr (und andere) Layer als die kostenlosen und ausserdem eine feste Feature-Auswahl - d.h. alles, was ich nicht explizit auswaehle, kommt auch nicht ins Shape, waehrend bei den kostenlosen derzeit z.B. alles mit einem highway-Tag ins Strassen-File kommt, egal ob da “residential” oder “schotterpiste” steht. Ich werde dann vermutlich bei den kostenlosen Shapes eine Teilmenge der Layer anbieten - also etwa Strassen, Gebaeude, Landuse, wichtige POIs - und die kostenlosen Shapes auch nur noch alle paar Tage neu ausrechnen statt taeglich, und dafuer gibt es dann aber auch ordentliche Multipolygone.

Wenn diese Aenderung kommt, dann gehen allerdings alle Anwendungen kaputt, die sich auf die alte Shapefile-Struktur verlassen haben. Ich fuerchte, da gibt es recht viel, wovon ich gar nichts weiss :wink: eventuell muss ich dann eine Zeitlang beides parallel anbieten, oder einen Satz ogr2ogr-Commandline-Befehle, mit denen man die neuen in die alte Struktur umrechnen kann oder so.

Das ist immer ein bisschen schwer - ich moechte ja schon, dass der Downloadserver wirklich nueztzlich ist und fuer sowas wie Moenks Studentenprojekt einfach eingesetzt werden kann. Was auf dem Downloadserver ist, darf keine “Crippleware” sein, daher muss das mit den Multipolygonen jetzt bald mal richtig gemacht werden. Auf der anderen Seite muss ich aus wirtschaftlichem Interesse schon auch irgendeinen Anreiz fuer diejenigen mit Geld schaffen, mir dann und wann ein Shapefile abzukaufen, d.h. irgendwas muss am bezahlten Shape schon besser sein als am kostenlosen. Aber ich denke, mit einer Kombination aus “mehr Layer” und/oder “mehr Attribute” und/oder “aktueller” koennte das funktionieren - wenn ich mit dem Bezahlangebot nur die 2-3% anspruchvollsten Nutzer abschoepfe und den anderen 97%-98% fuer ihre Zwecke ausreichende kostenlose Files zur Verfuegung stelle, dann zahlt das schon die Rechnung fuer den Server.

Uebrigens, seit gut einem Jahr sind in den kostenlosen Shapes in Frankreich ueberhaupt keine Gebaeude mehr dabei, weil die da so massiv importiert haben, dass ich irgendwann dachte, das wird mir jetzt zu viel - 90% der Datenmenge in einigen Zipfiles entfielen auf den Gebaeudelayer…

Bye
Frederik

Das ist natürlich verständlich, dass sich die Sache irgendwie finanzieren muss. Ein deutlicher versprochener Mehrwert der kostenpflichtigen shapes ist natürlich deren Routingfähigkeit.

Moin,

um das Thema noch mal noch oben zu holen: Was woodpeck sagt ist völlig nachvollziehbar und verständlich, ich hab mir auch schon gedacht das der Aufwand täglich auch die Multipolygone bereit zu stellen zu hoch wird. Um so mehr an dieser Stelle noch mal Dank an die Geofabrik dass man den Deutschland-Ausschnitt immer frisch herunterladen kann!

Für die Universität haben wir nun einen anderen Weg beschlossen: Es wird einmal im Monat eben diese germany.pbf neu eingespielt (mit osm2pgsql und imposm) und als WFS bereitgestellt: http://maps.geo.hu-berlin.de/ - hier kann man dann mit WFS die Daten ins GIS holen oder sich auch Shapes mit einem von mir erstellenten kleinen und einfaches Windows-Programm herunterladen.

LG,

-moenk

Im englischen Wiki ist dieser Passus gestrichen.
Aus Konsitenzgründen gehören dieses Tags an die Relation.

Ach diese Inner-Outer-Multipolygon-wo-kommt-das-Tag-hin-Disskossion…

[Kopf hängen gelassen]

Ich kenne noch immer keinen logischen Grund warum das so sein soll… Mittlerweile resigniere ich da aber auch… dieses wird mir langsam egal… :frowning:

Einerseits stört es mich daß man so “Wertelose” geschlossene Linien hat [das kann ich mit meinem Grundverständniss von GIS nicht vereinbaren, mit GIS verdiene ich mein Geld].
Andererseits ist es nur extrem nervig, wenn man auf unnötige und fehlerbehaftete MP’s stößt, die gar nicht nötig sind, diese aufzulösen und dann umständlich die Tags wieder an die ehem. Outerlinie zu packen.

Das was ich gelernt habe: ohne einen echten OGC-konformen Datentyp “Polygon” kommen wir nicht mehr drum herum. Es wird allerhöchste Zeit, daß dieser kommt… (die API-0.7-Geschichte kenne ich)

Sven