Relation Master Germany (1111111) Problem

#DWD* wrote:

Wieso kann mann die Relation Master Germany nicht einfach in Bundesrepublik Deutschland umbenennen und auf die Bundesrepublik Deutschland Relation verzichten? Werten einige Renderer das dann nicht richtig aus? Vielleicht kann wambacher als Ersteller was dazu sagen?

moin moin,

ja dieses "schöne" Teil hab ich vor einiger Zeit mal erzeugt (und dafür eine alte Relation recycled, da die id so klasse ist).

Mir wäre es natürlich auch recht, wenn die alte 51477 "sterben" würde, hab mich aber noch nicht getraut, die im Forum und auch unter talk-de anzusprechen.

Mapnik hat keinerlei Probleme mit verschachtelten Relationen und rendert das sauber.
Wie es bei anderen Programmen aussieht, ist mit nicht 100% bekannt.
Da verschachtelte Relationen (mit Eltern und Kindern) schon seid mehreren Jahren "erlaubt" sind würde ich auf ältere Programme keine Rücksicht nehmen.

Wichtig wäre es, zu wissen, ob die "Töchter" auch brav mit geändert wurden, da erst diese den eigentlichen Grenzverlauf beinhalten.

Gruss
Walter

2 Fragen dazu:

• Wieso erzeugst du eine neue (bessere) Relation, wenn du nicht vorhast, die alte (schlechtere) zu killen?
  

• Wieso der komische Name :-) Klar, der ist technisch begründet, in der Karte gerendet sieht das "leicht" größenwahnsinnig aus ;-)
  

Also laut den Informationen hier ist folgendes Vorgehen angesagt: Check, ob die "Töchter" ok sind, dann alte Relation killen. Doppelte Datenhaltung führt IMMER zu großen Problemen.

Viele Grüße,
Kay

wambacher wrote:

Mir wäre es natürlich auch recht, wenn die alte 51477 "sterben" würde, hab mich aber noch nicht getraut, die im Forum und auch unter talk-de anzusprechen.

Jetzt ist der Admin-Level 2 für Deutschland in den Daten doppelt vorhanden, nur der Name ist unterschiedlich. Das finde ich etwas unglücklich. "Master Germany" müsste m.E. auch mit name=Bundesrepublik Deutschland versehen sein, da diese Relation ja die Grenzen unserer Republik darstellt. Spricht für Dich etwas dagegen, Deine Relation so zu nennen? Das dürfte doch niemanden stören, oder doch? Auf jeden Fall sollte geklärt werden, ob unterschiedlich benannte Grenzrelationen gleichen Inhalts in den Daten in Ordnung sind.

wambacher wrote:

Wichtig wäre es, zu wissen, ob die "Töchter" auch brav mit geändert wurden, da erst diese den eigentlichen Grenzverlauf beinhalten.

Das sieht ganz so aus: http://www.flosm.de/html/Themen-Karte.h … 77024.8125 Wären die Relationen Master Germany und Bundesrepublik Deutschland nicht deckungsgleich, würden bei unserem SVG-Export "Differenzreste" auftauchen. Das ist aber nicht der Fall. Im Augenblick sind diese Grenzen identisch.

kay_D wrote:

• Wieso erzeugst du eine neue (bessere) Relation, wenn du nicht vorhast, die alte (schlechtere) zu killen?
  

Natürlich hab ich das vor -langfristig. die 51477 ist verdammt wichtig und selbst ich hatte Programme, in denen deren ID fest verdrahtet war.

@frederik: würde das bei euch Probleme machen oder verwendet ihr eh eure eigenen Borders zum Zuschneiden?

• Wieso der komische Name :-) Klar, der ist technisch begründet, in der Karte gerendet sieht das "leicht" größenwahnsinnig aus ;-)
  

War nicht so beabsichtigt. Kann/sollte man natürlich bald ändern.

Also laut den Informationen hier ist folgendes Vorgehen angesagt: Check, ob die "Töchter" ok sind, dann alte Relation killen. Doppelte Datenhaltung führt IMMER zu großen Problemen.

Klar, aber bevor ich MICH killen lasse, hab ich erst mal etwas abgewartet.

Gruss
Walter

wambacher wrote:

@frederik: würde das bei euch Probleme machen oder verwendet ihr eh eure eigenen Borders zum Zuschneiden?

Fuer die Geofabrik-Extrakte benutze ich statische Polygone, die nicht den OSM-Relationen entsprechen (sondern meistens irgendwann mal aus diesen automatisch erzeugt, leicht vergroessert und vereinfacht und dann manuell kontrolliert wurden).

Grundsaetzlich finde ich solche mehrstufigen Relationen fuer Grenzen vernuenftig, und in Frankreich werden die ja auch benutzt, aber es gibt viele Tools, die das nicht richtig auswerten und bei denen die Grenze dadurch hopps ginge. (Sind bestimmt auch viele von meinen darunter.) Ich halte es fuer sehr wahrscheinlich, dass die Grenze schnell wieder als neue "normale" Relation angelegt wuerde, wenn man sie entfernt, und dass es ausserdem eine Menge Protestgeheul gaebe. Andererseits gibt es ja das Sprichwort mit dem Hobel und den Spaenen 😉

Vielleicht koennte man darueber nachdenken, fuer eine Uebergangszeit die "normale" Deutschlandrelation irgendwie so zu taggen, dass man automatisch erkennen kann, dass die 111111 ein Doppel davon ist und umgekehrt, so dass verarbeitende Software sich dann entscheiden kann, welche sie auswertet? Man koennte ja jede Relation mit role=alternative in die andere aufnehmen oder so 😉

Kann auch nicht schaden, sich hierueber mit den Franzosen auszutauschen, denn die waren die Vorreiter bei deiser Art von Grenzmapping (http://wiki.openstreetmap.org/wiki/Fran … nstruction).

Uebrigens bin ich ein grosser Feind von type=boundary. Ich finde, das sollte type=multipolygon sein.

Bye
Frederik

woodpeck wrote:

...
Uebrigens bin ich ein grosser Feind von type=boundary. Ich finde, das sollte type=multipolygon sein.

Bye
Frederik

Kannst du die Gründe deiner Feindschaft mal näher erläutern.
Nur weil drei oder vier Länder (incl. Deutschland) weltweit multipolygon statt boundary für Grenzen verwenden, kann boundary doch nicht so verkehrt sein.

Wie heißt es doch immer:
Bei verschiedenen Möglichkeiten wird sich eine durchsetzen. Das ist dann wohl boundary.

wambacher wrote:

kay_D wrote:

• Wieso der komische Name :-) Klar, der ist technisch begründet, in der Karte gerendet sieht das "leicht" größenwahnsinnig aus ;-)
  

War nicht so beabsichtigt. Kann/sollte man natürlich bald ändern.

Wenn niemand Probleme damit hat, ändere ich den Namen der Relation Master Germany auf den Namen Deutschland
Gruß
Detlev

woodpeck wrote:

Uebrigens bin ich ein grosser Feind von type=boundary.

Ja, das ist bekannt. Ich bin ein Freund von type=boundary. 😉

Zurück zum Thema: Die Frankreich-Grenze wurde ja soviel ich weiss aus Größengründen
aufgeteilt. Besteht denn die D-Grenze auch aus so vielen Teilen, dass hier eine Pyramidenstruktur
angebracht ist ?

chris66 wrote:

Zurück zum Thema: Die Frankreich-Grenze wurde ja soviel ich weiss aus Größengründen
aufgeteilt. Besteht denn die D-Grenze auch aus so vielen Teilen, dass hier eine Pyramidenstruktur
angebracht ist ?

Da Deutschland keine Kolonien mehr hat, ist das eigentlich nicht der Fall 😉
Die Verwendung einer Pyramidenstruktur für Deutschland (wie bei der Relation Master Germany 1111111) verschafft Übersicht, da dort bereits klare Zuordnungen zu Grenzabschnitten (z.B. Deutschland-Niederlande) vorgenommen sind.
Ich finde das gut und würde diese Relation der Relation Bundesrepublik Deutschland (51477) vorziehen.

hurdygurdyman wrote:

Kannst du die Gründe deiner Feindschaft mal näher erläutern.
Nur weil drei oder vier Länder (incl. Deutschland) weltweit multipolygon statt boundary für Grenzen verwenden, kann boundary doch nicht so verkehrt sein.

Fuer eine Relation vom Typ Multipolygon gelten ganz spezielle Verarbeitungsregeln. Alle Programme, die etwas sinnvolles mit den Daten machen wollen, muessen eine Sonderregel dafuer eingebaut haben.

Es ist sinnvoll, fuer saemtliche Flaechendefinitionen den gleichen Relationstyp zu verwenden. type=multipolygon bedeutet, dass diese speziellen Flaechenkonstruktionsregeln angewendet werden muessen; was fuer eine Art Flaeche es ist, ergibt sich aus den weiteren Tags (z.B. boundary=administrative).

Dadurch kommen Programme mit einer einzigen Sonderregel aus.

Mir ist schleierhaft, wieso der type=boundary ueberhaupt eingefuehrt wurde; mit der gleichen Logik koennte ich einen Wald statt mit type=multipolygon mit type=wood taggen (und eine Lichtung dann folgerichtig nicht als role=inner, sondern als role=clearing...). Die Folge waere, dass in zig Programmen hardcodiert werden muss "if type=multipolygon or type=boundary or type=...". - Der type soll doch nur angeben, was es grundsaetzlich fuer eine Art von Relation ist, und meiner Ansicht nacht ist eine Landflaeche die gleiche "Art" von Relation wie ein Waldgebiet.

Wenn wir in API 0.7 einen neuen "area"-Datentyp einfuehren, dann werden die heutigen type=multipolygon und type=boundary ohnehin beide kommentarlos in einen Area-Typ ueberfuehrt, etwas anderes macht gar keinen Sinn.

Aus all diesen Gruenden ist es unvernuenftig, Grenzen mit type=boundary zu taggen. Aber eben gerade weil der Spuk mit 0.7 eh vorbei ist, mach ich mir da normalerweise keine Muehe mit, das zu argumentieren 😉

Bye
Frederik

woodpeck wrote:

...
Wenn wir in API 0.7 einen neuen "area"-Datentyp einfuehren, dann werden die heutigen type=multipolygon und type=boundary ohnehin beide kommentarlos in einen Area-Typ ueberfuehrt, etwas anderes macht gar keinen Sinn.

Aus all diesen Gruenden ist es unvernuenftig, Grenzen mit type=boundary zu taggen. Aber eben gerade weil der Spuk mit 0.7 eh vorbei ist, mach ich mir da normalerweise keine Muehe mit, das zu argumentieren 😉

Bye
Frederik

Ich hoffe auch, dass die API 0.7 zum Thema Flächen - auch im Sinne der Simple Features - ordentlich aufräumt und in sprachlicher und konstruktiver Hinsicht Klarheit bringt. Nur wann ist das? Mindestens seit Dezember 2009 wird diskutiert. ( http://wiki.openstreetmap.org/wiki/Talk:API_v0.7 siehe unter Brainstorming )

Danke, dass du dir die Mühe der Kommentierung für die wissensdurstigen OSMler, welche nicht so im Thema sind, gemacht hast.

woodpeck wrote:

Aus all diesen Gruenden ist es unvernuenftig, Grenzen mit type=boundary zu taggen. Aber eben gerade weil der Spuk mit 0.7 eh vorbei ist, mach ich mir da normalerweise keine Muehe mit, das zu argumentieren 😉

hallo frederik,

ich hab den type boundary eigentlich nur gewählt um eine leichte unterscheidung zur 51477 zu ermöglichen - für mich sind type=boundary und type=multipolygon inzwischen identisch.
Da sowieso fast (*) alle Programme, die Grenzen verarbeiten, dieses sauber machen, ist es doch inzwischen total egal, was hier angegeben wird. Und alle dahingehenden Diskussionen ebenfalls.
Daher sollte es dabei bleiben und natürlich mit 0.7 bereinigt werden.

Ich werde mich am Wochenende mal auf den Wechsel zur 1111111 stürzen und einige Checks und Anpassungen machen - ohne sogleich 51477 zu killen. Allerdings glaube ich, dass es IMMER ein Riesengeschrei geben wird, egal ob die heute oder in 5 Jahren stirbt.

Gruss
Walter

• ) das einzige, das sich da etwas störrisch verhält, ist der Osm-Inspector - keine Ahnung warum 😉
  

Also wenn sich niemand traut die alte Version zu loeschen mach ich das am Montag. 😉

chris66 wrote:

Also wenn sich niemand traut die alte Version zu loeschen mach ich das am Montag. 😉

Hi Chris,

ok, dann mach mal - kann ich wenigstens ruhig schlafen 😉

Ich hab die Tags von der 51477 rübergezogen aber type=boundary gelassen.
Somit sind die beiden bis auf diese "Kleinigkeit" identisch.

sollte man die Problematik vorher auch mal auf talk-de ansprechen oder nicht? Rein informativ, damit niemand aus allen Wolken fällt?
Viele lesen ja mit - aber halt nicht alle.

Gruss
Walter

das mit type=boundary stellt kein Problem dar, das wird schon jemand "reparieren". So geschehen auch mit meinen type=boundary die selbst auf admin_level 10 wie von Zauberhand wieder zu type=multipolygon wurden, irgendwann hab ichs dann sein gelassen. Warten wir einfach auf die API 0.7 (2012 ist sowieso Weltuntergang, also keine Eile).

Naja, MP geht ja nicht bei Pyramidenstruktur....

Ein weiteres Argument warum Boundaries eben keine normalen Polygonen sind. 😉

chris66 wrote:

Naja, MP geht ja nicht bei Pyramidenstruktur....

Ein weiteres Argument warum Boundaries eben keine normalen Polygonen sind. 😉

Um noch eins draufzulegen: josm akzeptiert seit einigen Tagen die Roles admin_centre und label innerhalb von Grenzrelationen - aber nur bei type=boundary.

Josm ist zwar nicht "die Welt" aber doch ziemlich hilfreich in solchen Sachen.

Gruss
walter

http://josm.openstreetmap.de/ticket/6792 erledigt in 4424

chris66 wrote:

Naja, MP geht ja nicht bei Pyramidenstruktur....

Ein weiteres Argument warum Boundaries eben keine normalen Polygonen sind. 😉

Die Anzahl der Programme, die eine Pyramidenstruktur bei boundary verarbeiten und bei multipolygon nicht, ist sehr klein. Meiner Ansicht nach sollte auch fuer Multipolygone grundsaetzlich eine Pyramidenstruktur zulaessig sein.

Bye
Frederik

In an attempt to compile a new map for Garmin devices, using mkgmap and the new index function to find cities and streets, I noticed that Germany disappeared from the European map. In my opinion it's not very wise to treat the German border different than other European borders. A boundary system, especially admin_level 2, should be consistent throughout Europe, otherwise it will be very difficult/impossible to create OSM based maps which cover more than one country.

navmaps_eu wrote:

In an attempt to compile a new map for Garmin devices, using mkgmap and the new index function to find cities and streets, I noticed that Germany disappeared from the European map. In my opinion it's not very wise to treat the German border different than other European borders. A boundary system, especially admin_level 2, should be consistent throughout Europe, otherwise it will be very difficult/impossible to create OSM based maps which cover more than one country.

hi,

the old relation is still online (id 51477) to give anybody a chance to switch to 1111111, which is a super-relation with boundary-segments.
Many other applications don't have any problems dealing with that.

I hope we will remove it in 2012.

Regards
walter

b.t.w: france is doing the same and austria may be the next one.

wambacher wrote:

navmaps_eu wrote:

In an attempt to compile a new map for Garmin devices, using mkgmap and the new index function to find cities and streets, I noticed that Germany disappeared from the European map. In my opinion it's not very wise to treat the German border different than other European borders. A boundary system, especially admin_level 2, should be consistent throughout Europe, otherwise it will be very difficult/impossible to create OSM based maps which cover more than one country.

hi,

the old relation is still online (id 51477) to give anybody a chance to switch to 1111111, which is a super-relation with boundary-segments.
Many other applications don't have any problems dealing with that.

I hope we will remove it in 2012.

Regards
walter

b.t.w: france is doing the same and austria may be the next one.

No, France is using ways in the border relation 1403916. The old german border relation does not include any border specific tags so it is not possible to use it with any program.

Edit: France has a second border relation 1362232 which is using the same super-relation approach.

navmaps_eu wrote:

In an attempt to compile a new map for Garmin devices, using mkgmap and the new index function to find cities and streets, I noticed that Germany disappeared from the European map. In my opinion it's not very wise to treat the German border different than other European borders. A boundary system, especially admin_level 2, should be consistent throughout Europe, otherwise it will be very difficult/impossible to create OSM based maps which cover more than one country.

Die Grenzen werden derzeit auf Super-Relationen umgestellt.
Das Programm welches die Border-Files für mkgmap erstellt sollte entsprechend damit umgehen können.
Notfalls kann man zur Zeit noch die alte Relation (51477) dort händisch mit berücksichtigen.

chris66 wrote:

navmaps_eu wrote:

In an attempt to compile a new map for Garmin devices, using mkgmap and the new index function to find cities and streets, I noticed that Germany disappeared from the European map. In my opinion it's not very wise to treat the German border different than other European borders. A boundary system, especially admin_level 2, should be consistent throughout Europe, otherwise it will be very difficult/impossible to create OSM based maps which cover more than one country.

Die Grenzen werden derzeit auf Super-Relationen umgestellt.
Das Programm welches die Border-Files für mkgmap erstellt sollte entsprechend damit umgehen können.
Notfalls kann man zur Zeit noch die alte Relation (51477) dort händisch mit berücksichtigen.

Also irgendwie finde ich das nicht gut. Es wurde immer Frankreich Beispiel angeführt, dass Super-Relationen funktionieren. Nun stimmt das gar nicht, da Frankreich zwei Grenzrelationen hat, eine Super-Relation und eine normale. Daher wäre es mal interessant zu wissen, wo die Erkenntnis, dass die meisten Programme damit umgehen können, überhaupt herkommt und wer jetzt entschieden hat, dass die Grenzen als Super-Relation zu erfassen sind. Im Wiki steht, dass die Mitglieder einer Boundary Relation Wege sind. Ich recycle die alte 51477 mal wieder
Btw mkgmap selber erstellt die Grenzfiles und kommt damit nicht klar.

SunCobalt wrote:

Also irgendwie finde ich das nicht gut. Es wurde immer Frankreich Beispiel angeführt, dass Super-Relationen funktionieren. Nun stimmt das gar nicht, da Frankreich zwei Grenzrelationen hat, eine Super-Relation und eine normale. Daher wäre es mal interessant zu wissen, wo die Erkenntnis, dass die meisten Programme damit umgehen können, überhaupt herkommt und wer jetzt entschieden hat, dass die Grenzen als Super-Relation zu erfassen sind. Im Wiki steht, dass die Mitglieder einer Boundary Relation Wege sind. Ich recycle die alte 51477 mal wieder
Btw mkgmap selber erstellt die Grenzfiles und kommt damit nicht klar.

das ist genau dass, was ich befürchtet habe: einer kommt nicht sofort klar damit und macht alles rückgängig.
ich hatte mit dem autor der französischen rels gesprochen und er erlärte mir, dass er die "normale" france-relation nur deshalb erstellt habe, weil SEIN programm mit der französischen super-relation nicht klar komme.
Inwischen braucht er die "normale" relation nicht mehr, traut sich aber ebenfalls nicht, diese zu löschen.

solange wir die 51477 noch mitschleppen, sind aller verbesserungen hinfällig. der eigentliche vorteil der arbeitserleichterung beim editieren ist somit nicht mehr gegeben.

walter

ich finde die neue Art Grenzen zu mappen auch viel besser. Aber Du kannst den Autoren der Programme keine Schuld geben. Ausser in diesem Thread steht nirgendwo, (nicht auf der Tagging-ML, kein Proposal, Wiki sagt auch das Gegenteil), dass auch Relationen Mitglieder der Grenzrelation sein können sondern es steht klipp und klar, dass das Ways sein sollen. Und woher weißt Du, dass es nur ein Programm ist, dass damit Probleme hat? Die anderen haben es vielleicht nur noch nicht bemerkt.
Ich habe mal eben den OSM Relation Analyzer mit der 1111111 gefüttert da ich den gern benutze. Der kommt mit der Super-Relation auch nicht klar. Damit wären es schon zwei Programme. Es finden sich sicher einige mehr.

Also die Super-Relas löschen? Weil doppelte Grenzen sind ja auch Käse.

chris66 wrote:

Also die Super-Relas löschen? Weil doppelte Grenzen sind ja auch Käse.

nee, die Idee ist ja sehr gut. Proposal erstellen und danach Wiki ändern und dann mit den Programmautoren schimpfen. Aber dann hatten sie auch Zeit, sich darauf einzustellen. Solange die deckungsgleich sind, stören die ja nicht.

Ich stell mir gerade dei Frage, ob es sinnvoll ist, ein bestehendes und auch funktionierendes System zu ändern. Vorallem mit dem Hintergrund, dass das System an sich in der nächsten API-Version ohnehin erledigt sein wird.

aighes wrote:

Ich stell mir gerade dei Frage, ob es sinnvoll ist, ein bestehendes und auch funktionierendes System zu ändern. Vorallem mit dem Hintergrund, dass das System an sich in der nächsten API-Version ohnehin erledigt sein wird.

Bestehend stimmt natürlich.
Funktionierend, na ja. Sobald es an große Gebilde wie Staaten geht, gibt es immer wieder mal Probleme, weil jemand nicht genau übersehen hat/konnte, welche Nebenwirkungen seine Änderungen haben. Relationen mit mehreren hundert oder gar tausend Mitgliedern sind nun einmal äußerst unhandlich. Fernwander- und Fernradwege werden aus diesem Grunde gerne mal in mehrere Abschnitte unterteilt und per Superroute die Teilstücke wieder zusammengefügt.

Das System wird sich nicht mit der nächsten API_Version erledigt haben. Schließlich ist der Streit Multipolygon (~= Fläche) und Boundary (~= Grenzlinien) keineswegs entschieden. Außerhalb von DE und einigen umliegenden Ländern ist Multipolygon für Grenzen eher ungewöhnlich. Und selbst in DE werden Multipolygone keineswegs flächendeckend für Grenzen verwendet.

Auf die API V0.7 würde ich im Augenblick auch lieber nicht setzen. Die kommt meiner Einschätzung nach erst nach der Lizenzumstellung, welche eher Mitte nächsten Jahres als früher stattfinden wird. Damit ist der Zeithorizont für die nächste API-Version eher Ende als Anfang nächsten Jahres.

Edbert (EvanE)

SunCobalt wrote:

Solange die deckungsgleich sind, stören die ja nicht.

"nicht" ist übertrieben. 😉
Es widerspricht dem KISS Prinzip, verschwendet Resourcen, und in Mapnik
erscheinen diese Grenzen "fetter" als nicht-doppelte Grenzen (soviel ich weiss).

Als einer der "lahmen" Programmautoren, die die Programme nicht vor einem Proposal schon in vorauseilendem Gehorsam fertig gestellt haben, möchte ich hier kurz meine "2 cents" beisteuern:

• Der Vorteil der Subrelationen mit Teilen der Grenze erschließt sich mir nicht. Die Subrelationen sind genauso Relationen und daher können beim Editieren Fehler eingebaut werden. Dies passiert derzeit regelmässig und dafür gibt es meines Erachtens auch keine reale Verbesserungsmöglichkeit. Große Struktur => Viele Möglichkeiten für Fehler.
  

• Wie Ihr (OSM community) es letztendlich realisiert, ist mir relativ egal. Aber macht es einheitlich. Ich werde keine Einzellösung für ein oder zwei Länder implementieren. Ich kann nur jedem die Lektüre des mkgmap Source Codes, der sich um das Handling der Multipolygone kümmert, empfehlen. Dort werden recht starke Klimmzüge veranstaltet, nur um allen Tagging-Varianten (nur die Wege, nur das Multipolygon, beides taggen, gemischtes Taggen etc.) der Multipolygone gerecht zu werden. Baut bitte nicht ein weiteres Moloch dieser Art! Also bitte erst einig werden (oder eine Mehrheit entscheiden lassen), dann ordentlich und sauber im Wiki dokumentieren mit klaren Regeln und zuletzt den Schalter umlegen.
  

By the way: ich bin nur durch Hinweise auf diesen Thread aufmerksam geworden. Anderen Programmautoren wird es ähnlich gehen...

Have fun!
WanMil

WanMil wrote:

Also bitte erst einig werden (oder eine Mehrheit entscheiden lassen), dann ordentlich und sauber im Wiki dokumentieren mit klaren Regeln und zuletzt den Schalter umlegen.

+1

Hallo,

bei der Suche nach der "echten" Relation der deutschen Außengrenze bin ich auf diesen Post gestoßen.
kurze Frage ... die geführte Diskussion ist schon fast 6 Jahre alt und es gibt immer noch 2 Relationen ...
Ich wurde im Wiki nur bedingt fündig und die Fülle an Informationen ist schlicht überwältigend ...
Das nehme ich mit (20170214 - http://wiki.openstreetmap.org/wiki/Relation:boundary)

• Grenzen werden mit type=boundary getaggt
  
• Die Member einer "border"-Relation sollen Wege sein, keine weitere Relations (Way --> outer --> The multiple ways that form the closed border)
  

--> Die Relation 1111111 ist somit "weniger richtig" als 51477 ?
Die Tags unterscheiden sich minimal

Für Hinweise in eine Richtung wäre ich dankbar 😉

Die Relation 1111111 ist somit "weniger richtig" als 51477 ?

Ja, kann man so sehen, weil mehrstufige-boundary-relations immer noch "experimentell" sind.

Das ist ja mein "Baby". Ich hab es damals "gezeugt", da ich das Problem mit den verschachtelten Relationen aktiv testen wollte.
Leider spielt keine Software so richtig mit - noch nicht einmal Josm.

Nun, ihr könnt das löschen oder auch stehen lassen. Ab und zu schau ich mal nach, ob Josm das endlich verarbeiten kann.

Erlaubt sind diese Konstrukte ja, werden aber irgendwie doch stark vernachlässigt.

Gruss
walter

ps: es gibt noch viele andere rekursive Rels, deren Sinn wohl auch unklar ist.