Kein Problem.
btw: heute früh hatte ich keine “Missing Postal_Codes”, ok so?
Gruss
walter
Jein. 33607 Bielefeld ist/war geometrisch im Nordosten kaputt. Hat osm2pgsql aber wohl “repariert”.
In Bielefeld machen mir die Grenzen häufiger Ärger. Es gibt merkwürdige Gebietsaufteilungen (inkl. Rolle “subarea”), die auch oft mit der Infratstruktur “verklebt” sind. Da passiert es beim Verschieben von Straßenpunkten sehr schnell, dass sich Grenzen selbst überschneiden.
Ich sollte wirklich einen Größenvergleich machen. Wenn von einem Boundary-MP (mit Löchern oder mehreren Outern) ein Teil defekt ist, merke ich das noch nicht. PLZ 33607 ist aber ganz normal. Komisch.
Es gibt Konsens in Deutschland, daß Subareas bei uns nicht verwendet werden sollen. Einfach rausschmeissen. Zur Not finde ich auch noch den Thread. Selbst die Kollegen auf Talk-DE hatten kein Problem damit.
Gruss
walter
ps: Bielefeld? Das gibt es doch garnicht 
Nee, das ist eigentlich nur ein simples Polygon. Aber es hatte einen Geometriefehler (Selbstüberschneidung). Davon merkst Du mit osm2pgsql nichts.
Noch nicht
Gruss
walter
Habe die PLZ-Waisen fertig durchgearbeitet und die meisten korrigiert (boundary=administrative gesetzt bzw. das postal_code Tag entfernt) oder gelöscht. Dabei sind folgende Linien übriggeblieben:
w86575374 note=“08439 Crimmitschau; replaced”
w86575393 obsolete_boundary=postal_code, type=multipolygon (PLZ 08138)
w51360434 admin_level=10 (ohne Relation), aber an den Endknoten schließen nur Linien mit Relationen mit AL8 an
w204365182 … w204373401 mehrere geschlossene Ringe in einer russischen Kleinstadt
w265907645 geschlossener PLZ-Ring in Spanien
w279439137 und w302115054 geschlossene PLZ-Ringe in den USA
w266705611 Erweiterung des PLZ-Bereichs über die Gemeindegrenze hinaus in der Schweiz (die Gemeinegrenze enthält weder an der Linie noch in den Relationen eine PLZ-Angabe)
Franz
Danke,
ich fahre nachher mal eine neue Waisenauswertung.
GRuss
walter
Über eine Fehlermeldung aus den Fools habe ich das Haus wiedergefunden, dessen Eingang zu zwei Hausnummern mit unterschiedlichen PLZ führt.
Franz
Lösung: addr:postcode von Entrance löschen nach dem Prinzip: Lieber keine Info als eine falsche.
done
Gruss
walter
Oder: Mal mit der Post reden.
Moin,
“Ich weiss nicht, ob sie es schon wussten:” 
Ich habe die Irrläuferauswertung ein wenig geändert. Da manche Bundesländer wie Bayern, Hessen oder NRW sehr lange brauchen und die ausgewerteten Daten sich bestimmt schon von den Live-Daten unterscheiden, habe ich die Auswertung für diese BL aufgeteilt.
Ab sofort werden hier Auswertungen auf AL5-Ebene gefahren, die zwar insgesamt wohl ein wenig länger brauchen als ein BL alleine, aber dafür zeitnaher zur Verfügung stehen.
Gruss
walter
ps: Bayern ist fast durch
Nachdem ich Bayern, Hessen und NRW in kleinere Bröckchen “zerlegt” habe und damit zeitnähere Auswertungen fahren kann, hab ich noch den “Brocken” Niedersachsen vor mir. Der braucht ca 28 Stunden und ist mir einfach zu groß.
Leider gibt es dort keine AL5, die ich dafür verwenden kann.
Frage: gibt es irgendeine Möglichkeit, NDS in Bereiche/Regionen aufzuteilen? Natürlich nicht als Administrative Grenze mit AL5, weil es die nicht gibt, sondern sowas wie Regionen, Landesteile , die man eventuell erfassen könnte. Mir schwebt sowas wie type=boundary, boundary=region, name=Ostfriesland vor.
Könnte dann nach dieser Aufstellung weitergehen.
Ansonsten behelfe ich mich mit lokalen Daten, indem ich die in meine DB eintrage aber nicht hochlade.
Gruss
walter
Es gab ja mal Regierungsbezirke in Niedersachsen. Guck mal in den Regionalschlüssel. Da sind die quasi noch als statistische Bezirke erhalten (Ziffer 3). Danach könntest Du gruppieren/filtern.
naja, “richtige” Relationen mit einer Id wären mir natürlich lieber (da einfacher auszuwerten).
Spricht den was gegen boundary=region? Sowas kommt doch immer wieder hier im Forum hoch. Westerwald, Pfälzer Wald, Harz, Rheingau, …
Ist hier wohl OT.
Gruss
walter
Mach Dir doch eine “special_boundary”-Tabelle, in der Du einmal mit PostGIS (ST_Union) die “Bezirksregionen” aus den Kreisen zusammenbaust.
Es gibt zumindest eine (sehr grobe) TMC-Relation für den Spessart.
Klaro, technisch ist das kein Problem für mich, träume ja Nachts schon von PostGis
Lösung1: Ich erstelle die Regionen lokal, zeige das Ergebnis in Qgis und dann könnt Ihr die immer noch in OSM haben.
Lösung2: Die TMC-Rels schau ich mir auch mal dahin an. Wenn die passen sollten (nicht zu viele und vollständig sind), kann man die ja nehmen.
Nee, geht nicht: Tmc sind Rels mit type=TMC und werden somit von osm2pgsql ignoriert.
Das Thema hatten wir zuletzt bei den - inzwischen wohl in der Versenkung verschwundenen - LEZ-Gebieten, wo ich ja lange um type=boundary, boundary=low_emmission_zone kämpfen musste. 
Ich zumindest sehe einen Bedarf für räumliche aber nicht politische Gliederungen. Sollte ich wohl einen eigenen Thread aufmachen.
Gruss
walter
Hmm, ich sehe darin eher eine Krücke für Auswertungen, die man auch gut lokal halten kann. Jede herleitbare Region als zusätzliche Member-Relation für Grenzsegmente macht das wacklicke OSM-Grenzgebilde noch einsturzgefährdeter.
Klar, ist ja auch am Anfang (s.o.) als Krücke gedacht gewesen (Tagging für den Auswerter - und das von mir! ;)) aber ich frage ja nur mal, ob jemand anders (nicht du) geographische Regionen gebrauchen kann.
Fortsetzung im eigenen Thread, wenn ich mit Stufe 1 (lokal) fertig bin.
Gruss
walter
Hi, benutzt eigentlich noch jemand meine Irrläufer-Liste im Wiki?
Eigentlich sollte ein Aufruf von Fools ja reichen um die aktuellen Fehler zu sehen. Denn bis ich das Wiki aktualisiert habe, hat ja meistens schon jemand “zugeschlagen”.
Wenn keine Einsprüche kommen, pflege ich die Liste nicht mehr - das ist bei dem ganzen Projekt die meiste Arbeit, der Rest geht fast automatisch.
Gruss
walter
Ja, meinen Segen hast Du. Du könntest viell. überlegen, im Wiki z.B. monatsweise eine Statistik über den Verlauf der Fallzahlen anzubieten (oder zu verlinken).