Way für ungefähren Ortsumriss

Das genannte Objekt wurde vor 7 Jahren angelegt ... deshalb meine eher allgemeine Antwort.

OSM funktioniert in etwas so:
- Der Erste erzeugt etwas,
- der Zweite verbessert es,
- der Dritte komplettiert es,
- der Vierte wartet es,
- ... und so weiter.

Und irgendwann stehen bessere Daten zur Verfügung. Und dann heißt es:
- Das Bessere ist der Feind des Guten.

Gruß Klaus

Zumindest könnten, nein, eher müssen,

addr:postcode 71546
population 8313
website www.aspach.de
wikipedia de:Aspach (bei Backnang)

entfernt werden. Die halte ich so schlicht für falsch an diesem way weil sie sich auf die gesamte Gemeinde beziehen.

toc-rox wrote:

Das genannte Objekt wurde vor 7 Jahren angelegt ...

Asbach Uralt. 🙂

Warum soll das place-Polygon unbedingt zu einem place-node schrumpfen?
Weil die Daten dann besser / genauer werden?

GeorgFausB wrote:

Warum soll das place-Polygon unbedingt zu einem place-node schrumpfen?
Weil die Daten dann besser / genauer werden?

Gegenfrage: Was genau repräsentiert das place-Polygon jetzt? Oder: In welcher Hinsicht ist es genauer als ein place-node (der ja ohnehin schon da ist)?

--ks

Der key place beschreibt - u. a., aber durchaus im Wesentlichen - einen benannten Wohn-/Siedlungsplatz.
Bei der Auswertung, was (Gebäude, Adressen u. a.) alles zu diesem Siedlungsplatz gehört, ist ein place dann hilfreich, solange nicht alle Siedlungsplätze durch Grenzen abgegrenzt werden können.

Bei einem Polygon ist dabei eine genau abgegrenzte IST_ENTHALTEN-Abfrage möglich.
Bei einem Node ist nur eine ungefähre UMKREIS-Abfrage möglich, die immer die Gefahr des zuviel oder zuwenig beinhaltet.

Bei der Wahl würde ich daher eher den Node löschen als das Polygon - meine Meinung.

Gruß, Georg

GeorgFausB wrote:

Bei einem Polygon ist dabei eine genau abgegrenzte IST_ENTHALTEN-Abfrage möglich.
Bei einem Node ist nur eine ungefähre UMKREIS-Abfrage möglich, die immer die Gefahr des zuviel oder zuwenig beinhaltet.

Bleibt aber der Umstand, daß das Polygon nichts Physisches on the ground repräsentiert und dazu in willkürlichem Abstand um den Ort gezogen ist (also die Gefahr des Zuviel bereits gegeben ist). Es dient nur zum ungefähren Einfassen von Elementen, die zum place gehören. Dafür wurde doch – wo admin_level noch nicht konsequent durchgemappt ist – das gute alte is_in erfunden. Ein is_in=Aspach an allen betroffenen landuse=* würde das Polygon lückenlos ersetzen, wäre exakter und vereinfachte das Editieren, ein Way weniger.

--ks

Oh ja, zurück zum guten alten is_in - 100e Tags, die keine genormte Struktur haben statt eines geografischen ways. 😉
Einfacher und exakter und lückenlos ...
Ich fürchte nur, Du meinst es wirklich ernst ...

kreuzschnabel wrote:

GeorgFausB wrote:

Bei einem Polygon ist dabei eine genau abgegrenzte IST_ENTHALTEN-Abfrage möglich.
Bei einem Node ist nur eine ungefähre UMKREIS-Abfrage möglich, die immer die Gefahr des zuviel oder zuwenig beinhaltet.

Bleibt aber der Umstand, daß das Polygon nichts Physisches on the ground repräsentiert und dazu in willkürlichem Abstand um den Ort gezogen ist (also die Gefahr des Zuviel bereits gegeben ist). Es dient nur zum ungefähren Einfassen von Elementen, die zum place gehören. Dafür wurde doch – wo admin_level noch nicht konsequent durchgemappt ist – das gute alte is_in erfunden. Ein is_in=Aspach an allen betroffenen landuse=* würde das Polygon lückenlos ersetzen, wäre exakter und vereinfachte das Editieren, ein Way weniger.

Sollte "is_in=Großaspach" sein.
Besser wäre mMn aber eine AL9/10-Grenze zwischen Klein- und Großaspach.
Selbst eine erfundene Linie wäre immer noch besser als dieses Phantasiepolygon.

GeorgFausB wrote:

Oh ja, zurück zum guten alten is_in - 100e Tags, die keine genormte Struktur haben statt eines geografischen ways. 😉
Einfacher und exakter und lückenlos ...
Ich fürchte nur, Du meinst es wirklich ernst ...

Keine Angst, ich hab frische Batterien in meinem Sarkasmusignorator.

Exakter: Weil dann die dazugehörigen Flächen (residential, commercial, industrial, …) wirklich exakt beschrieben und nicht nur willkürlich eingefaßt sind.

Lückenlos: Weil dann nicht weniger Information da ist als jetzt (falls ich mich irre: welche?)

Einfacher: sag ich gern nochmal: Ein Way weniger, der im Editor stört und gepflegt werden muß.

--ks