wir sind beim Auswerten des Planets über die Relation: Master Germany (1111111) gestolpert. Diese Relation ist deckungsgleich mit der Relation Bundesrepublik Deutschland (51477). Beide Relationen sind als boundary=administrative, admin_level=2 getaggt. Dadurch entstehen zwei übereinander liegende Polygone, eins mit name=Bundesrepublik Deutschland, das andere als name= Master Germany.
Die “schönere” Relation ist natürlich die Master Germany. Da wir für unsere Kartendarstellung verschachtelte Relationen auswerten haben wir damit beide Grenzen in der Karte. Wie sollen wir nun herausfinden, welche der beiden admin_level=2 die “richtige” Grenze ist bzw. von welcher wir die Beschriftung nehmen müssen?
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?
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.
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.
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.
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
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.
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 ?
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.
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
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.
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
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.
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).
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.
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.
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.
Klar, der ist technisch begründet, in der Karte gerendet sieht das “leicht” größenwahnsinnig aus 
