meistens ist place=* als Node getaggt. Aber dadurch ist es nicht immer Eindeutig zu welcher Ortschaft ein Anwesen gehört. Wäre es daher nicht besser alle landuse=residential, farmyard usw. mit einem Multipolygon oder einer anderen Relation zusammenzufassen?
Ich hab mich in meiner Umgebung ein bisschen mit overpass turbo umgesehen und konnte nur wenige Fälle finden, wo das so gemacht wurde. Aber meistens wurde trotzdem zusätzlich der place-Node beibehalten.
Edit: Und/Oder sollte man, wie es teilweise gemacht wird, an jede unbenannte Straße (z.B. service) den Namen der Ortschaft ran schreiben? (In kleinen Orten gibt es ja meist keine echten Straßennamen)
Aussiedlerhöfe, die außerorts liegen, tagge ich wie folgt
Einzelner Aussiedlerhof mit eigenem Hofnamen:
Hoffläche: landuse=farmyard + place=farm oder isolated_dwelling + name=“Name Aussiedlerhof”
Gebäude mit Haus-Nr.: building=yes + addr:city=* + addr:place=“Name Aussiedlerhof” + addr:housenumber=*
Einen Place-Node setze ich hier nicht.
Beispiel: https://www.openstreetmap.org/#map=18/47.98459/9.94288
Mehrere Aussiedlerhöfe mit gemeinsamen Hof- / Flurnamen:
Hoffläche: landuse=farmyard
Gebäude mit Haus-Nr.: building=yes + addr:city=* + addr:place=“Flurnamen” + addr:housenumber=*
Place-Node im Zentrum der Aussiedlerhöfe: place=isolated_dwelling bzw. hamlet + name=“Flurnamen”
Beispiel: http://www.openstreetmap.org/?mlat=47.97227&mlon=9.92871#map=17/47.97227/9.92871
**Die Straßen / Hofzufahrten erhalten jeweils keinen Namen!
**
addr:place wird von OSMand gefunden, Nominatim liefert nur teilweise korrekt Ergebnisse.
Wenn ich es richtig verstanden habe, ist es also bei kleineren Orten ohne echte Grenzen in Ordnung mit Multipolygonen zu arbeiten und den Place-Node zu löschen.
Welchen Vorteil siehst du darin einen einen extra Place-Node zuerstellen und nicht einfach die landuses mit einem place-Multipolygon zusammenzufassen?
Zusammenfassung soweit:
An alle bewohnte Gebäude ein addr:place=* (Sollte auch i.O. sein, wenn die Hausnummern noch nicht erfasst sind.)
An die Straßen kommt der Ortsname nicht.
Bei Einzelhöfen kann der place-Tag direkt ans Landuse. (Wobei hier auch in der Regel ein Place-Node reicht.) 4. Bei mehreren Höfe ist auch ein Multipolygon möglich, oder? *(Edit: Wartungstechnisch ist das eher nicht zu empfehlen, siehe unten.)
Da hast Du natürlich recht. Aber denkst Du bzw. Ihr, dass ein Multipolygon zu kompliziert für diesen Zweck sein kann oder sonstige entscheidende Nachteile hat?
Nein - finde ich nicht. Du hast hier ja nur ein paar Einzelmeinungen über deren Vorgehen gesammelt.
Ich halte gar nichts davon, bestehendes Tagging zu ändern und Dinge zu löschen, blos um sie der aktuellen Taggingmode anzupassen.
Ich mach’s so: Wenn ich etwas Neues erfasse,dann so wie es meiner Meinung nach den aktuellen Gepflogenheiten entspricht. Bestehendes lasse ich wie’s ist, ausser es ist wirklich hahnebüchender Blödsinn oder völlig veraltet. Ich such auch nicht aktiv nach sowas. Es gibt noch genügend Neues zu erfassen. Noch fehlen in ganzen Landstrichen Gebäude und Adressen.
Ein permanent unterschätztes Thema bei OSM ist die Wartbarkeit der Daten im Team. Das funktioniert nur bei maximaler Klarheit der Strukturen. Nimm an, in drei Jahren wird 200 m weiter ein weiteres Gehöft gebaut, das noch dazugehört. Wahrscheinlich wird das jemand anders mappen. Einen place-node findet der Kollege sofort und kann ihn entsprechend verschieben. Ein Place-Polygon ist im Editor auch sichtbar und kann erweitert werden. Aber dass die bestehenden Gehöfte zu einem MP zusammengefasst sind, ist im Editorfenster nicht grafisch sichtbar, dazu müsste man schon einen davon anklicken und einen Blick auf dessen Mitgliedschaften werfen, bevor man auf die Idee kommt, diese Struktur zu übernehmen.
Kurz: Wir arbeiten im Team zusammen, aber es wäre unmöglich, über jeden Punkt miteinander zu kommunizieren, es finden keine Übergaben statt. Wir arbeiten gezwungenermaßen viel nebeneinander her, daher muss alles möglichst selbsterklärend sein.
Eine Relation ist datentechnisch bestimmt am saubersten, aber wartungstechnisch am komplexesten und verstecktesten.
Das Zusammenfassen aller landuse innerhalb einer Siedlung via Multipolygon ist nicht möglich da Multipolygone keine outer haben dürfen, die sich an mehr als einem Punkt treffen (Beispiel). Es ist Wartungstechnisch ja auch ein Alptraum .
Warum also keine einfachen Polygone (Areas)?
Das wäre für größere Städte nicht wartbar und man käme an an das 2000 Nodes per Way Limit. Bei kleineren Siedlungen fehlt so die Information über das Ortszentrum, nämlich dort momentan üblicherweise der Place Node sitzt. Als Lösung schlage ich das neuen Tag place=place_centre vor welcher bei flächig gemappten place= als Node das Ortszentrum markiert.*
Warum keine Multipolygone mit einem Ring und mehreren outer wie bei Grenzen?
Hier würde man praktischerweise auch die landuse als Multipolygone mappen. Unser gefürchteter Multipolygonwahn würde gefördert. Als Lösung schlage ich die Einführung einer place-Relation die die Grenzen-Ways mitnutzt und als “alle urbanen Flächen innerhalb der Fläche der Relation” definiert ist. Place=place_centre kann als Mitglied der Relation mit Rolle centre o.ä. aufgenommen werden.
Im Großen und Ganzen bin ich da deiner Meinung. Aber wenn sich durch ein anderes Taggigschema zusätzliche Informationen erfassen lassen, sehe ich das Ändern von Bestehenden weniger kritisch. Natürlich dürfen dabei keine Informationen verloren gehen oder die Wartbarkeit deutlich verschlechtert werden.
Wie meinst du das genau? Meinst du, man soll soweit wie möglich die Grenzen-Ways nutzen und wenn das nicht ausreicht noch weitere Wege einzeichnen?
So wie ich das jetzt sehe, sind die Punkte 1.-3. in meiner Zusammenfassung aus #6 in Ordnung und mehr kann man mit dem aktuellen Taggingschema nicht sinnvoll umsetzten ohne die Wartbarkeit deutlich zu verschlechtern.
Auch sollte sich aus dem addr:place-Tag der Gebäude die Information, welche Teile zu einem Ort gehören, mit ein bisschen Aufwand rekonstruieren lassen.
Nochmals vielen Dank an Euch. Zuerst habe ich die Wartbarkeit zu wenig beachtet bzw. die Komplexität, die sich daraus entwickeln kann.
Viele Grüße,
wwweg
PS: Edit:
Leider verstehe ich nicht genau, worauf du hinaus willst. Meinst du man sollte einfach einen Place-Node im Zentrum setzen und dann ggf. falls ein Konsens besteht irgendeine Relation mit den place-Node und den Grenzen machen, statt einen neuen Key fürs Zentrum?