Aufgrund von Inkonsistenzen (siehe dieser Thread) möchte ich gerne diskutieren, ob man die population-Tags von den place-nodes an die boundary-relation verschieben sollte, sofern vorhanden.
Der population-Tag kommt sinnnvollerweise an das OSM-Objekt bei dem sich auch der wikipedia/wikidata-Tag mit dieser Einwohnerzahl befindet - im Idealfall ist das eine Grenzrelation.
Das Thema ist nicht neu,
viele Grenzrelationen<—>zugehörige place-Nodes in .de sind aber (noch) reichlich konfus bzw. unaufgeräumt, s. als Leitfaden:
https://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze#Zusätzliche_Relationselemente
Ein Großteil der Renderer (auch unser Hauptrenderer von openstreetmap.org, OpenTopoMap usw.) verwenden seit vielen Jahre die population-Tags von den place-Knoten, um beim Beschriften von Städten in niedrigeren Zoomlevels nur die “größeren” Städte dazustehen. Würde man population vom place-Knoten auf die boundary verschieben, wäre diese Möglichkeit vorbei.
Der population-Tag war auch nie als präzise Angabe gedacht, sondern als grobe Hausnummer. Aus dem angenommen Proposal von 2006:
Hier ein Beispiel, wo man sehen sollte, warum das die Renderer machen…
a) place=city oder place=town und population>12000:
b) place=city oder place=town ohne Verwendung vom population-Tag:
Wenn die Place-Nodes diese Information nicht mehr tragen sollten – könnte der Render das nicht auch aus der Administrative-Relation erhalten?
So einfach wie möglich - kompliziert wird es von allein. Wie z.B. nominatin das macht - dann sieht man auch manchen Fehler.
Warum soll ich bei der Abfage eines node noch schauen in welcher Grenze (PLZ, Ort, …) liegt?
Ich meinte eher, dass man den Place-Node dann weglassen könnte. Der Renderer müsste eben unterstüzten Places sowohl an Flächen als auch an Nodes zu rendern. Diese Funktionalität wäre vollständig abwärtskompatibel und würde eine schleichende Migration erlauben.
Und wo soll dann der “Name” gerendert werden? Im Mittelpunkt der Grenze, die dann auch mal außerhalb liegen kann?
Ich finde man sollte das “einfache” erhalten und das komplizierte “duplizieren” - so können alle damit leben.
https://www.openstreetmap.org/search?query=Freital#map=12/50.9945/13.6395
- “Freital” am place-node
- Grenze Freital - wo würde da der “Name” gerendert?
Am Node, der mit der Rolle “label” in der Administrative-Relation eingetragen ist.
Also brauchst du ja doch den node. Dann kann er auch den place=* behalten und wird auch innerhalb der Grenze (Relation) gefunden: http://overpass-turbo.eu/s/IRW
@geri-oc: Ja, ich möchte eben genau das disktutieren: Node behalten finde ich gut, wenn dort nur place=* und name=* getaggt sind und der Node in der Relation ist, sodass der Bezug maschinenlesbar erkannt werden kann.
Ist das ein gangbarer Weg?
place-node und node mit Rolle *label * für die Platzierung des Namens im Renderer sind eigentlich völlig verschiedene Sachen. Es ist mMn nicht unzulässig, die zusammenzulegen, aber Pflicht oder empfohlener Standard ist das nicht.
Die place-nodes sind ein zweischneidiges Schwert: Zumindest früher haben die Nominatim gelegentlich auf Irrwege geführt.
Und genau deshalb diskutieren wir hier: Ich möchte den Tagging-Standard weiterentwickeln, damit die Daten besser werden – nicht nur durch die Mitleser hier, sondern durch alle, da eine Empfehlung im Wiki dokumentiert sein wird (hoffentlich).
Ich halte nicht allzuviel davon (place-)Nodes zu setzen, die nur die Funktion label bekleiden, z.B. Gemeindename eines al=8. Ich betrachte es als ausreichend, wenn eine Gemeinde (al=8) einen Punkt als Rolle admin_centre hat. Im meinen Augen kann und muß der Renderer anhand seiner Platzierungsregeln selbständig den richtigen Platz für den Namen der Gemeinde finden, da braucht es keinen weiteren Punkt als label-Rolle.
Sven
Das müsstest Du die Entwickler/Betreiber der diversen OSM-Karten fragen. Ich schätze, dass das schon möglich wäre, aber nur mit ziemlichem Aufwand, komplexeren und damit vermutlich langsameren Datenabfragen und mit einem Umbau der Renderer-Regeln.
Bin mir nicht sicher, ob wir durch diesen Mehraufwand wirklich viel gewinnen oder nur die Auswertung der OSM-Daten schwieriger machen und ob Du Dir der Konsequenzen für die existierende OSM-Infrastruktur Deines Vorschlags im Klaren bist.
+1
Ich finde auch, dass man einfache Aufgaben mit einfachen Lösungen lösen sollte, d.h. ich fände ein Verschieben des population-Tags vom place-Knoten auf die boundary nicht gut.
Moin,
Falsche Informationen am falschen OSM-Objekt zu belassen ist aber eine zu einfache Lösung.
Welche population will ein Renderer denn auswerten - die der Gemeinde oder die des Siedlungsplatzes?
Dies sind nunmal zwei verschiedene Dinge.
Grüße
Georg
Hier der Ausschnitt von openstreetmap.org
select way, name, CASE WHEN (tags->'population' ... as population,... FROM planet_osm_point WHERE place in ('city',...
hier von opentopomap.org
SELECT way,...,name,population::INTEGER FROM planet_osm_point WHERE ... place IN ('city',
d.h. er wertet die population des Sieglungsplatzes aus.
und genau dafür wurde das population-Tag eingeführt (und deshalb hatte ich #3 aus dem damaligen und angenommenen Proposal zititert “…As the population is only used for name scaling, it does not have to be very precise and can be approximated…”)
population an der Relation sollte die Population des Relationsgebietes und population am place die Population des Siedlungsplatzes auf den sich der place-Node bezieht angeben.
Damit hätte auch niemand ein Problem
Das würde dann diesen Threadtitel etwas abändern in “population-Tag kann von place an boundary verschiebenkopiert werden, falls zutreffend”, wobei mir nicht sicher bin, ist ob es überhaupt eine Anwendung (außer overpass) gibt oder geben wird, die population an einer boundary-Relation auswertet. Weiß jemand diesbezüglich vielleicht mehr?
Jede Anwendung, die Einwohner innerhalb einer (arbiträren) Fläche auswerten möchte braucht die Information Flächenbezogen. Dazu gehören auch Heatmaps. Man verliert einfach information in dem man es auf einen Punkt reduziert und das finde ich schade, wenn die Flächeninformation doch vorhanden ist.
Hast Du einen Link zu einer Anwendung (auch heatmapbasierend), die population an boundary auswertet, damit man sich das mal ansehen kann?