Relationen: Parkplatz grenzt an Gebäude & Gebäude an Gebäude

Hallo,

hat sich in den letzten Jahren eigentlich ein Konsenz gebildet, was mit topologisch direkt angrenzenden Flächen gemacht wird?

Beispiel 1 - Parkplatz grenzt an Gebäude:
Topologisch korrekt ist, dass die Grenzlinie zwischen Gebäude & Parkplatz jeweils Bestandsteil der Multipolygone Gebäude und Parkplatz sind. Dank JOSM ist das sehr einfach möglich und osm2pgsql verarbeitet es korrekt. Diese Arbeitsweise hat den großen Vorteil, dass man kleine “Blitzer” zwischen den Objekten hat.

Beispiel 2 - Gebäude an Gebäude:
Eigentlich müsste man hier analog vorgehen: Wenn zwei Gebäude aneinander grenzen, muss die Grenzlinie in jeweils zwei Multipolygone. Aber wer macht das? Gerade jetzt, wo hundert tausende Gebäude in NRW erfasst wurden, macht das nur ein geringer Prozentteil auf diesem Weg.

Was sagt die Erfahrung? Streuben sich die Nutzer immer noch gegen Multipolygone?

LG
Tobias

Dafür braucht man gar keine Multipolygone… :confused:

Hallo,

es will aber nicht jeder Java wegen JOSM installieren sondern Vieles im Browser erledigen (den hat jeder Rechner). Ohne JOSM werden Multipolygone aber schnell eklig.

Gruß
Mario

Natürlich braucht man es nicht, aber da du aus BW kommst, erkläre ich dir das aktuelle Problem in NRW: hier wurde die ALK zur Abdigitalisierung freigegeben. Manche lassen eine Vektorisierungsanwendung drüber laufen, weshalb manche Gebäude detailierte Umringe mit vielen Ecken und Zacken haben.

Nun kommen andere Mapper und wollen Details dort rankleben. Was gibt es nun für Möglichkeiten?
a) alle Ecken und Zacken genau nachmalen - Merge hilft hierbei
b) beide Flächen miteinander verschneiden - dafür gibt es Plugins
c) einfach den Parkplatz / die Grünfläche irgendwie davor zeichnen, hauptsache sie ist da
d) das verhandene Gebäude auftrennen und jeweils den Platz und das Gebäude in Multipolygone packen

Auswertung:
a) braucht viel Zeit, hat aber super Ergebnisse - am Ende hat man zwei sauber getrennte Geometrien => im Browser der Horror
b) nicht jeder hat diese Plugins, Browser scheidet eh aus
c) das ist leider das übliche Vorgehen, geht ja am schnellsten
d) geht am schnellsten und saubersten: man trennt einfach das Gebäude auf, zeichnet die anderen 3 Ecken des Platzes und fügt alles zusammen.

Oder habe ich eine Alternative übersehen?

Hi Tobi

ich stimme Dir zwar zu, das die Multipolygon Lösung die klarste einfachste und schönste Lösung in den Daten ist.

Sie hat nur einfach den extremen Nachteil, das nicht jeder Editor (Editor = Tool und Editor = Mapper) damit problemlos umgehen kann.

Damit erzeugen wir Daten, die später Fehler in der Pflege erzeugen werden. Oder aber wir grenzen neue Mapper aus, weil sie schon an so einfachen Dingen wie Parkplatz grenzt an Haus unsere Daten nicht mehr nachvollziehen können.

Von daher bin ich dazu übergegangen, solche Konstrukte zu vermeiden, wobei hier die Ausnahme die Regel bestätigt.

Christoph

Ich hab bisher einfach ein neues Polygon gezeichnet und angrenzende Punkte verbunden… :confused:

Also wenn der Parkplatz um das ganze Gebäude geht (in anderen Worten: das Gebäude befindet sich völlig in dem Parkplatz), dann muss daraus ein Multipolygon gemacht werden. Umschließt der Parkplatz nicht vollständig, dann muss eine Linie gezeichnet werden, die an das Gebäude grenzt (schließlich muss der darf der outer keinen Kontakt zu den inner haben).

+1 (Einfach einfach)

Fläche an Fläche - (Relationen für Multipolygone sollten nur dort verwendet werden, wo es nicht anders geht.)
Wenn ich mancherorts sehe, das residential als Relation mit Straßenabschnitten (mit weiteren Relationstypen), Wiesenabschnitten (als Relation mit nur outer), … genutzt wird …

Multipolygon-Wahnsinn

Muss ich lange überlegen ob ich so was in Realität schonmal gesehen habe. :sunglasses:

Bei uns steht ein Trafohäuschen mitten auf dem Parkplatz :slight_smile:

Das Problem, was ich dabei sehe ist z.B. Landuse. Nehmen wir unseren Friedhof in Werl. Da steht die Trauerhalle als Gebäude mit Parkplatz (räumlich getrennt) drauf. Steche ich jetzt das Gebäude aus oder nicht? Wenn ich nämlich die Größe des Friedhofs bestimmen will, wird es kompliziert:

  1. das Polygon aus der DB nehmen
  2. prüfen ob Löcher drin sind; wenn Loch: prüfen was drin ist: welche Art der Nutzung, bei Gebäude: Loch füllen
    usw.

Ich sehe also oft, dass die Leute bei Landuse das Gebäude einfach drauf stehen lassen, bei anderen Arten der Polygone aber Multipolgone bilden. Das ist schwer, wenn man mit den Daten arbeitet. Ihr dürft ja nicht vergessen, dass es nicht nur Mapper mit dem Browser gibt, sondern auch Leute, welche die Daten nutzen wollen :slight_smile:

Aus echtem Interesse. Wie machst du das? Nutzt eine Funktion dafür, die ich noch nicht kenne?
Im GIS verschneide ich die Flächen (Gebäude und Parkplatz) einfach und lösche die überstehende Fläche. Dann habe ich keine Blitzer und nichts.
Im Endeffekt müsste es ja eine Funktion geben, um aus Relationen einfache Polygone zu wandeln, dann wären ja alle zufrieden.

Noch ein reales Problem:
Der Parkplatz eines ALDIs bei uns in Werl grenzt an den Parkfriedhof, getrennt werden beide durch eine Mauer. Ich habe das jetzt so abgebildet:

  1. Parkplatz mit eine Linie drum herum
  2. Friedhof mit Zaun drum herum
  3. ALDI mit einer Linie drum herum
  4. Linie zwischen ALDI und Parkplatz
  5. Mauer einzeln

Das Multipolygon des Parkplatzes besteht somit aus: Parkplatzlinie (1), ALDI-Linie (4), Mauer (5),
das Multipolygon des ALDis besteht somit aus: Parkplatzlinie, ALDI (3), ALDI-Linie (4),
der Friedhof besteht aus: Mauer (5), Friedhof (2)

In der Datenbank ist alles korrekt abgebildet, ich probiere das gleich mal mit verschiedenen GIS-Tools, die OSM-Daten verarbeiten können und mit dem Webeditor.

Man muss einen Parkplatz ja nicht metergenau zeichnen. MP würde ich weitgehend vermeiden, sind einfach zu unhandlich auch in JOSM. Und wenn er um ein Gebäude geht, gibt es beispielsweise of bei McDonalds Drive Thru, dann zeichnet man den Parkplatzweg und die Parkplätze aber nicht als eine Fläche.

Darum geht es ja jetzt überhaupt nicht.

Ich finde das ganze in JOSM extrem einfach. Deutlich einfacher als mit den Programmen, mit denen ich sonst arbeite. Ich werde nachher nochmal alle Funktionen durchgehen und schauen, wie man einfache Multipolygone in einfache Polygone rückwandeln kann.

1: Parkplatz als Fläche (amenity?) mit 3. Fläche als ALDI (building?)verbunden mit
2: Friedhof als Fläche (Der Zaun wird doch bestimmt unterbrochen von der 5. Mauer?)

Für was sind Relationen notwendig?

Günstig wäre ein Link.

Warum Multipolgone wenn es nur ein einfaches Polygon ist - oder reden wir aneinander vorbei? (Multipolygone / Relationen?)

Während des Way-Zeichnens: Ersten gemeinsamen Node anklicken, zweiten gemeinsamen Node anklicken, [F] gedrückt halten bis die Ways nicht mehr gemeinsam verlaufen sollen, weitermachen :wink:

http://www.openstreetmap.org/#map=19/51.54752/7.91807

Liegt vermutlich an meinem Studium, dass ich topolgisch angrenzte Objekte zwanghaft so abbilden will :slight_smile:

Werden Multipolygone nicht durch Relationen (Datenschema) abgebildet?

Wenn das Gebäude zum Friedhof gehört, dann wird natürlich nicht ausgestanzt.

Relation ist einer der drei OSM Datentypen (Node, Way, Relation). MPs sind ein spezieller Typ von Relation.

Yop, die Follow-Funktion. Aber mach das mal bei den ganzen Gebäuden, die wir hier plötzlich in NRW dazu bekommen haben - vorallem weil die ja selbst so genau sind. Bei Multipolygonen klicke ich einfach nur die Parkplatzlinie und die Gebäudelinie an, erzeuge per Tastenkombination ein Multipolygon und tagges es genau wie ein normales Polygon. Wenn ich die ganzen Ecken und Kanten followen würde, wäre das deutlich mehr Arbeit.

Aber ich bin gespannt, ob ich ein Tool finde, welches meine Multipolygone in normale Polygone rückwandeln kann - dann wäre das ja alles kein Problem mehr.

Ich habe in der DB folgende Fälle gesehen:
1 Park war “outer”, Trauerhalle war “inner”,
2. Park war ein normales Polygon, Trauerhalle war ein normales Polygon und liegt mitten im Park,
3. genau wie 2, aber mit einer Relation, in dem Gebäude und Park waren.

Meine Meinung:

  • landuse an landuse - hier liegt im residential ein cemetery (und commercial und farmyard)
  • building, amenity auf landuse (genau so wie ways über landuse verlaufen) - sonst müsste sämtliche buildings aus dem residential ausgeschnitten werden.
  • Wie kommt man auf den Parkplatz Friedhof? Ist der wirklich hinter dem Zaun?
  • Die “Multipolygone” ALDI und Parkplatz haben nur outer - warum nicht nur building (eventuell building:part, usw.) oder amenity?
  • ein area=yes ohne weitere Angaben?
  • beim driveway zum Friedhof fehlt ein hw=service

(und 23 Fehler im Validator)