Hallo,
mir ist aufgefallen, dass es einige places gibt, die sich sowohl auf einen Teil einer Grenze beziehen als auch auf die gesamte Grenze.
Beispiel: Kusterdingen
Place
Boundary
In diesem Fall scheint es so, als würde der Place-Tag räumlich im Dorf Kusterdingen sein (das sich in der gleichnamigen Gemeinde Kusterdingen befindet), sich aber auf die Gemeinde beziehen.
Fehlt in diesem Fall dann aber nicht ein zweiter Place-Tag, der sich auf das Dorf bezieht?
Viele Grüße
dktue
place=* ist das Tag für die besiedelte Stelle, die in diesem Fall eine Dorf-ähnliche Relevanz hat. Hier fehlt kein zweites place=*-Tag, das sieht alles ok aus.
Tatsächlich hängt am Place-Tag allerdings der Tag
population=8258
, was sich auf die gesamte Gemeinde bezieht. Bei den anderen Dörfern in der Gemeinde Kusterdingen, beispielsweise Jettenburg (Link zum Place-Node von Jettenburg) steht
population=1100
, was sich eben nur auf das Dorf bezieht und nicht auf die Gemeinde.
Ach das meintest du. Hmm, das ist nicht eindeutig entschieden. Beim Place-Node von Stuttgart möchte man schon die 600.000-irgendwas sehen, nicht die Einwohnerzahl von S-Mitte. Bei einer Landgemeinde tendiere ich zur Einwohnerzahl des Hauptorts.
Der Thread hier soll genau diesen Widerspruch erläutern und helfen, ein konsistentes System zu erarbeiten.
Einwohnerzahlen, die sich auf die Gemeinde (al=8) beziehen, gehören meiner Ansicht nach nur an die jeweilige al-Relation, nicht an den Knoten, der die admin_centre-Rolle hat.
Wenn wie in deinem Beispiel population=8258 sich auf die gesamte Gemeinde bezieht, gehört das an die Relation https://www.openstreetmap.org/relation/2778683. Der place-Node https://www.openstreetmap.org/node/90626099 müsste dann nur die Einwohnerzahl des Ortes selbst bekommen.
Sven
Alternatives Beispiel, gleiche Struktur: Place-Node von Laichingen. Auch hier bezieht sich die Einwohnerzahl auf die gesamte Gemeinde.
Zu Deiner Eingangsfrage:
Nein, ich würde laut Chronik des place=village Knoten (https://www.openstreetmap.org/node/90626099/history) diesen schon alleine vor dem Respekt der damaligen Mapper als Punkt für das Siedlingsplatzzentrum von Kusterdingen belassen, allerdings die Anzahl der Bewohner von 8xxx geschätzt (je nachdem was passt) auf 2000-3000 ändern.
Was fehlt, bzw. was damals der opengeoDB-bot durcheinandergebracht hat, ist der administrative place Knoten der Gemeinde, dieser kann z.B. im geografischen Zentrum (irgendwo auf dem Acker) als place=municipality untergebracht und sogar in die Gemeinde-Relation (admin_level=8) als Rolle “label” aufgenommen werden. Dort, weil auf dem Acker wohl keiner wohnt, würde ich population=* weglassen und die 8xxx an die Gemeinderelation hängen.
edit: ps: falls man die is_in behalten möchte, könnte man diese dann wohl so verteilen.
=> Am Kernort (Siedlungsplatz p=village) Kusterdingen
is_in=Kusterdingen,Tübingen,Tübingen,Baden-Württemberg,Bundesrepublik Deutschland,Europe
=> Am geograpfischen Zentrum (label p=municipality) Kusterdingen
is_in=Tübingen,Tübingen,Baden-Württemberg,Bundesrepublik Deutschland,Europe
Ich bin ebenfalls der Ansicht, dass die admin-Relation der bessere Ort als ein place-node für die Gemeindeangaben wie Einwohnerzahl ist.
Bei dem weiß man zunächst nicht, worauf er sich bezieht, wenn wie hier ein Ortsteil den gleichen Namen wie die Gemeinde hat.
Ein municipality-node könnte das leisten, wenn eindeutig (und allseits bekannt) definiert wäre, dass der immer zu AL=8 gehört.
Bei der admin-Relation und der damit definierten Fläche geht die Zuordnung zwanglos, abgesehen davon muss ich im Editor einen Node erst finden.
Für den Platz der Beschriftung bei irregulären Umrissen gibt es den Node mit Rolle *label *und für den Sitz des Rathauses das admin_centre.
Hier sind nicht einmal die place-Nodes für die Ortsteile erforderlich, da es auch die Grenzrelationen mit AL=9 für die vier Teilorte gibt. Dorthin gehören mMn nach auch ggf. die Einwohnerzahlen der Teilorte.
Die sehe ich in OSM eher kritisch und selbst mit Stichtag nur als Größenordnung, wenn sich wie hier diese Zahl wegen der Nähe zu Tübingen ständig und stark ändert. Wer hält das aktuell :/?
Bedeutet das, dass die Place-Nodes in solchen Fällen überflüssig sind und deren Tags vollständig an die Administrative-Relation verschoben werden können?
Im Prinzip ja.
Ich würde die Place-Nodes aber nicht löschen: Wie im anderen Thread beschrieben, kann es passieren, dass dann irgend ein Auswerter ins Stolpern kommt. Ein bisschen Redundanz für solche Fälle sehe ich nicht als Beinbruch an.
Ich würde gerne eine Mapping-Regel daraus ableiten, beispielsweise:
Existiert zu einem Place-Node eine boundary=administrative-Relation, so sollten die Tags des Place-Nodes an dieser Relation dupliziert werden.
Wäre das tragfähig?
@Fischkopp0815: Sehr interessante Diskussion und toll, was Jo Cassel dort geleistet hat. Ich würde gerne erreichen, dass wir daraus gemeinsam einen Standard für das Tagging erarbeiten und auch im Wiki dokumentieren, sodass es nicht auf die Leistung einzelner ankommt sondern durch die gesamte OSM-Community die Daten dezentral verbessert werden.
das halte ich nicht für sinnvoll, einen place Knoten der irgendwo auf dem Acker die Gesamtgemeinde repräsentieren soll, die bereits als Fläche gemappt ist? Wozu soll das gut sein? M.E. kann man place=municipality deprecaten oder wenigstens an das bestehende zugehörige Adminobjekt dranmachen, einem zusätzlichen erfundenen Knoten kann ich keinen Sinn entlocken.
Genau das ist meiner Meinung nach der Kern der Diskussion: Wieso haben wir Place-Nodes für die Fälle in denen die dazugehörige Grenze als Fläche gemappt ist?
Bei Siedlungs-place für das Zentrum, aber bei den „Verwaltungsplace“? Die sind m.E. komplett überflüssig, sowohl als Punkt als auch als Fläche (hinsichtlich place=*), weil sie lediglich eine boundary=administrative replizieren.