Konkretes sinnvolles Beispiel: Jede Relation einer Verwaltungseinheit.
Mit dem label-node in der Relation wird nur die Position angegeben:
Es wird kein label-Text angegeben, denn der Name befindet sich ja bereits in der Relation!
Dieser node braucht auch kein place-tag, denn im ländlichen Raum ist Gemeinde != Siedlungsplatz - und oft enthält eine Gemeinde ja auch mehrere verschiedene Siedlungsplätze.
Ein Renderer sollte durchaus beide Namen - unterschiedlich formartiert - anzeigen, selbst wenn sie gleichlautend sind.
Ja, man kann/sollte alle Tags rauswerfen. Vorher aber bitte prüfen, ob an dem Node Tags stehen, die in der Grenzrelation fehlen. Diese sollten (wenn es Sinn macht) an die Grenzrelation “gepappt” werden.
Was man bei widersprüchlichen Tags machen sollte, bleibt hier erstmal offen.
Evtl noch ne Note dran, die das beschreibt, damit nicht irgendwer wieder alles rückgängig macht.
@wambacher, bei meiner beispielhaften Landkreis Kassel Überarbeitung werfe ich gerade einige Tags raus, führe aber keinen Krieg gegen place-nodes, weil ich nicht weiß, wer die so nutzt und braucht, insbesondere beim name-Rendering. Insofern wird und soll sich z.B. auf der Standardkarte dort auch nicht viel ändern.
[Früher angefangen und jetzt erst gesendet - mag nicht nochmal alles überarbeiten, auch wenn das Meiste schon von Anderen angesprochen wurde.]
Moin,
Ich betrachte solche (Verwaltungsklassen-) nodes als Altlasten aus der Vor-Grenz-Relation-Zeit, ja.
Sie sind redundant in Ihren Informationen und - bei solchen Flächen - als label ziemlich nutzlos.
Und darauf ziele ich ab - für mich sind einige Deiner Beispiele nicht unbedingt Verbesserungen:
name=, place= sind eben nicht notwendig, denn - siehe Fettgedrucktes.
place=town für Kaufungen ist in meinen Augen falsch - es gibt eben (wie Du ja selber schreibst) keinen Ort dieses Namens (auch wenn er in der Öffentlichkeit so aufgefasst werden mag), insofern darf er auch nicht als (Siedlungs-)Ort, sondern eben nur als Gemeinde gerendert werden.
Ich würde den node als admin_centre ohne weitere Daten (weder name noch place) in die Relation aufnehmen.
Ein extra label-tag halte ich bei dieser Form der Relation nicht für nötig.
Dies alles bezieht sich wohlgemerkt auf Verwaltungseinheiten, die zumindest in Deutschland über Grenzrelationen abgebildet sind.
Bei Siedlungsplätzen mit schwammiger Grenz-Definition sind Punkte nicht immer zu vermeiden - das sehe selbst ich ein.
@GeorgFausB, wenn Du oder irgendjemand sonst eine grundsätzliche Abneigung gegen place-nodes hat, dann wird dies in diesem thread nicht zu lösen sein…
Die bisher einzig konkrete Kritik an meiner Überarbeitung aller Gemeinden im Landkreis Kassel, scheint mir also zu sein, dass das in den letzten Jahren gewachsenen Kaufungen (> 10 000 Einwohner in einem geschlossenen Siedlungsgebiet), vgl. auch http://www.kaufungen.eu/media/custom/417_6479_1.PDF?1375333703
nunmehr genauso als town daherkommt, wie seit 8 Jahren(!) das benachbarte Lohfelden (> 10 000 Einwohner in einem geschlossenen Siedlungsgebiet) oder wie seit 8 Jahren(!) das benachbarte Niestetal (> 10 000 Einwohner in einem geschlossenen Siedlungsgebiet). Ich hatte dies so vorgefunden und versuche nur, konsistent weiterzuarbeiten.
Der place-node des deutlich kleineren Kernortes Calden in der Gemeinde Calden https://www.openstreetmap.org/node/240096777
ist demgegenüber place=village geblieben, insofern muss man das schon im Zusammenhang sehen - Du kennst dich im Landkreis Kassel aus?
Und ich hätte ebenso konsistent die beiden vorhandenen Lohfelden und Niestetal in place=municipality geändert.
Ich richte mich bei den Siedlungsplatz-/Ortsnamen (town, village, hamlet etc.) halt nach den Ortsschildern (*) - und trenne eben konsequent zwischen Verwaltungseinheit- und Siedlungsplatz-Namen.
Zusammengewachsene Siedlungsplätze sind nicht gar so selten - öfter allerdings auf verschiedenen Verwaltungsgebieten, da kann man sie auch in OSM nicht mal so eben umbenennen.
Die Kaufunger hätten ja die Chance - aber auch da zeigt sich eben, dass es gar nicht so einfach ist, wenn sich zwei gewachsene Strukturen und letztlich Identitäten zusammenraufen sollen.
So gehen wir halt verschiedener Wege.
Grüße, Georg
(*) Falls Kaufungen in den letzten 2 Jahren da etwas geändert haben sollte, gebe ich Dir recht - es liest sich aber nirgends so.
@Georg: ok, zum Prinzip, und in diesem Sinne habe ich mal Schauenburg auf municipality geändert (vorher village an unpassender Stelle) und Kaufungen (war reiner Beispiel-Zufall) aus dem Titel dieses Fadens entfernt, und statt Kaufungen als Beispiel die Stadt Baunatal in meinem Wiki-Entwurf genommen, denn als was die place-nodes dann (regional) letztendlich daherkommen will ich weder ausdiskutieren noch festlegen. Können wir so Freunde bleiben?-)
Hallo, inzwischen bin ich erstmal grob durch, was bedeutet alle al:8-Gemeinderelation im Landkreis Kassel sind per role ihren place-nodes zugeordnet und die Redundanzen sind beseitigt.
Einschätzung: mit admin_centre und/oder label ließen sich alle nodes bzw. Gemeinde-Varianten zufriedenstellend einordnen, das Konzept scheint mir Gemeinde-praxistauglich.
In einem 2. Schritt schaue ich mir nochmal die vorhandenen, darunterliegenden al:9+10-Grenzrelationen an und verbinde die auch noch per admin_centre mit ihren vorhandenen place-nodes.
Das Beispiel Gemeinde Helsa habe ich durch die (ich denke unumstrittene) Stadt Immenhausen ersetzt, weil dort die Zuordnung eines place-nodes zu 2 Grenzrelationen gezeigt werden kann: https://www.openstreetmap.org/node/240106500
(was auch zeigt, wie problematisch generell die Zuordnung von flächenbezogenen Information zu einem place-node ist - welche Fläche ist gemeint?)
Außerdem gibt mir Immenhausen, die Möglichkeit einer (unbezahlten) Werbeeinblendung:
Inzwischen wurden neben 30x Gemeinde/Stadt auch bei 70x Ortsteil/Stadtteil
die Grenzrelation mit dem vorhandenen place-nodes verbunden und Redundanzen beseitigt.
Dabei wurde die Gemeinde-Systematik nach “unten” fortgeführt, Probleme sind keine aufgetreten.
Wie ist in diesem Zusammenhang die Meinung zur Behandlung der openGeoDB:*-Tags am place-Node? Auf Relation übertragen oder löschen? Bei mir in der Gegend sind die uralt. Ich tendiere zum löschen.
Im Landkreis Kassel war der OpenGeoDB Bot i.d.R. Erstautor bei den Gemeinde/Stadtnodes (Ortsteile/Stadtteile waren dagegen händisch angelegt worden). In ca. 10 Jahren hatte keine Pflege, sondern lediglich einzelnes (und IMHO gerechtfertigtes) Tag-Löschen durch andere Mapper stattgefunden.
Im Rahmen meiner Überarbeitung habe ich die restlichen dieser alten Bot-Tags “in der Versionsgeschichte bzw. Chronik der nodes abgelegt”. Auf eine Übernahme in die Grenzrelationen, die erfreulicherweise immer korrekt getaggt waren, habe ich bewusst verzichtet.
@Die immer lacht, vgl. Diskussionsverlauf letzte Woche, #35 2018-12-11 19:10:18 - muss dich enttäuschen, den rein zufälligen “Fall Kaufungen” plane ich nicht weiter zu verfolgen, noch plane ich diesbezüglich auf irgendetwas zu “bestehen”.
Dabei fällt mir dort auf, en Role:admin_centre:
“Node representing the administrative centre (a capital, county seat etc.), usually a town, city or village (depending of the boundary level, see place=). "
würde ich eher so übersetzen:
"Node, der das Verwaltungszentrum repräsentiert (Hauptstadt, Kernstadt, Hauptort usw.) normalerweise town, city oder village (abhängig vom boundary-DE:Key:admin level, siehe place=).”
Spricht da irgendetwas dagegen?
(role:label würde ich in DE auch noch einfügen)
Aufgefallen ist dabei im Zusammanhang mit der Auswertung:
Gibt man das Beispiel der Gemeinde “Söhrewald” in die OSM-Suchmaske ein, ehält man als ersten Treffer die Gemeinde-Grenzrelation:
“Gemeinde Söhrewald, Landkreis Kassel, Regierungsbezirk Kassel, Hessen, 34…” https://www.openstreetmap.org/relation/1115035
Gibt man dagegen “Calden” ein, erhält man (z.Zt. als zweiten Treffer) auch die Gemeinde-Grenzrelation, allerdings fälschlich beschriftet als:
“Dorf Calden, Landkreis Kassel, Regierungsbezirk Kassel, Hessen, 34…” https://www.openstreetmap.org/relation/455491
Der Unterschied: Söhrewald besitzt einen, mit role:label eingebundenen, place=municipality-Node für den Gemeindenamen, den die OSM-Suche wohl nutzt, oder sehe ich das falsch?
eine boundary-Relation gibt ja immer eine Verwaltungseinheit an (z.B. Gemeinde) an.
Ich sehe eher bei Calden einen node gleichen Namens mit der Rolle admin_centre, der das Tag place=village enthält, wo Nominatim jetzt das Dorf herholt.
Und schon hat man das, was man eigentlich nicht haben will …
