Pflege der deutschen PLZ-Daten in OSM

seichter · January 25, 2015, 3:12pm

Da sieht man schön die lokalen Präferenzen von Adressen am Gebäude vs. an Node.

wambacher · January 25, 2015, 3:50pm

Jo, ist also ein Spinn Off-Spinn Off

So ganz sieht man das nicht, da sich die Punkte überlappen. Ich wollte gerne, dass aus Blau und Gelb Grün wird (z.B. in Berlin), hab das aber mit Qgis nicht hinbekommen.

Nodes:

Ways:

Gruss
walter

wambacher · January 27, 2015, 1:45pm

Hi,

ich habe - hoffentlich - noch einen kleinen Fehler in der Irrläuferauswertung beseitigt. Es wurden nicht alle bearbeiteten Irrläufer aus der Fools-Liste gelöscht und tauchten immer wieder auf. Zwar als closed und somit nicht allzu schlimm, allerdings war dann der Timestamp der letzten Auswertung falsch. Man konnte meinen, dass überhaupt keine Auswertung gefahren wurde, da der Timestamp halt noch der alte war.

tl;dr: Timestamps der Bundesländer sollten jetzt ok sein.

Gruss
walter

edit: Feddich - 911 von 918 Irren sind noch einzufangen.

wambacher · January 27, 2015, 2:07pm

Hier noch mal alle zusammen - auch mit Relationen:

Fehlen eigentlich nur noch die Irrläufer - schau’n 'mer mal.

Gruss
walter

seichter · January 27, 2015, 5:30pm

Hinweis: Irgend etwas ist im Moment nicht in Ordnung.
Die Fools-Seite lädt ewig (übrigens auch die Int. Grenzen) und dann war die Top-Down-Liste mit den Ländern leer.
Jetzt gibt es die Länderliste wieder, aber dann eine Minute “loading records …”
Als positive Nachricht: Die Einträge mit ~~closed~~ done sind weg.

[edit]Reaktion wieder normal

wambacher · January 27, 2015, 5:42pm

kann ich schlecht nachvollziehen, da ich ja nicht übers das INET arbeite, sondern lokal auf dem Server schaffe. Und da sind die Zeiten ok.

Leider läuft mein Performance-Messer (Munin) noch nicht wieder, sodass ich keinerlei Übersicht über sowas habe. Wenn das öfters auftritt, melde das bitte nochmal.

Gruss
walter

wambacher · January 28, 2015, 8:00am

Hi,

jetzt scheint der automatische Fools-Update wohl zu funktionieren.

Startet um 3:00 Uhr CET/MEZ, schnappt sich die Daten von ca 2:00 Uhr UTC (Zulu-Time), je nachdem wie das Lag ist, macht die Auswertung und dated die Fools-Tabelle up.

Aktueller Stand: noch 837/852 Irre laufen frei rum Waren ja vor einigen Tagen noch über 5000.

Danke fürs Einfangen und Grüsse
Walter

viw · February 7, 2015, 5:41pm

Gestern früh ist im Opendatareich von Berlin der folgende Datensatz aufgetaucht:
http://daten.berlin.de/datensaetze/rbs-plz-postleitzahlengebiete-dezember-2014

Gehrke · February 7, 2015, 5:52pm

Und wie gut sind die so?

wambacher · February 7, 2015, 6:05pm

Bei denen steht:

muss man sich halt mal anschauen. Aber Datenstand auf jeden Fall Ende 2014.

aus: https://www.statistik-berlin-brandenburg.de/opendata/Beschreibung_RBS_OD_PLZ.pdf

Gruss
walter

FvGordon · February 7, 2015, 7:55pm

Wenn ich aus diesen Daten die PLZ-Grenze beim Stadtbahnbogen südlich S-Tiergarten ansehe, habe ich auf der Grundlage der Hausnummern in OSM eine bessere PLZ-Grenze eingezeichnet. Wenn jemand hier die PLZ-Grenze der PLZ 10555 wieder nördlich der Straße des 17. Juni, wie in diesen Daten und wie auch im Brandenburg-Viewer abgekürzt einzeichnet, haben wir wieder die Gebäude mit den Nrn. 491-496 als Fehler in der Fools-Liste.

Franz

wambacher · February 14, 2015, 2:09pm

Hi, nachdem mich Stephan gestern auf meine ~~Schlamperei~~ Vergesslichkeit mit der PCBoundaries-Map hingewiesen hat, packe ich die PLZ mal wieder an.

Als erstes Zwischenergebnis hier eine Karte der Regionen:

Und zu den Fools auch einige Bilder, die unter http://osm.wno-edv-service.de:82/index.php/projekte/postleitzahlen/irrlaeufer/irrlaeufer-statistik abrufbar sind.

dagegen aber

NRW stagniert irgendwie und da passiert recht wenig.

Und hier unser "Muisterländle

Gruss
walter

FvGordon · February 14, 2015, 3:02pm

In NRW sind fast nur noch einzelne Fehler - damit hatte ich gestern schon weitergemacht, um auf unter 400 gesamt-Fehler zu kommen. Aber nun repariere ich gerade die E 45-Route, die vor einigen Monaten alle Elemente verloren hat und inzwischen wegen der turn:lanes viele Elemente gelöscht wurden und noch mehr hinzugekommen sind (Richtung Süden habe ich schon lokal komplett bekommen, die andere Richtung ist zu 1/3 fertig, kann noch eine Stunde dauern).

Franz

dalchimsky · February 14, 2015, 4:00pm

Hi,

ich habe jetzt nicht alle 58 Seiten des Threads gelesen, aber warum gibt es eine Differenz bei der Anzahl der Einträge auf der fools-Seite?

z.B. steht oben in der Auswahlbox momentan “Nordrhein-Westfalen (190/190)” und unten rechts in der Ecke “Showing 1-10 of 162”.
Werden irgendwelche Einträge nicht angezeigt?
Bei allen Bundesländern taucht eine Differenz auf.

Grüße
Thomas

wambacher · February 14, 2015, 4:21pm

Oben stehen die Anzahl der Irrläufer pro Bundesland - also hier 190 und unten rechts die Anzahl der Zeilen der Tabelle. Und da es manchmal mehrere Irre pro Zeile gibt, ist die Anzahl der Zeilen fast immer kleiner.

Gruss
walter

ps: wenn beide 0 sind, stimmt es wieder

Gehrke · February 14, 2015, 4:36pm

Danke!

streckenkundler · February 14, 2015, 5:05pm

ein interessanter Fehler:

http://www.openstreetmap.org/relation/1351583

addr:postcode an der boundary-Relation… auch die anderen addr:*Angaben gehören meiner Ansicht nach nicht an die Relation… Nebenbei fällt auch die Nutzung nicht nutzbarer Daten ins Auge: Brandenburg-Viewer…

Fehler hab ich mal gelassen.

Sven

Nakaner · February 14, 2015, 5:42pm

Dann revertiere es doch. Und melde es bitte auch gleich der DWG. Von dem User liegen nämlich mehrere Beschwerden bei der DWG vor (d.h. er beschwert sich).

wambacher · February 14, 2015, 6:35pm

War gerade dabei, mich bei ihm zu beschweren, finde aber, es ist besser, die Diskussion im Forum zu führen und ihn nur hierauf hinzuweisen. ok so?

Oh Mann, die Liste wird immer länger.

Gruss
walter

wambacher · February 14, 2015, 6:57pm

@apl_pilot:

uns sind mal wieder Änderungen deinerseits aufgefallen, die absolut nicht in das Tagging-Konzept von Administrativen und/oder Postalischen Grenzen passen.

Es gibt voneineinander völlig unabhängige Relationen jeweils für die Administrative Grenze als auch die Postalische Grenze eines Ortes - auch wenn die absolut deckungsgleich sind.
die Admin-Grenze (Relation!) wird mit type=boundary, boundary=administrative und admin_level=AL getaggt.
die Postalische Grenze (Relation!) mit type=boundary, boundary=postal_code, postal_code=PLZ, getaggt.

Davon weichst du in erheblichen Ausmaß ab:

die Wege, die Member dieser Relationen sind, werden NICHT MIT DIESEN TAGS VERSEHEN - wenn man von boundary=adminstrative/admin_level=N absieht. Das ist eine histoische Altlast, die wir wohl beibehalten müssen/werden.
Namen für Grenzwege sind nicht üblich, und in deinen Editssogar oft falsch. Ein Grenzstück kann Trenner zwischen verschiedenen Administrtiven Einheiten sein (Land+Kreis+Ort+Stadtteil+PLZ-Gebiet, Wahlkreis+… ) und da ist EIN name=“Grenze zwischen A-Ort und B-Ort” einfach falsch.
addr:*-Tags an Grenzrelationen sind falsch. https://www.openstreetmap.org/relation/55770/history

tbc:

Wir (nicht ich alleine!) möchten dich bitten

a) diese unnötigen, widersprüchlichen und auch falschen Tags an deinen Objekten zu entfernen, falls wir noch welche übersehen haben sollten.
b) diese Vorgehensweise ab sofort zu unterlassen.

-wambacher-