Man muss sich immer bewusst sein, dass Admin-Grenzen etwas ganz anderes sind als Places. Letzteres sind Siedlungen, keine Verwaltungsgebiete und OT-Grenzen (mit Wäldern etc.).
Natürlich wäre dann besser, wenn das Siedlungsgebiet ein Gebiet und kein Punkt wäre…
Mit zwingend meine ich: Selbst wenn alle admin-Grenzen erfasst sind.
Administrativ (Verwaltungs-…) sind Grenzen im eigentlichen Sinn nur bis level=9. Alles mit höherem Level ist eher informativ, die “Grenzen” sind oft nur grob geschätzt. Bei Dörfern und Ortsteilen dieser Stufe können places (bis auf Weiteres) sehr wohl Sinn machen. Ich setze sogar des öfteren da ein addr:suburb an die Gebäude (Pragmatismus vs. Redundanzfreiheit).
Den Namen und weitere Tags an sonstige Flächen (landuse etc) zu hängen, ist auch nicht das Gelbe vom Ei. Streuweiler mit einem Gehöft alle paar hundert Meter z.B. lassen sich nicht vernünftig als (nicht-admin-)Fläche erfassen. Das rettet ein place-Tag am Umfang wie in http://www.openstreetmap.org/way/42346288auch nicht.
Naja, vom generellen Place-Node-Killen bin ich ja auch weg. Ich finde nur, dass sie dort, wo es vernünftige Admin-Grenzen gibt, für Ortschaften und höher (es gibt auch places an Ländern!) unnötig sind.
Die eigentliche Frage ging aber nicht um den Place-Node sondern darum, was an schrottigen Tags aus Admin-rels raus kann. Und da gibt es einiges.
Gruss
walter
select osm_id,name,tags->'place' place
from planet_osm_polygon
where osm_id < 0
and admin_level = '2'
and tags ? 'place'
and boundary='administrative'
;
osm_id | name | place
----------+---------------------+----------
-2171347 | Luxembourg | country
-3335661 | بيرطويل (Bir Tawil) | locality
(2 rows)
Das kann man so machen, auch laut Wiki. Vernünftig gerendert wird es nicht unbedingt (?).
Im Wiki sind places nicht für Relationen definiert. Das bräuchte man dann aber im Prinzip für “verstreute” Siedlungen.
a) Die Daten sind jetzt in Google, ich hab Gehrkes Post verpennt
b)
An die nicht Twitterer: NRW s Abstand zum Baden Württemberg ist wieder größer geworden. und die Bayern sollen das Überholen durch die Niedersachsen nicht auf sich sitzen lassen
Die meisten davon sind 2-, 3- oder 4 Seitenhöfe, bei denen jeweils nur an einem Gebäude addr:street und addr:housenumber hängt und an den anderen nur addr:housenumber. Wie sollte man hier am besten vorgehen?
A: addr:street ergänzen (dann werden wohl div. Qualitätssicherungstools ganz wild werden wegen doppelten Adressen. Außerdem ist es z.B. für Navis oder andere Suchmaschinen nicht sinnvoll, wenn dann viele Nummern mehrfach in den Daten auftauchen)
B: Die doppelten Nummern ohne addr:street einfach löschen (dann gehen jedoch wichtige Informationen verloren, nämlich, dass die Häuser adressmäßig zusammen gehören, also eher nicht sinnvoll)
C: Die doppelten Nummern ohne addr:street löschen und stattdessen ein “note=gehört zu Nr. x” dranhängen
4 * Hausnummer 70 halte ich für nicht korrekt. Es sei denn es ist an jedem Haus die gleiche Hausnummer angebracht. Im Prinzip musst du jetzt aufs Fahrrad, und vor Ort nachschauen, wo die 70 richtig ist und wo nicht, und Häuser ohne Hausnummer haben auch keine Adresse.
Wenn allerdings vor Ort wirklich 4 * die 70 steht, und der Postbote die finale Auflösung der Zustellungsfrage durch den Nachnamen löst (wie sie es auch auch innerhalb eines Gebäudes machen) wären die richtig und die Adresse muss dann auch mehrfach erfasst werden.
Das mit den mehrfachen Hausnummern gefällt mir überhaupt nicht. Bei einem Hof mit mehreren Gebäuden hat eines die Hausnummer und den Briefkasten, die anderen nicht. Der Kuhstall bekommt keine Post, also auch keine Adresse.
Wenn die Zugehörigkeit ausgedrückt werden soll, sollte das nicht über die (falsche) mehrfache Hausnummer gemacht werden.
Also B, höchstens C.
Eine ähnliche Problematik (eher noch schlimmer) hat man übrigens in verwinkelten Altstädten auch. Da weiß man auch nicht, zu welcher Adresse ein Anbau gehört, der an mehrere Gebäude grenzt, wenn man nicht dort wohnt.