Tags sind
boundary administrative
de:amtlicher_gemeindeschluessel 0841
name Region Neckar-Alb
note no matching admin level available
source LGL, www.lgl-bw.de
type boundary
wikidata Q650566
wikipedia de:Region Neckar-Alb
Kann es sein, dass wir boundary=administrative taggen, aber es keinen passenden admin_level gibt? Oder sollte das eher eine andere Art von boundary sein? Oder evtl. einen neuen admin_level einführen?
Laut Wikipedia ist das eine Raumordnungs- und Planungsregion, und die Grenzen sind durch die Landkreise Tübingen und Reutlingen sowie Zollernalbkreis definiert. Wäre es da nicht sinnvoller, die Region mit nur 3 Membern (nämlich den entsprechenden Relationen dieser 3 Landkreise) zu bauen? Das hätte den Vorteil, dass sich die Grenzen automatisch anpassen, sollten sich die Landkreisgrenzen ändern, und es entspricht auch eher der Realität, die Region würde in OSM so definiert wie sie auch in der Realität definiert sind.
Der passende müsste sozusagen 5,5 sein …
Denn der Regionalverband wäre ja einsortiert zwischen
Regierungsbezirk – admin_level=5
und
Kreis – admin_level=6
Naja, ich würde mal annehmen, dass die ganze Relation ohnehin eine “Zweitverwertung” der vorhandenen boundary-Elemente ist.
Test: https://www.openstreetmap.org/way/60450552
insofern werden deren Änderungen ohnehin übernommen, zusätzlichen Wartungsaufwand kann ich nicht erkennen.
Schön wäre es allerdings, wenn man Geodatenbank relevante Kerninformationen wie “Laut Wikipedia ist das eine Raumordnungs- und Planungsregion, und die Grenzen sind durch die Landkreise Tübingen und Reutlingen sowie Zollernalbkreis definiert.” schnell und einfach im description-Tag nachlesen könnte, statt dafür die Wikipedia bemühen zu müssen.
Die Wirklichkeit ist sogar noch komplizierter: Teilweise werden in den Regionen die Abgeordneten bei den Kommunalwahlen direkt gewählt, man müsste ihnen also von der Bedeutung und der politischen Struktur her einen eigenen admin_level zugestehen, viel eher noch als z.B. den AL=7 der Verwaltungsgemeinschaften.
Zwischen 5 und 6 ist aber kein Platz mehr, dafür bleibt AL=3 in DE unbelegt - Entwurfsfehler, Pech gehabt.
Damit nicht genug, einige Regionen gehen sogar über Ländergrenzen hinweg, schneiden also AL=4 - Linien.
Ich würde sie aber zumindest gleich wie alle anderen admin-Einheiten behandeln, also das Gebiet über die (vorhandenen) boundary-Linien definieren.
Die Definition über die Mitglieds-Kreise entspräche dem mancherorts beliebten, woanders aber ungeliebten subarea-Tagging, das aber mW immer nur zusätzlich zum boundary-Tagging in den Relationen gemacht wurde.
na hoffentlich, wenn man auch noch überlappende Wege verwenden würde wäre es natürlich absurd.
die Änderungen werden dann übernommen wenn der Mapper erkennen kann, dass sich mit dem Landkreis auch die Region ändern soll, das ist im Moment nicht so gemappt (sondern es sind einfach “zufällig” überlappende Grenzen)
der description tag ist nicht besser als die Wikipedia, schön wäre es, wenn wir dafür strukturierte tags hätten. Dass das Teil aus den Landkreisen besteht wäre dadurch gemappt, dass man es aus den Landkreisen aufbaut, ganz einfach.
Das ist bei allen anderen admin-Relationen genau so der Fall. Nicht immer lässt sich eine admin-Einheit aus Einheiten mit niedrigem hierarchischem Level zusammensetzen. Das hätte man theoretisch durch dummy-Gebiete für die Lücken beheben können, aber das hat man nicht gemacht, sondern den Weg über die Grenz-Linien eingeschlagen.
In BW und den Nachbarländern sind die Regionen mW ausschließlich aus AL6-Gebieten aufgebaut, aber das muss nicht so bleiben. Dann hätte man mit dem subarea-Ansatz ein Problem.
Das Ändern einer Grenzlinie ändert übrigens automatisch alle Relationen, in denen diese Linie Member ist. Der Mapper muss dazu gar nicht wissen, was worin enthalten ist - das ist in der Struktur der Daten festgelegt. Nur wenn ein Kreis in eine andere Region wechselt, ist der Aufwand etwas höher. Bei solchen Verwaltungsreformen bleibt aber in der Regel auch auf den unteren Hierarchien kein Stein auf dem anderen und man käme mit einem Umordnen von Untereinheiten auch nicht sehr weit.
Das habe ich erst vor kurzem in Nepal mit ein paar Hundert admin-Relationen durchexerziert.
Stimmt, das ist ein grundsaetzliches Thema. Es hat ja auch Nachteile, wenn man das jeweils verschachtelt aufbaut, weil man dann z.B. Deutschland nur noch geometrisch bestimmen kann, indem man Schritt fuer Schritt von den Gemeinden alles aufbaut bis man beim Land ist. Das will man sicher auch nicht.
Wenn es Luecken geben wuerde dann kann man es m.E. mit subareas nicht machen, entweder es ist gleich wie a+b+c oder es ist was eigenes.
aber kein echtes Problem, man wuerde einfach davon Abstand nehmen, wenn es wirklich zu einer Aenderung dieser Gebietsgrenzen unabhaengig von den Landkreisgrenzen kaeme, und die eigenstaendigen Grenzen auch eigenstaendig definieren.
Das ist schon klar, nur muss man dazu wissen, dass die Grenzen der Region die des Landkreises sein sollen, weil wenn man sonst die Landkreise aendert und sich nicht um die Regionen kuemmert (also die so lassen will wie sie sind), dann wird man sie absichtlich nicht aendern. Es sind ja Menschen die die Daten bearbeiten, die machen das so wie sie denken dass es sein soll, und im Zweifel lassen sie den Teil mit dem sie sich nicht auseinandersetzen wollen, so wie er ist.
Dann müssten sie aber, statt ein paar nodes zu verschieben, die Grenzlinie komplett neu erstellen und an die alte Grenze nach Aufspalten ansetzen. Bei PLZ-Grenzen mit kleinen Abweichungen von den Gemeindegrenzen kommt so was schon vor, das ist aber etwas kniffelig und nichts für Ungeübte. Im Relationseditor führt da an der Liste, in welchen Grenzrelationen die alte Grenzlinie enthalten war, kein Weg vorbei. Wer dann nicht merkt, dass die Grenze des Landkreises bisher auch die der Region war, dem ist nicht zu helfen.
Wer sich dessen nicht sicher ist, sollte mMn nach die Finger von Grenzänderungen lassen.
Aber da sind unsere Ansichten vermutlich verschieden und von mir aus können wir es dabei auch lassen.
Du erfährst dass sich die Landkreisgrenzen von 2 Landkreisen verschieben.
Du machst Dich ans Bearbeiten in OSM.
Dabei bemerkst Du, dass es noch andere Grenzrelationen auf diesen ways gibt.
Du kannst nun entweder einfach alle Grenzen so ändern wie die Landkreise geändert werden müssen, oder Du änderst nur die Landkreise und lässt den Rest so wie es ist. Was davon richtig ist kommt drauf an. Wenn man nur die Landkreise ändert ist man auf der “sicheren” Seite, weil selbst wenn die anderen Grenzen auch geändert werden müssten, durch das Nichtändern bleiben sie maximal “veraltet”, aber man wird nicht aus Versehen einen neuen Fehler einfügen was passieren könnte, wenn man die Grenzen einfach alle so ändert wie die Landkreise.
Wenn die Regionen schon über die Landkreise definiert wären (und wenn sie das auch in der Realität sind), dann würde man automatisch die Regionen beim Ändern der Landkreise mitändern ohne dass man sich damit beschäftigen muss.
“Verschieben” kann geometrisch so einiges, sehr unterschiedliches sein, und wer Grenzrelationen bearbeitet sollte sich unbedingt vorher eine Strategie überlegen, was er verschiebt und wie er verschiebt um gegebenenfalls notwendige Nacharbeiten gering, im Idealfall bei 0 zu halten.
Es ist doch niemand gehindert, (sich) die Region aus den Landkreisen zusammenzusetzen.
Die Außenumfahrung ist halt eine zusätzliche Möglichkeit.
Die Außenumfahrung ist der Standard bei admin-Relationen, alles andere ist dort optionaler Zusatz.
Ich sehe keinen zwingenden Grund, ausgerechnet bei Regionen von diesem Schema abzuweichen, auch wenn für die kein admin_level mehr übrig ist.
… sehe ich genauso, die Außenumfahrung ist das, was ein Datennutzer erwartet, wenn er eine definierte boundary-Area “bestellt”. Ungefragt gelieferte Binnengrenzen sind ein Mangel. Wer (zusätzlich) Binnengrenzen möchte, bestellt die extra.
Lassen wir das mit der Art der Abbildung mal außen vor (m.E. wäre es theoretisch/konzeptionell schöner, die Sachen jeweils aus den “echten” Bestandteilen aufzubauen, anstatt sie nur “zufällig” an gleicher Stelle liegen zu haben, aber technisch ist das zumindest bei den derzeitigen Tools nicht sinnvoll bzw. geradezu ein sich selbst in den Fuß schießen).
Sind die Regionen also allgemein anerkannte Admin-Relationen die mit
boundary=administrative
getaggt werden sollen?
M.E. sollte die Sache mit dem admin_level irgendwie gelöst werden, ggf. auch mit einem Wert wie 5.5
Offensichtlich sind (mind.) 2 davon in größeren Regionen integriert/aufgegangen. In der wikipedia scheint mir das gut dokumentiert, in OSM dagegen ist das wohl im name-Tag “kodiert” per (BW). Möchte nochmal alle auf den description-Tag und seine Möglichkeiten hinweisen …
