Ich bin jetzt zum wiederholten Male über einen Stolperstein “gestolpert”, der die volle Adresse mit PLZ etc. trug und das auch noch falsch.
mMn gehört die Adresse allein ans Haus (so es noch existiert) und nicht an den Stolperstein. Ich glaube nicht, dass an ihn Post ausgeliefert wird. Insbesondere gibt es ja auch einen Subtag zu memorial, der die Beziehung zum Haus samt Adresse herstellt.
Ich habe mir daher erlaubt, die addr:*-Tags an den fraglichen Stolpersteinen nicht zu korrigieren, sondern sie zu löschen.
Hab vorhin ca 3400 addr:*-Tags in Frankenthal rausgeschmissen, da sich der Übeltäter nach 2 Wochen immer noch nicht gemeldet hat. Müssen aber noch mehr sein, da ich die Straßenlaternen noch nicht wieder gefunden habe.
ps: Mag sich bitte mal jemand um eine PLZ in Hamburg kümmern? https://www.openstreetmap.org/relation/1732878 Die ist uns durch die Lappen gegangen, weil der Östliche Ring ok ist. Aber der Westliche ist defekt.
Dabei fällt mir dunkel ein, dass in Düsseldorf auch Straßenlaternen o.ä. mit Adressen oder addr:postcode getaggt sind/waren. Die Community dort hat auf Erhalt bestanden. Hoffe, ich gebe das richtig wieder.
PLZ-Grenze war nicht geschlossen. Habe die PLZ-Grenze, die gleichzeitig auch diese Straße war von der Straße entfernt und auf die nördlich parallel verlaufende AL9-Grenze gelegt und den Umriss wieder geschlossen.
die Auswertung für die Irrläufer musste ein wenig ruhen, da ich erst meine “Aktion Fliegenschiss” durchziehen wollte
Was war das? Es gab ca 5-6 sehr kleine Flächen, die sich in keinem einzigen PLZ-Gebiet befanden. Die fielen mir aber in meiner neuen Karte als kleiner Fleck auf. Die sind nun weg.
@gehrke: gerade jetzt sind mMn alle PLZ-Relationen bei uns zu 100% ok. Es fehlt nix, nix ist zuviel und auch keine Überlappungen. Wäre eine gute Gelegenheit, eine Referenz-Kopie aller PLZ-Grenzen zu machen.
Bedeutet natürlich nicht, dass die auch richtig liegen aber die Topologie stimmt. Das kann sich aber jeden Moment wieder verschlechtern.
select tags->'postal_code_level' postal_code_level, count(*)
from planet_osm_polygon
where boundary='postal_code'
and st_contains((select way from planet_osm_polygon where osm_id = -51477) ,pointonsurface)
group by tags->'postal_code_level'
order by tags->'postal_code_level';
postal_code_level | count
-------------------+-------
4 | 10
6 | 95
8 | 8204
(3 rows)
Ich hoffe, daß 8204 PLZ ok sind. Die Level 4 und 6 stehen so (noch) nicht in OSM drin, die hab ich aus den PLZ-Gebieten berechnet.
Ja, ich habe schon eine Referenztabelle der deutschen Grenzen (admin und postal), die ich nur aktualisiere, wenn alles sauber ist.
Habe erst vor wenigen Sekunden PLZ-Geometriefehler in Berlin behoben.
Ich hoffe aber, dass da keine defekten PLZ-Grenzen dabei waren, oder doch? Die hätte ich nämlich sehen müssen. Was ich mit der neuen Karte nicht sehe, sind zu verschiebende Ways.
Ich wollt gerade ein paar Irrläufer in Chemnitz beseitigen, die gibt es aber seit April garnicht mehr.
Da hat Basstoelpel die PLZ-Grenze schon korrekt verschoben. Stimmt da etwas mit den Relationen nicht?
Vorhin hab ich eher zufällig einen Abweichler entdeckt: das Tierheim in Hanau. Liegt offenkundig in Dörnigheim, die Adresse ist aber hanauisch. Wie passt das zusammen? Die PLZ-Grenze müsste zumindest angepasst werden, wenn das stimmt.
So was kommt nicht selten vor. Vermutlich ist auch das Gebiet östlich davon betroffen, das bis zum Main-Garten auch noch zu Maintal / Ortsteil Dörnigheim gehört, aber an der Landstraße liegt. Die gibt es (postalisch) in Maintal nicht.
Sehr wahrscheinlich muss auch der Straßenname angepasst werden, denn dann fängt die Kesselstädter Straße erst weiter im Westen an. Das möchte ich aus der Ferne aber nicht entscheiden.
ich habe einen Clone meiner Boundaries-Karte erstellt: PcBoundaries. Damit sind - hoffentlich - alle Sachen möglich, die ihr bereits von der Boundaries-Karte kennen solltest.
falls doch noch kleinere Fehler drin sein sollten, ruhig melden.
