Gibt es denn irgendeinen Grund, warum in Deutschland unflexible Multipolygone genutzt werden, wenn diese mit anderem Tagging-Verhalten auch noch Nachteile und Unterschiede mit sich bringen? Anscheinend wird das ja nur von allen bedauert. Kann da nicht mal einer mit einem Bot alles vereinheitlichen?
Hintergrund siehe Diskussionsseite zur boundary relation:
http://wiki.openstreetmap.org/wiki/Talk:Relation:boundary#Use_type.3Dmultipolygon_instead
Zum Ursprungsproblem dieses Threads steht da auch was:
*Giving a new point of view - Merging everything in type=multipolygon makes automatic validity checking harder. I now implemented relation checking in JOSM’s validator and this checker checks for multipolygons whether they have outer/inner or something else. Now boundaries also use admin_centre and subarea. To get this together I either need to allow these roles for all multipolygons or need to add checks which will fail for every new type. *
EDIT: Hab’s mal auf die Diskussionsseite zu MP gestellt, ob andere Roles erlaubt sind.
Wenn nicht, sind MPs kein vollwertiger Ersatz zur boundary relation → umtaggen
EDIT2: So, hab den Kreis Coesfeld mal entsprechend umgebaut.
http://www.openstreetmap.org/browse/relation/62779
Das war ein Mißverständnis, bin von einem Tag ausgegangen, nicht von einem Member.
Nach dem aktuellen Stand der Diskussion finde ich MP für Boundary auch ziemlich daneben, wenn es ein boundary gibt. => umtaggen.
Nur mal so ein Beispiel zum anschauen, wie es in Russland gehandhabt wird. Eine schöne Statistik in der auch alle erfassten und noch fehlenden Ortschaften aufgelistet sind. Alle Bezirke und Landkreise sind Boundary-Relationen mit der Rolle admin_centre als Hauptort. Nicht wundern, dass so viele Orte als hamlet getaggt sind, in Russland jeder Ort mit weniger als eintausend Einwohnern.
http://yav.gis-lab.info/boundaries/r115135-o57000000
Frankreich hat interessante Boundary Eltern- / Kindrelationen verwendet: France boundary pyramidal construction.
statt “interessant” hätte ich “kompliziert” geschrieben. 
Ging in Frankreich wohl nicht anders auf Grund der API Beschränkungen.
Mein Grund gegen type=boundary:
- Multipolygonrelationen sind etwas besonderes. Jedes ernsthafte OSM-Auswerte-Programm hat speziellen Code eigens fuer Multipolygone, um daraus naemlich grosse Flaechenobjekte zusammenzusetzen. In meinen Augen sollte “type=multipolygon” immer den Ausschlag geben, diesen speziellen Code auszufuehren; wenn wir diesen Spezialcode bei einer ganzen Latte von verschiedenen Relationstypen brauchen (heute boundary, morgen kommt einer und sagt “fuer ein Waldgebiet ist Multipolygon zu unflexibel, ich tagge jetzt type=forest, damit ich noch eine zusaetzliche Rolle namens “forsthaus” definieren kann”, und so weiter), dann muss das jedes Mal in allen Tools nachgezogen werden. Das ist schlecht - besser waere, wenn der Mapper durch type=multipolygon einfach angeben kann, dass er eine Flaeche meint, und fertig.
Allerdings:
Mit der Einfuehurng von API 0.7 sollen eh die Multipolygone und Boundaries wegfallen und durch einen einheitlichen Flaechendatentyp ersetzt werden. Dann werden wir diese Objekte alle automatisch umwandeln. Was dann aus irgendwelchen Zusatz-Members wie “forsthaus” oder “admin_centre” wird, weiss ich nicht; eventuell wuerde man hierfuer tatsaechlich dann wieder eine uebergeordnete Relation bauen muessen.
Mein Rat:
Nicht ueber Bord gehen damit, und vorallem nicht alles umtaggen (streng genommen ist fuer boundary ja auch statt inner/outer ein enclave/exclave definiert, das fast alle falsch verstehen). Lasst uns das lieber mal in Ruhe angehen, wenn wir richtige Flaechendatentypen haben. Der Validator in JOSM ist meiner Ansicht nach viel zu oberlehrerhaft und sollte solche Sachen nicht anmaekeln.
Bye
Frederik
Hi Frederik,
das heißt konkret, wenn jemand admin_centre und subarea hinzufügen möchte, soll der Typ
auf MP bleiben?
Trotz des Einwands von Dirk, dass man MPs dann nicht mehr so schön validieren kann?
Meine persönliche Meinung ist, dass Grenzen “besondere” Kartenobjekte sind die ein eigenes
Tag verdient haben.
Chris
Ich bin der Meinung das viele type=* überflüssig sind. Zum Beispiel type=route in Kombination mit route=* oder type=restriction mit restriction=* jeder Auswerter der mit diesen Sachen etwas anfangen kann und will muss eh nach dem zweiten Schlüssel schauen. Daher ist es eigentlich egal ob dort vorher ein type definiert ist. Dies könnte also schon vieles vereinfachen.
Das wäre eine signifikante Verschlechterung. Derzeit muß man nur ein Tag “type” prüfen und weiß was gemeint ist. Mehrdeutigkeiten sind ausgeschlossen.
Die Suche nach dem Vorkommen bestimmter Tags ist umständlicher und Mehrfachvorkommen ist jederzeit möglich.
bye
Nop
Kannst du das bitte nochmal genauer erklären? Also im Prinzip verhindert das type=public_transport doch nicht, dass es sich dabei um ein route=bus handelt. Gleichzeitig ist es auch möglich type=route route=bus zusetzen. Wenn jetzt also jemand Busrouten auswerten möchte sucht er nach route=bus.
Wenn ich dich richtig verstehe möchtest du type=* als Filter benutzen um nicht unterstützte types auszusortieren. Einen anderen Zweck kann ich nicht erkennen.
Mit Deinem Vorschlag kann ich jederzeit route=hiking, restriction=blah, boundary=nochwas setzen. Damit ist dann völlig offen was die Bedeutung sein soll und wo der Fehler ist.
Derzeit würde ich einfach nachsehen ob type=route da ist, es dann als Route verarbeiten und alles störende Beiwerk kann ich ignorieren.
bye
Nop
Da stimme ich mit dir ueberein, aber meine Schlussfolegrung daraus ist eine voellig andere:
Eine multipolygon-Relation dient ausschliesslich dazu, um eine Flaeche zu definieren. Alles was darueber hinaus geht, hat in so einer Relation nichts zu suchen.
Fuer dein Beispiel mit dem Forsthaus und dem Wald bedeutet das, dass die Wladflaeche per multipolygon-Relation erfasst sein kann. Die logische Verbindung zwischen Forsthaus und Wald ist aber eine eigene Releation ganz anderen Typs, bei der die Waldflaechenrelation eines der Mitglieder ist.
Warum man hier in Deutschland aber meint, dass die Grenzen der Verwalltungsbezirke Flaechenobjekte sind, ist allerdings eine ganz andere Frage.
Damit man das Rad nicht immer wieder neu erfinden muss, geht es also nicht darum, dass man die multipolygon-Relationen aufblaeht, sondern stattdessen muss man sie als einzelnen Objekt begreifen, das wiederum Mitglied in anderen Relationen sein kann.
Und was das Weglassen des type=* angeht, so kann ich da nur Nop zustimmen. In vielen Faellen mag es zwar letztendlich ueberfluessig scheinen, aber es gibt auch genug Faelle, wo sich dadurch Missverstaendnisse einfach vermeiden lassen. Besser der Klarheit zu Liebe ein Tag mehr verwenden. (Das ist so aehnlich wie bei Programm-Code: Der beste Code ist nicht der, der mit am wenigsten Zeichen auskommt, sondern der, der (von Fremden) am einfachsten zu lesen ist.)
Gruss
Torsten
+1
Ausserdem werden die Relationen im Relationsfenster erst nach Typ und dann nach Name oder ref sortiert. Das hat durchaus seine Vorteile.
Gruß.,
ajoessen
aber andersherum beschränkt es auch wieder. Du kannst eben nicht type=public_transport und type=route setzen oder gar type=multipolygon und spätestens bei letzterem ist dann eh entscheidend welche anderen tags gesetzt sind.
Außerdem geht das Auswerten doch nach dem Prinzip ich suche mir alle relationen mit route=bus und schaue dann nur nach name oder ref. die weiteren Details interessieren eigentlich dann nicht. Ein anderer Auswerter schaut nur auf restriction=no_left_turn und sucht dann ob die Rollen from to via vergeben sind. Auch hier sind andere Details nicht von belang.
Das sollst Du auch nicht. Mehrere Aussagen => mehrere Relationen.
bye
Nop
Hallo Nop,
wo aber ist der Unterschied zwischen type=public_transport linevariant=bus oder type=route route=bus?
Abfrage: “Die administrativen Grenzen bitte, weil ich will 'ne schematische Karte machen.” Hilfe! Nein, ich wollte nicht Millionen von Gebäudeumrissen haben! So erst mal nen Kaffee kochen, bis der Renderer das die administrativen Grenzen rausgesucht hat…
Da der Auswertecode ja eh schon für Multipolygone verarbeiten kann, ist es kein Problem den noch mal für Grenzrelationen anspringen zu lassen. Und zum eintragen eines Forthauses im Wald brauche ich keine extra Relation!
Normalerweise bin ich weniger an der Grenzlinie interessiert als an der Fläche.
Das Interessante an der Bundesrepublik ist ja auch nicht die Grenze sondern der Inhalt.
Wenn du in der Nähe einer Grenze wohnst, interessiert die die Grenze als Weg (da ändern sich Gesetze/Sprache/Verkehrsregeln/…) und weniger die dadurch eingeschlossene Fläche.
Ich sehe das so:
- Eine Grenze besteht immer zwischen zwei Objekten (die auch eine Fläche haben).
Das sind im Prinzip Striche auf der Landkarte (Wege) also type=boundary/boundary_segment. - Die Umgrenzung eines Gebietes setzt sich aus allen Grenzen zu Nachbargebieten zusammen.
Dafür kann man, wenn man unbedingt will, auch ein Multipolygon nehmen.
Mitglieder sind die Grenzabschnitte zu jeweils einem Nachbarn. - Aua, Multipolygone wollen keine Relationen für die Grenzabschnitte, sondern einzelne Wege.
Da sollte man mal in die Weiterentwicklung investieren, wenn man Multipolygone will.
Auf die Art und Weise könnte man die zwei Sichtweisen auf eine Grenze (lokal = Line/Trennung, großräumig = eingeschlossene Fläche) beide sinnvoll abbilden.
Edbert (EvanE)