In meiner Umgebung habe ich bemerkt, dass Postleitzahlgrenzen, die ja aus Multipolygone bestehen, anscheinend aus Linien bestehen, die ebenfalls ein boundary=postal_code beinhalten (allerdings ohne weitere Informationen mit Ausnahme der Quelle), was m.M.n. ein Missbrauch darstellt, da ein Flächenelement für Linien verwendet werden.
Es gibt sogar einen Fall, wo jemand gerade durch die Beschwerden in iD durcheinandergekommen ist, was mich veranlasst hat, diesen Thread zu erstellen.
Tatsächlich habe ich bei Overpass mal rumgeschaut und bemerkt, dass dies v.a. ein Problem in Deutschland ist und bei den Nachbarländern (mit Ausnahme Österreich und Belgien) sind treten solche boundary=postal_code-Linien da eher vereinzelt auf.
Ich frage mal somit nach, ob dies eigentlich so sein soll oder ob dies eigentlich geändert werden sollte.
Ohh… iD und Grenzrelationen… bitte ganz, ganz vorsichtig…
Der Editor iD kann sowas nicht gut. Für sowas bitte JOSM verwenden und auch nur dann, wenn man da tiefere Kenntnisse bei JOSM und solchen Relationen hat!
Es gibt ja im OSM Datenmodell keine Fläche. Es gibt nur linien und es gibt annahmen darüber wann eine geschlossene Linie eine Fläche darstellt.
landuse + geschlossene linie = fläche.
junction=roundabout und geschlossene linie → keine fläche
Und dann gibt es das “meta” Objekt der Relation, das auch mit annahmen gefüttert mehrere linien beschreiben kann als ein polygon beschreibend.
Dazu kommt das wir kein wirkliches “Boundary” objekt haben. Eine Grenze ist ja erstmal nur eine Linue. Wir behelfen uns mit dem zusammenfügen von linien zu einem polygon um dinge wie en und exklaven abbilden zu können.
Rendern wollen wir Grenzen aber als linien, nicht als polygone. Deshalb haben die administrativen Grenzen auch jeweils den kleinsten oder höchsten level getagged an dem diese linie teilnimmt.
Es gab in der historie von OSM durchaus mal eine “spezial” boundary relation die aber in favour of multipolygon ersetzt worden ist. Denn das zusammensetzen zu einer Fläche mit En und Exklaven ist bei beiden identisch gewesen.
Dazu kommt das wir keine linien mit zig tausenden von Punkten haben wollen (Mittlerweile gibts da auch ein API limit) so das und nichts anderes übrig bleibt diese aus mehreren Linien zusammenzusetzen.
Dazu ist im boundary Bereich jede 2. Linie oder so nicht nur teil der beiden benachbarten bereiche, sondern mehrere Grenzen auf verschiedener hierarchischen Ebenen, bzw eine administrative Grenze kann gleichzeitig auch die des postcodes sein.
Und nein - Das ist kein Missbrauch sondern die effizienteste Nutzung der OSM Datenmodelle unter beachtung o.g. Rahmenbedingungen.
Also, was ich meine ist, dass die PLZ-Linien, die ich meine
keine geschlossenen Linien sind, sondern nur Teile der Umrisse und
mit Ausnahme von boundary=postal_code ansonsten keine Informationen beinhalten
Dass die PLZ-Flächen i.d.R. als Multipolygone konstruiert sind und sich die Linien teilen, halte ich natürlich für verständlich. Allerdings ist das mehr eine Situation mit Gebäuden mit Innenhöfen (also mit ein Loch in der Mitte), die ja als Multipolygone konstruiert sind, vergleichbar, denn dort stehen Informationen wie building=* sowohl im Multipolygon als auch redunant an der Außenlinie, wodurch auch die Innenhöfe als building=* eingezeichet werden (teilweise sogar inkonsistent d.h. building:levels ist für beide Elemente anders).
wenn man es genau nimmt gibt es schon Flächen im Modell (Multipolygone), nur halt nicht als Primitive. Wenn man bei ways “sicher” sein will dass sie als Flächen markiert sind (oder explizit nicht), kann man area=yes oder area=no dazutaggen, dann sollte es eigentlich auch klar sein, nur dass manche Datenkonsumenten das ignorieren.
Nein, das sollte nicht geändert werden.
Nein, das ist kein Missbrauch.
Ja, das kann so sein.
Eine entsprechende Warnung in iD oder einem anderen Editor oder QA-Tool ist zu ignorieren.
PLZ-Grenz-Relationen können aus einer Kombination von ways mit boundary=administrative und boundary=postal_code bestehen. Das ist kein Problem.
Verwaltungs- und PLZ-Grenzen sind Fälle, bei denen ein Tag der Relation, eben boundary=administrative bzw. postal_code an die Außenlinie kommt, wie auch der admin_level der hierarchisch höchsten Relation. Nur in diesen Fällen wird das von QA-Tools nicht angemahnt.
Der Grund dafür ist vermutlich pragmatisch, weil Grenzrelationen ziemlich anfällig für “Zerschießen” sind und man die zugehörigen Linien schnell erkennen soll. Genau weiß ich es aber nicht, es wird halt schon “ewig” so gemacht und auch beschrieben.
Es gab vor kurzem die gleiche Diskussion bei boundary=protected_area, die auch auf den Einbau eines Kurzschlusses aufgrund von ID-Warnungen zurückging. Damals hatte ich mich ein wenig damit beschäftigt. Das Setzen der Tags auf den Wegen ging wohl auf Rendering-Probleme einiger Apps zurück, die nicht ohne konnten. Siehe Relation:boundary - OpenStreetMap Wiki
Persönlich gefallen mit ungetaggte Wege besser, deren Bedeutung aus den Relationen, die sie enthalten, hervorgehen. Vermutlich geht das vielen so, die in ihrer osm-Frühzeit lediglich Multipolygone und keine boundaries gemappt haben.
Ja - Das macht absolut Sinn - Denn postleitzahl regionen/flächen sind exklusiv - Es kann nur eine PLZ gelten. Also ist es richtig das diese sich nicht überlappen. Also kann man ein multipolygon auch aus geteilten “linien” zusammensetzen die eben die Grenze zwischen den PLZ regionen beschreibt.
Bei Landuses würde das im Sinne der “exklusivität” auch Sinn ergeben, aber da hat man sich anders entschieden. Das führt auch dazu das landuses beliebig übereinander gestapelt werden, was semantischer unfug ist.
Das nachbearbeiten von dieserlei multipolygonen ist leider “die pest in Tüten”.
Das problem ist das wege ohne tags von vielen editoren und validatoren angemault werden. Dazu verwirrt es user linien ohne tags zu sehen. Zack ist ein “highway=path” drauf.
Es macht schon sinn zumindest grob zu beschreiben was das ist.
Und am ende ist es auch nicht schlimm das das tag da drauf ist. Ich finde es gut im Sinne der eindeutigkeit.