Berlin 5 —> 15
jetzt läuft NRW. Dürfte bis Morgen brauchen.
Gruss
walter
Ähm das verstehe ich nicht ganz! Du kennst alle IDs von Relationen die Postcode enthalten. Wenn jetzt in einem Änderungssatz diese Relation auftaucht prüft man diese Relation etwas so:
Beispiel aus der Overpassapi:
area[name=“Bonn”]->.a;
(
node(area.a)[building][“addr:housenumber”];
way(area.a)[building][“addr:housenumber”];
);
out ids;
eventuell ist das aber zu Kurz gedacht. Mann müsste noch bei Änderungen beteiligter Nodes und Ways überwachen. Aber ich schätze den Aufwand deutlich geringer als mal eben 24 Stunden ganz Deutschland zu durchsuchen.
Jo, dann mach mal - Ich werte nicht die reinkommenden Changesets aus sondern frage meine Datenbank. Das kann dann schon mal bei ca 600 GB Daten einige Zeit dauern. Dafür bin ich aber flexibel und kann jede beliebige Auswertung/Anwendung in relativ geringer Zeit aus dem Boden stampfen.
Klar, Speziallösungen wie “Schnapp die alle reinkommenden Changesets, schau dir nur die PLZ an und mach was raus” oder eine hochgetunte Overpass-DB sind da schneller. Ich möchte dagegen flexibel bleiben. Rendern könnte ich z.B. auch damit - nur weiss ich noch nicht was 
Und das Ganze hat halt seinen Preis.
Gruss
walter
Ich habe das Gefühl früher warst du da flexibler, als du noch deine Multipolygone selbstberechnet hast 
Aber seis drum. Ich habe so eine DB nicht, daher werde ich das auch nicht auswerten können.
Nochmal zum Schulterklopfen an alle: Am Anfang waren es 75.299 “Irre” (und es sind ja auch zig-tausend Adressen neu hinzugekommen).
Ich tippe auf einen Dämpfer. Habe da zufällig etwas in Rheine gesehen.
Walter, willst Du die “Fools”-Website nicht auch in Deinem OSM-Wiki-Artikel verlinken?
NRW 213 —> 177 - immerhin stimmt der Trend.
Jo, das Wiki werde ich wohl erweitern - wenn mir ein vernünftiger Text einfällt
Gruss
walter
Moin Moin,
Baden-Württemberg 9 —> 56 
Gruss
walter
War grade am Beseitigen des partiellen addr:street-Vakuums der benachbarten “Großstadt”.
Dabei kam ein Fehler in den PLZ-Grenzen zutage (fehlende “Grenzausstülpung”), der vermutlich noch lange unentdeckt geblieben wäre.
Das bleibt vermutlich noch für einige Zeit ein sehr hilfreiches Tool (solange jedenfalls, wie wir die PLZ in der Adresse als sinnvoll erachten).
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.
Dafür. addr:* zeigt eine konkrete Postzustelladresse an.
Kleinkram
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.
Kenn mich zu wenig in de Ecke aus.
Gruss
walter
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.
Beispiel: http://www.openstreetmap.org/node/1052320316 (seit 4 Monaten als “object:addr:*”)
Komisches Tagging: **object:*addr:xxx=
Nun denn, mögen die damit glücklich werden.
Gruss
walter
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.
Franz
Danke, war mir nicht sicher, wo die hin sollte.
Gruss
walter
Moin Moin,
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.
Gruss
walter
Nö, sind sie nicht
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.
So, die Fools-Auswertung läuft wieder:
Meck-Pomm 5 —> 5, 2 davon sind noch offen
Gruss
walter
BW 56 —> 3