Geofabrik building-Shape unvollständig, was tun?

moenk · 2013-12-04 12:37:04

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

maxbe · 2013-12-04 13:44:39

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

Last edited by maxbe (2013-12-04 13:45:49)

moenk · 2013-12-04 15:00:30

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

streckenkundler · 2013-12-04 15:26:40

moenk wrote:

damit sind die Geofabrik-Shapes aber relativ unbrauchbar

Da gebe ich dir recht.

moenk wrote:

Multipolygone/Relationen sind offensichtlich ein besonderer Fetisch einiger Mapper.

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

viw · 2013-12-04 16:03:37

moenk wrote:

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

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.

moenk · 2013-12-04 17:13:47

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

streckenkundler · 2013-12-04 17:32:15

moenk wrote:

tudenten 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.

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

g0ldfish · 2013-12-04 17:33:49

viw wrote:

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.

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.

Last edited by g0ldfish (2013-12-05 10:28:32)

EvanE · 2013-12-04 17:47:49

moenk wrote:

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.

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)

EvanE · 2013-12-04 17:53:25

streckenkundler wrote:

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...

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)

streckenkundler · 2013-12-04 18:13:05

EvanE wrote:

streckenkundler wrote:
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...
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

maxbe · 2013-12-04 18:22:34

EvanE wrote:

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

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...

Pepito · 2013-12-04 18:38:19

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

wambacher · 2013-12-04 18:45:59

Pepito wrote:

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

Gruss
walter

Pepito · 2013-12-05 12:42:18

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.

woodpeck · 2013-12-06 01:40:02

moenk wrote:

damit sind die Geofabrik-Shapes aber relativ unbrauchbar

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

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- … d-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 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

viw · 2013-12-06 06:59:00

woodpeck wrote:

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.

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.

moenk · 2015-03-02 13:00:50

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

RadFr · 2015-03-02 18:04:28

streckenkundler wrote:

EvanE wrote:
streckenkundler wrote:
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...
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

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

Last edited by RadFr (2015-03-02 18:05:22)

streckenkundler · 2015-03-02 18:30:21

RadFr wrote:

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...

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

Last edited by streckenkundler (2015-03-02 18:31:13)

viw · 2015-03-02 19:44:53

streckenkundler wrote:

RadFr wrote:
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...
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].

Das kommt aus der Rücksicht auf die Auswerter. Ein Programm welches keine Ahnung von Multipolygonen hat würde wenn die Informationen am Weg stehen daraus fertige Polygone machen ohne die Löcher auszustanzen.
Auch ist ein Multipolygon schon viel eher das was du im GIS unter einem Polygon verstehst. Jedenfalls dann wenn es mit En- und Exklaven daherkommt.
An einem Weg kann man nur schwer die Information speichern welcher Weg noch zu diesem Polygon gehört. Und stattdessen mehrere Wege übereinanderzulegen macht die Bearbeitung nicht einfacher.

4rch · 2015-03-02 19:56:49

streckenkundler wrote:

RadFr wrote:
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...

Ich rate mal: weil sich mehrere Multipolygone die gleiche Linie als Outer teilen können? Dann wäre unklar, welches Polygon die Attribute der Linie erben soll.

viw · 2015-03-02 20:12:25

Auch können Eigenschaften vom Weg nicht für das Polygon gedacht sein. Zaun um die Weide oder Mauern um den Garten.

streckenkundler · 2015-03-02 20:15:42

4rch wrote:

streckenkundler wrote:
RadFr wrote:
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...
Ich rate mal: weil sich mehrere Multipolygone die gleiche Linie als Outer teilen können? Dann wäre unklar, welches Polygon die Attribute der Linie erben soll.

Von denen rede ich noch garnicht mal... das sind sowieso meine "speziellen" Lieblinge... Zum Glück ist mein Hauptmapping-Bereich weitestgehend frei davon... und mit den wenigen, die ich in meiner Anfangszeit vorfand, habe ich den einigermaßen vernünftigen Umgang mit MP's gelernt...

Letztendlich ist aber die Diskussion müßig...

Sven

moenk · 2015-03-26 08:58:20

Moin,

tatsächlich scheint in Bezug auf die OSM-Daten kein Weg um Programme wie osm2pgsql, osmosis oder imposm herumzuführen. Die sind aber recht kompliziert in der Handhabung, außerdem können auch direkt keine Shapefiles erzeugen wie unsere Studies sie gern haben möchten.

Daher gibts dazu den WFS-Downloader: http://gdi.geo.hu-berlin.de/wiki/WFS-Downloader

Einige GIS-Programme tun sich mit dem WFS-Download etwas schwer, daher ein kleines Tool für diesen Zweck: Am WFS-Server die Layer abfragen und dann als Shapefile downloaden.

LG,

-moenk

Announcement

#1 2013-12-04 12:37:04

Geofabrik building-Shape unvollständig, was tun?

#2 2013-12-04 13:44:39

Re: Geofabrik building-Shape unvollständig, was tun?

#3 2013-12-04 15:00:30

Re: Geofabrik building-Shape unvollständig, was tun?

#4 2013-12-04 15:26:40

Re: Geofabrik building-Shape unvollständig, was tun?

#5 2013-12-04 16:03:37

Re: Geofabrik building-Shape unvollständig, was tun?

#6 2013-12-04 17:13:47

Re: Geofabrik building-Shape unvollständig, was tun?

#7 2013-12-04 17:32:15

Re: Geofabrik building-Shape unvollständig, was tun?

#8 2013-12-04 17:33:49

Re: Geofabrik building-Shape unvollständig, was tun?

#9 2013-12-04 17:47:49

Re: Geofabrik building-Shape unvollständig, was tun?

#10 2013-12-04 17:53:25

Re: Geofabrik building-Shape unvollständig, was tun?

#11 2013-12-04 18:13:05

Re: Geofabrik building-Shape unvollständig, was tun?

#12 2013-12-04 18:22:34

Re: Geofabrik building-Shape unvollständig, was tun?

#13 2013-12-04 18:38:19

Re: Geofabrik building-Shape unvollständig, was tun?

#14 2013-12-04 18:45:59

Re: Geofabrik building-Shape unvollständig, was tun?

#15 2013-12-05 12:42:18

Re: Geofabrik building-Shape unvollständig, was tun?

#16 2013-12-06 01:40:02

Re: Geofabrik building-Shape unvollständig, was tun?

#17 2013-12-06 06:59:00

Re: Geofabrik building-Shape unvollständig, was tun?

#18 2015-03-02 13:00:50

Re: Geofabrik building-Shape unvollständig, was tun?

#19 2015-03-02 18:04:28

Re: Geofabrik building-Shape unvollständig, was tun?

#20 2015-03-02 18:30:21

Re: Geofabrik building-Shape unvollständig, was tun?

#21 2015-03-02 19:44:53

Re: Geofabrik building-Shape unvollständig, was tun?

#22 2015-03-02 19:56:49

Re: Geofabrik building-Shape unvollständig, was tun?

#23 2015-03-02 20:12:25

Re: Geofabrik building-Shape unvollständig, was tun?

#24 2015-03-02 20:15:42

Re: Geofabrik building-Shape unvollständig, was tun?

#25 2015-03-26 08:58:20

Re: Geofabrik building-Shape unvollständig, was tun?

Board footer