Dito. weg damit.
Gruss
walter
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.
Gruß Jo
@Jo Cassel: Nicht die “Schönheit”, sondern die Richtigkeit der Karte ist das Wichtigste.
Eine nicht willkürliche Position des Nodes Kaufungen kann es NIEMALS geben. Daher hör bitte auf, auf eine solche zu bestehen.
@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”.
In
https://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze#Zus.C3.A4tzliche_Relationselemente
sind jetzt die 3 Beispiele aus dieser Diskussion hinzugefügt.
Die dortigen role-Wiki-Links führen z.Zt. noch auf en
https://wiki.openstreetmap.org/wiki/Relation:boundary#Relation_members
ich werde also (analog zur en-Struktur) noch DE-Redirects anlegen, auf:
https://wiki.openstreetmap.org/wiki/DE:Relation:boundary#Mitglieder
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)
Grüße und guten Rutsch
Jo
1 Like
Jetzt sind admin_centre + label angepasst bzw. neu in:
https://wiki.openstreetmap.org/wiki/DE:Relation:boundary
und dort unter “siehe auch” ein Verweis auf:
https://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze
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?
Moin,
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 …
Grüße, Georg
Idee, ggf. potentielle Lösung, setze einen neuen node(place=municipality/name=Calden) ungefähr an die Stelle des Flächen-Schwerpunktes der Caldener admin-level=8 Grenzrelation und binde diesen Punkt als Rolle ‘label’ in selbiger Relation ein.
Vielleicht gibt dann Nomination irgendwann für Calden Resultate wie Dorf(Siedlungsgebiet) und Gemeinde(Verwaltungseinheit) in passenderer Zuordnung aus.
Apropos, nach welchem Rhythmus synchronisiert sich Nominatim?
Habe mal einen place=municipality “Calden” eingefügt, rein strukturell scheint mir das sinnvoll …
https://www.openstreetmap.org/node/6184200447
Landkreis-Abfrage (2MB):
http://overpass-turbo.eu/s/Ezh
Und schon wenige Minuten später ist der erste Such-Treffer:
“Gemeinde Calden, Landkreis Kassel, Regierungsbezirk Kassel, Hessen, 34…”
Mmh, da denke ich mal, dass ich das bei 2 weiteren derartigen Gemeinden auch noch mache …
Moin,
Rückschluss aus den Ergebnissen:
Nominatim sucht
- eine Relation mit dem Namen
2a) in der Relation die Rolle label mit identischem Namen
oder, falls nicht gefunden
2b) in der Relation die Rolle admin_centre mit identischem Namen - verknüpft den place-Tag des node mit der Relation
Und das ist dann ein Trugschluss - also ein Bug in Nominatim.
Und um das zu vermeiden, wird jetzt ein extra Node mit der Rolle label angelegt und verknüpft.
Eine selten benötigte Renderer-Hilfestellung wird somit zur strukturellen Notwendigkeit erkärt? - Wozu?
Edit:
Kann er/sie/es jederzeit - er braucht sich doch bloß an die richtigen Objekte boundary und place zu halten!
Statt wilde Vermutungsverknüpfungen herzustellen, die ihm allerdings von - in meinen Augen - etwas übereifrigen Mappern 
vorgeflüstert werden.
Grüße, Georg
1-3 ist reichlich spekulativ, aber gut …
Also meine Denke ist folgende:
Im Landkreis Kassel hatten - nach über 10 Jahren node-Geschichte, die wohl kein Mensch mehr nachvollziehen kann - die Gemeinden (nicht Städte!) OHNE Namensgebenden Hauptort i.d.R. einen place-node der “irgendwie” die Gemeindefläche befraf. Die Gemeinden MIT namensgebenden Hauptort dagegen hatten keinen (mehr?). Dies sind neben “Calden” noch “Breuna” und “Nieste” - genau die Gemeinden, bei denen die OSM-Suche Auswertungsprobleme hat.
Da stellt sich mir, der am Vorgefundenen arbeitet, dann schon die Frage, ob “namensgebender Hauptort vorhanden” so ein valides Kriterium ist, oder ob man sich nicht besser auf den “Söhrewald”-Standpunkt stellt: eine Gemeinde - ein zugehöriges place=municipality-label.
Ich würde das nicht “notwendig” nennen, aber “irgendwie logisch”.
Gruß Jo
Man darf es mMn dem Datenkonsumenten (Nominatim) im Bedarfsfall schon leichter machen, das macht man beim Renderer mit dem label-Knoten gelegentlich auch, damit er seine Beschriftung vernünftig setzen kann.
Ein place=municipality ist ja nicht falsch und kann die Zusatzinformation geben, wo der Verwaltungssitz (das Rathaus) ist.
In der place-Hierarchie steht es über dem place=village, könnte also sogar theoretisch gleichzeitig daneben stehen (Hauptort vs. Gemeinde), ähnlich wie eine AL10-Kernstadt zu einer AL8-Gemeinde gleichen Namens.
Moin,
Wenn Du mir einen anderen Grund nennen kannst, wieso Nominatim bei der Relation plötzlich auf ein “Dorf” kommt - gerne.
Es ist zwar logisch - aber die Logik folgt dem (historisch bedingt fehlerhaftem) Verhalten des Auswerters (Nominatim) statt den aktuellen korrekten Daten (Gemeinde und Ortschaft).
Wer die letzten 10 Jahre miterlebt hat, hat auch miterlebt, dass
- zuerst die nodes da waren, die damals Ortschaft und/oder Gemeinde darstellten - je nachdem, was sich der Mapper so dachte.
- später die Gemeindegrenzen kamen, wodurch die Informationen dann größtenteils doppelt da waren (node und relation).
- Nominatim Namen doppelt darstellte und daher einen Weg suchte, wie er die doppelten Informationen eleminieren konnte.
- daraufhin relation und node auswertete/verknüpfte und dadurch doppelte Informationen vermied.
- die doppelten Informationen dann aufgelöst wurden (Trennung von Gemeinde/Relation und Ortschaft/place-node).
- Nominatim aber weiterhin diese unterschiedlichen Daten als vermeintlich doppelte Information zusammenschmeißt.
Die urprünglich gutgemeinte Absicht, falsche Daten zu glätten führte später-jetzt dazu, dass richtige Daten falsch verknüpft werden - und dieser doppelte Auswertungsfehler soll jetzt durch einen weiteren Daten-Workaround umschifft werden.
Dabei sind alle nötigen Daten bereits eindeutig vorhanden.
Tut mir leid - aber in einer geografischen Datenbank sind nodes (mit Umkreis) immer nur ein provisorischer Kompromiss bis die Fläche eindeutig beschrieben wird - danach haben flächenbeschreibende nodes dort nichts mehr zu suchen.
Als punktförmiger Hinweis auf ein admin_centre oder als Beschriftungsstütze meinetwegen - wobei Letzteres eher an der “Implementationsfaulheit” / Einfachkeit des Renderers liegt.
Grüße, Georg
Moin,
Als reine Positionsangabe gerne - aber dafür braucht es keine tags am node.
Als doppeltes Objekt (mit Tags) macht man es dem Auswerter nur schwieriger - siehe Renderer-History.
Als reine Positionsangabe admin_centre gerne - aber da sich dies meist in einer vorhandenen Ortschaft befindet, stehen dann meist die Tags der Ortschaft am node (Ausnahmen wie Stapel mal abgesehen, aber dort werden auch keine tags benötigt).
Ein node mit dem municipality-Tag dürfte sich meist nicht am Ort des admin_centre befinden, sondern im Zentrum der Fläche, eine Übereinstimmung eher Zufall sein.
Im Gegensatz zu einer Stadt / einem Stadtteil ist eine Verwaltungsgemeinde kein Siedlungsplatz.
Das Objekt Verwaltungsgemeinde ist die Relation - wozu also ein identisches Objekt als node?
Grüße, Georg
Kann deine (radikale-Redundanzvermeidung) Position schon verstehen, aber letztendlich geht es darum, dass ein name im zugeordneten label einmalig nochmals getaggt wird … ja mei, also damit kann ich leben.
Sieh da kein Problem, sondern eine fortschreitende positive Entwicklung (mit Söhrewald an der Spitze der Gemeinde-Evolution …
In diesem Sinne habe ich neben “Breuna” und “Nieste” auch “Liebenau” (eine al8-“Stadt” gebildet aus mehreren kleinen verstreuten Dörfern, davon eines mit dem Namen “Liebenau”) einen place=municipality “Liebenau” zugeordnet, den name:prefix=Stadt wertet die OSM-Suche an dieser Stelle wohl (derzeit) nicht aus, aber bei “Gemeinde” statt “Dorf” sehe ich schonmal pragmatisch einen Fortschritt …
Grüße Jo