Ich würde gerne mal die place=state Nodes für Hamburg und Berlin entsorgen, möchte aber jetzt keine Editierkrieg starten und deshalb mal die allgemeine Meinung einholen.
Diese Art der Node-Duplizierung ist in OSM unüblich. Normalerweise wird nur ein place-Node gesetzt mit dem umgangssprachlichen Typ, also hier place=city. In Deutschland halten wird das zum Beispiel bei den kreisfreien Städten so. Da wird man immer nur einen place=city-Node finden, keinen place=county-Node. Die Tatsache, dass Hamburg und Berlin Stadtstaaten sind, drückt sich dann im admin_level=4 der zugehörigen administrativen Grenze aus.
Ich würde also einfach das Tagging der Stadtstaaten an das Tagging der kreisfreien Städte angleichen wollen.
Die Relation hat 2 admin_centre
Das widerspricht definitiv der mir bekannten Spezifikation,
und das der Hamburgische Verwaltungssitz nun gerade mitten in einer Kirche oder aber im Wasser liegt erscheint mir auch suboptimal.
Vielleicht einen zum “label”? - jedenfalls Handlungsbedarf …
M.E. sollten wir diese place nodes für großen Verwaltungseinheiten bzw. Gebietskörperschaften einfach ignorieren, die braucht kein Mensch, und so Begriffe wie county oder state haben im deutschen Kontext sowieso keine Bedeutung. Mit admin boundaries und ggf. spezifischen Tags mit dem echten Begriff ist das Thema ausreichend abgedeckt,
ein paar Länder nutzen dafür admin_type:Land z.B. die Franzosen: https://taginfo.openstreetmap.org/search?q=admin_type
In Deutschland evtl. admin:title? Ich habe deutsches admin-Tagging zwar nicht parat, aber dass es nicht mit place nodes gemacht werden sollte bin ich mir recht sicher
Bei Städten haben nodes ja ihre Berechtigung (Zentrum etc.), aber bei Landkreisen, Bundesländern und Staaten ist das ein Relikt vergangener Zeiten als wir noch keine Grenzen hatten.
Als admin_centre kann man die Stadt-nodes verwenden, dafür braucht man auch keine Grafschaften in Deutschland.
Es geht mir nicht darum die Verwendung von place-Nodes und admin-Boundaries grundsätzlich in Frage zu stellen oder neue Tagging-Schemata zu erfinden. Das funktioniert einigermassen so, wie es jetzt ist, ohne, dass man Spezialfälle für Deutschland konstruieren muss. Es geht nur darum, dass zwei Nodes für den gleichen Ort einfach schlecht sind. Ja, da kann man drumherum arbeiten. Es wäre aber besser, wenn man das nicht muss.
Ich habe auch kein Problem damit, alle 16 place=state-Nodes zu löschen, wenn das die bevorzugte Lösung ist.
Ich wäre für Vereinigen der beiden Nodes und verschieben auf den Sitz des Hauptverwaltungszentrum.
Ich persönlich halte von “label” generell überhaupt nichts. Für mich ist das ausschließlich der Versuch, ein Rendering eines Namens an einer bestimmten Stelle zu erzwingen, was aber je nach individueller Anforderung so niemals zur Zufriedenheit funktionieren wird.
sind ja nicht 2 nodes für einen Ort, ist ein Node für das Land und einer für die Stadt. Wenn man place= nicht grundsätzlich in Frage stellen will, kann man den node auch lassen.
Das ist dem Fragesteller doch vollkommen klar. Seine Frage beruht darauf, dass Stadt und Land in diesem Fall geographisch identisch sind (administrativ natürlich nicht). Eben genauso wie bei kreisfreien Städten Stadt=Landkreis ist.
ich verstehe es ehrlich gesagt nicht. Was soll ein node mit place=state denn bedeuten? Ist das nicht grundsätzlich überflüssig und zusätzlich eine Verletzung der one element Regel? Es gibt ja schon das entsprechende admin_level=4 Objekt als Relation mit weiteren tags und allem drum und dran.
Wenn man das nicht in Frage stellen will, dann sollte man m.E. bei den kreisfreien Städten auch noch die “fehlenden” place=Grafschaft eintragen. Auf Ausnahmen und Sonderregelungen sollten wir möglichst verzichten, das macht das ganze noch undurchdringlicher, wo man erstmal 5 Jahre OpenStreetMap studiert haben muss bevor man überhaupt dran denken kann was einzutragen.
Jetzt bin ich an der Reihe, dich nicht zu verstehen. Erst verteidigst du die zwei Nodes, weil einer für die Stadt und einer für das Land steht, also zwei unterschiedliche Objekte – und jetzt argumentierst du ebenso vehement für das Gegenteil?
Ein place=state ist überall dort entbehrlich, wo die entsprechenden Grenzen als admin-level gemappt sind. Aber das gilt für alle anderen Ebenen bis zu place=hamlet auch, so dass wir für place eigentlich nur noch isolated_dwelling und locality brauchen, die vermutlich keine gemappten Grenzen haben. Interessanter Ansatz
Das mit den Place-Nodes und label-Rollen ist komplizierter und hat nur bedingt etwas mit Rendering zu tun. Place-Nodes enthalten eine andere Art von Information als administrative Grenzen: Zum einen enthält der Place-Node den Typ eines Objekts (also, Stadt, Dorf, Staat), während Grenzen den administrativen Typ enthalten (Bundesland, Kreis, etc). Beides ist wichtig zu haben, je nach dem, was man machen will. Zum anderen kennzeichnet der Place-Node bei Siedlungen den Ortsmittelpunkt. Dieser ist nicht einfach so aus einem Grenzpolygon ermittelbar, weil es etwas mit Siedlungsstruktur zu tun hat. Der Ortsmittelpunkt wird aber sehr wichtig, wenn es z.B. ums Routing geht. Wenn man dem Router sagt, dass man von Würzburg nach Bielefeld möchte, dann erwartet man, dass die Route von Stadtmitte zu Stadtmitte berechnet wird und nicht vom Zentroiden der administrativen Fläche, der auch gerne mal mitten im Stadtwald liegt.
Lange Rede, kurzer Sinn. Für Siedlungen sollte immer place-Node und Grenze vorhanden sein. Und die ‘label’-Rolle ist eine gute Möglichkeit um auszudrücken: diese beiden OSM-Objekte stellen zwei Aspekte des gleichen Ortes dar. Dass das Konstrukt nun unglücklicherweise ‘label’ heisst, ist halt ‘historisch gewachsen’. (Fälschlicherweise wird gerne wird dafür oft die ‘admin_centre’-Rolle verwendet, aber diese Rolle bezieht sich nicht zwingend auf den gleiche Ort. Es geht ja darum, welcher Ort die entsprechende Grenze verwaltet.)
Wenn das so ist, wäre tatsächlich bei Hamburg und Berlin allein der Citiy-Node angebracht und der State-Node sollte gelöscht werden. Es handelt sich um Städte, die admistrativ zusätzlich noch den Status eines Bundeslandes haben.
Ich versuche mal, das zu erklären: meiner Meinung nach brauchen wir für alle “Objekte”, die nur ein administratives Konstrukt repräsentieren, keine place Objekte. Nie. Die sind schon repräsentiert durch die admin-Relationen. Wenn da noch ein Schlüsselwort fehlen sollte (sowas wie “Kreisfreie Stadt” oder “Bundesland”, also die Bezeichnung der Art des begrenzten Gebiets) kann man das über tags dort in den Relationen ausdrücken. Wenn man nun aber für administrative Einheiten, die es nur administrativ und nicht unabhängig von der derzeitigen Verwaltungsstruktur gibt, place-nodes gut findet (ich nicht), dann käme es mir logisch vor, wenn man die auch für alles macht, und nicht noch seltsame Ausnahmen wie “es wird nur der umgangssprachliche Typ gesetzt und der Rest weggelassen” einbaut, die allen das Leben noch schwerer machen. Diese Doppelung der administrativen Objekte als Place-Punkte macht es für die Mapper nur schwieriger bis unmöglich, zwischen place und admin einen Unterschied zu erkennen. Mit null Zugewinn.
Bei Siedlungen ist die Lage anders, die gibt es unabhängig von admin, und daher ist place genau richtig dafür. Es gibt bei Siedlungen zwar meist/oft auch ein entsprechendes bzw. gleich- oder ähnlichnamiges Admin Gebiet, aber das kann durchaus auch andere Grenzen haben, und ist davon losgelöst (Admin-Gebiete teilen das komplette Land einschließlich Wäldern, Feldern, etc.), Siedlungen sind meistens nur ein Teil der entsprechenden Admin-Fläche). Auch können mehrere Siedlungen in derselben Admin-Fläche liegen. Siedlungen können auch außerhalb ihrer eigentlichen Admin-Fläche weiterwachsen, wobei das evtl. ein Punkt ist, der hier umstritten sein könnte, siedlungsgeographisch würde ich es zwar so sehen, aber solange wir nicht über place-Flächen reden ist es im Prinzip auch nicht so wichtig fürs reale Kartieren.
Wie Lonvia schon erklärt hat, bei Siedlungen gibt es mehrere geographische Eigenschaften die interessieren: die Fläche/Ausdehnung/Form (way/polygon) und die “Mitte” (node), so dass man beides “braucht” um diese Felder abzudecken. Das ist bei Staat, Bundesland, Kreis aber nicht gegeben, im Gegenteil, schaut Euch doch mal Deutschland an, hier ist es: https://www.openstreetmap.org/#map=19/51.08336/10.42346
Kann da bitte mal jemand hinfahren und kontrollieren, was da on the ground ist?
@dieterdreist: Ich stimme weitgehend zu, bei admin-Flächen kann es aber in Sonderfällen bei z.B. exotischer Geometrie für den Renderer hilfreich sein, per label-node eine Hinweis zu haben, wo der Name so plaziert werden kann, dass er noch im Gebiet liegt.
Im admin-Umfeld ist die OTG-Regel nicht besonders zielführend, Informationen zum Gebiet gehören mMn jedoch stets in die Relation und nicht auf place- oder gar label-nodes.
Siedlungs-nodes (place) sind sinnvoll als allererste Information in “weißen Flecken” sonstwo in der Welt und als Träger von Informationen, die nicht in admin-Relationen untergebracht werden können (Beispiele s.o.).
Bei größeren Flächen sind sie aber extrem wartungsunfreundlich, da man sie da nur sehr schwer bzw. umständlich findet.
So hat man zu den mehreren OTG-Mitten Deutschlands (je nach Messmethode, mit Tafel etc) auch noch eine OSM-Mitte .
Olala, der Node ist aber völlig an der falschen Stelle. Der gehört nämlich zum Landkreis Karlsruhe, der etwas anderes ist als die kreisfreie Stadt Karlsruhe. Ich fixe das mal gerade.
Weil das aus den Daten nicht ersichtlich ist und deswegen bei der Verarbeitung eben zwei Orte herauskommen, obwohl es nur einen gibt. Das kannst du recht genau bei der Suche sehen. Bis gestern gab es für Berlin und Hamburg jeweils zwei Suchresultate und dann gibt es immer wieder Beschwerden.
.