Bei einem kleinen Ausflug nach Russland habe ich gesehen, dass die bei Relationen mit type=boundary ein admin_centre angeben können, so z.B. Moskau. Aufgrund vorheriger Diskussionen hier, wollte ich mich gleich freudig ans Werk machen. Ich musste aber im Wiki sehen, dass das in Deutschland anders ist, weil wir, warum auch immer, die Grenzen als type=multipolygon erfassen und dort weder ein “label” noch ein “admin_centre” definiert ist. Nun gibt mir JOSM eine Warnung wenn man ein admin_centre in eine Multipolygonrelation packt, kann ich das trotzdem uploaden oder sollte man das eher unterlassen?
Mit einem zusätzlichen Label dieser Art kannst Du auf jeden Fall nichts kaputt machen. Sinnvoll klingt’s auch. Ich würd’s eintragen.
bye
Nop
Kannst ja das multipolygon wieder zu einer boundary umbauen. 
Spaß beiseite, das admin_centre wird als Rolle in die Relation gepackt, nehme ich an?
Spricht aus meiner Sicht nix dagegen.
Chris
Ganz so sicher waere ich mir da nicht.
Handelt es sich dabei einfach um einenen weiteren Wert (Key=Value), dann geht das vollkommen in Ordnung.
Handelt es sich dabei aber um ein neues Mitglied in der Relation in einer unbekannten Rolle, dann sollte auch das eigentlich nicht stoeren. Aber rein formell verletzt es dann die Defintion der multipolygon-Relationen, so dass irgendwelche Pruef-Tools zu recht daruerber meckern wuerden.
Vorsichtshalber wuerde ich das erstmal an ein bis zwei Beispielen ausprobieren und dann sehen, ob das irgendwo negativ auffaellt.
Ansonsten stoert es mich auch schon seit langem, dass die Grenzen hier in Deutschland so unsinnig erfasst sind. Wenn das also jemand zu boundary-Relationen umbauen will: Von mir aus gerne 
Gruss
Torsten
Ich habe das mal in Sachsen für Bundesland, Direktionsbezirke und Landkreise erstellt. Wenn man in die Label-Rolle den Node einer Stadt legt müsste das eigentlich auch die Darstellungsprobleme mit doppelten Stadtnamen u.ä. lösen (zumindest theoretisch, ob es die Renderer beachten ist natürlich ungewiss)
oder auch nicht?
eventuell haben wir demnächst dreifache stadbezeichnungen 
Habt ihr das mal in größerem Rahmen besprochen? Wie es getaggt wird ist mir persönlich Wurst. boundaries.pl kann ja auch mit beiden umgehen. Aber durch Osmosis Filter Ausdrücke wird daruch leider bei www.maposmatic.org verhindert, dass auch deutsche Städte-Grenzen auswertbar sind 
Ein admin_center macht ein Multipolygon kaputt.
Es ist nicht das ich es nicht sinnvoll finde aber das passt gut zu einem boundary. Leider haben wir in Deutschland aber multipolygone.
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