Changeset: 63870836
Gemeinde Gründau(Verwaltung).
Closed by sky-hub
Tags
changesets_count | 911 |
---|---|
created_by | iD 2.11.1 |
host | https://www.openstreetmap.org/edit |
imagery_used | Esri World Imagery (Clarity) Beta |
locale | de |
Discussion
-
Comment from Garmin-User
Hallo,
bitte unterlass es, Rathäuser als Mitglied zu Grenzrelationen hinzuzufügen. Es sind für Linien nur die Umrisse mit der Rolle "outer" bzw. "inner" definiert.
Grüße
Mario -
Comment from sky-hub
Hallo Mario,
.
"bitte unterlass es, Rathäuser als Mitglied zu Grenzrelationen hinzuzufügen."
.
Warum?
.
Etwa aus diesen Grund:
"Es sind für Linien nur die Umrisse mit der Rolle "outer" bzw. "inner" definiert."
?
.
Du beziehst Dich auf diesen wiki-Artikel?:
https://wiki.openstreetmap.org/wiki/Relation:boundary
.
Schöne Grüsse
sh -
Comment from Garmin-User
Der Grund ist, dass Datenbanken nicht zwingend auf die Rolle angewiesen sind, da sie die Geometrie aus Lage der Ringe und deren Verlauf selbst erkennen (und die Rolle daher nicht auswerten müssen). Das minimiert Fehler bei falscher Rollenvergabe (kommt häufiger vor) aber maximiert leider Fehler durch falsche Mitgliedschaften (sollte vermieden werden)...
Im Falle der administrativen Grenzen würden dadurch Rathäuser als innerer Ring interpretiert werden und gehören damit nicht zur Fläche.
Mir gefällt der Gedanke auch, admin_centre auf das Verwaltungszentrum zu setzen. Andere haben den Sachverhalt ebenfalls erkannt und es kristallisiert sich langsam die Lösung heraus, einen zusätzlichen Node - wo es zutrifft - in das Rathaus mit "office=government, government=administrative" zu setzen und diesen als admin_centre zu verwenden.
admin_centre ist übrigens nicht zwingend Bestandteil einer Grenzrelation, als Linie falsch interpretiert, als node aber verzichtbar. Es muss nicht alles drangepappt werden, was irgendwie möglich ist. Relationen sind dafür zu empfindlich und die Fehlerauswertung wird erschwert.
Grüße
Mario -
Comment from sky-hub
Hallo Mario,
.
vielen lieben Dank für die ausführlichen Erläuterungen.
.
Ich habe das jetzt so verstanden, wenn also Auswerter einer Grenzgebiets-Relation nicht schlau genau sind und die Fläche nicht unter der Bezugnahme der entsprechenden Rollendefinition der Relationsmitglieder modellieren können, dann diese Rathaus/Bürgerhaus-Linien als „inner“-Flächen unsinnigerweise ausgeschnitten werden. – Das wäre in der Tat suboptimal.
.
Ja, mein erster Gedanke war soeben, dann auch für amenity=townhall anstatt einer Linie(Fläche) einen Punkt zu verwenden.
.
Du hast Recht mit der noch weiteren Option als Nebenlösung, die POIs office=government (der eher neueren/zusätzlichen Erfassungsart) zu verwenden, ja dann eben auch ausschliesslich als Punkt-Element.
.
Das könnte dann nämlich nicht nur für admin_level=8 (lat-lon des Gemeindeamtes), sondern auch für admin_level=6 (lat-lon des Landratsamt) interessant sein...
.
Ich sehe Einbindung von punktförmigen Objekt in Grenzgebietsrelation aber jetzt bereits etwas kritisch, denn es könnte ja jederzeit ein anderer Benutzer aus Punkt wieder eine Linie(Fläche) machen.
Man sollte dann wenigsten so etwas wie eine Notiz an dem Punkt-Objekt (amenity=townhall / office=government) hinterlassen (z.B. note=Bitte dieses Objekt punktförmig belassen, solange dieses Objekt als Mitglied einer Rolle („townhall“ oder „office“) in der Grenzgebietsrelation eingebunden ist)
.
Das heisst, wenn ich für die Zukunft diese ausschliesslich punktförmigen Objekte als Mitglieder mit Rolle (bspw."townhall" / "office") der Grenzgebiets-Relation (inklusive note=“text siehe oben“) hinzufüge, dann würdest Du es nicht mehr revertieren?
.
Ich gebe Dir auch Recht, dass das dann schon ggf. als so eine Art Sammelrelation oder site-Relation (die ich persönlich nicht so mag) gewertet werden könnte. Aber da wir uns ja hier bei Grenzrelationen sowieso schon in der osm-Grauzone (bzgl. on-the-ground Erfassung) befinden, kommt es dann darauf m.E. auch nicht mehr an…
.
Viele Grüsse
sh -
Comment from Garmin-User
Hallo,
"wenn also Auswerter einer Grenzgebiets-Relation nicht schlau genau sind und die Fläche nicht unter der Bezugnahme der entsprechenden Rollendefinition der Relationsmitglieder modellieren können"
Das hat mit "schlau" nichts zu tun. Im Wiki ist eindeutig definiert, welche Elemente verwendet werden dürfen und wofür. Auswerter können nicht alle Eventualitäten abfangen, sie halten sich an das, was aus dem Wiki bekannt ist. Wie würde es dir gefallen, wenn ein Auswerter die Arbeit versagt, weil ein Element nicht definiert ist oder eine Rolle fehlt? - Kommt nämlich sehr häufig vor, also macht der Auswerter z.B. so weiter, als hätte er ein gültiges Element mit Standardrolle vor sich, um Fehlinterpretationen zu vermeiden.
"Aber da wir uns ja hier bei Grenzrelationen sowieso schon in der osm-Grauzone (bzgl. on-the-ground Erfassung) befinden, kommt es dann darauf m.E. auch nicht mehr an…"
Die Grenzrelationen sind eine der wenigen Dinge, die trotz fehlendem "on the ground" voll akzeptiert werden. Das liegt wohl auch an ihrer Wichtigkeit. Aber sie reagieren empfindlich auf Fehler. Deshalb ist es besser, sie sparsam mit Elementen auszustatten - insbesondere nur solchen, die im Wiki aufgeführt sind. Wenn z.B. bei der Fehleranalyse im JOSM die Warnungen überhand nehmen, könnte man schlimmere Fehler leicht übersehen.
Grüße
Mario
Ways (1)
Relations (1)
Nodes (1)
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |