Pflege der deutschen PLZ-Daten in OSM

186 “Irre” in Sachen warten darauf, wieder eingefangen zu werden.

Dabei ein Block mit 170 Zwickauern. (*)

Gruss
walter

*) no comment. :wink:

Habe in Berlin bei 26 PLZ-Relationen die Member-Reihenfolge korrigiert (Ich mache das in DE andauernd). Warum mache ich das, wenn es nicht notwendig ist?
Wenn ich so etwas sehe, glaube ich erstmal nicht, dass der letzte Bearbeiter sorgfältig geprüft hat, ob seine Änderungen auch in Ordnung sind.

Ich sortiere auch als erstes die Mitglieder im Relationen-Editor, um die Geschlossenheit zu sehen.
Ich bin mir aber nicht sicher, ob beim Aufruf dieser Relation in einer späteren Sitzung die mir wieder sortiert geladen wurden, auch wenn die vermutlich noch nicht angefasst wurden.

Ja, josm lädt die in der Reihenfolge, wie sie vorher sortiert waren.

Gruss
walter

Wäre ja auch schlimm, wenn JOSM (oder irgendeine andere Anwendung) die Reihenfolge der Unterelemente einer Relation oder eines Ways durcheinanderbringen würde :wink:

Inzwischen habe ich die ersten 10 PLZ-Waisen aus Post #1329 bearbeitet:
Mehrere Straßensegmente hatten noch das PLZ-Grenz-Attribut, aber die Grenze wurde inzwischen ein Stück verschoben.
In München habe ich aus der ehemaligen PLZ-Grenze eine AL10-Grenze gemacht (z.B. w69685350).

Franz

Prima, ich werte das Zeug nachher nochmals aus.

Gruss
walter

@jan

ich mache jeden Morgen um 5:00 Uhr auch eine PLZ-Analyse, die “Missing Postcodes” finden soll. Die hat aber seit mindestens zwei Wochen nichts mehr gefunden. Hätte die heute nichts finden müssen, da ja zwei AL8 defekt waren?

Oder bist du Frühaufsteher und korrigierst nach deiner eigenen Analyse?

Ich möchte halt sicher sein, daß ich mich auf meine Auswertung auch verlassen kann.

Gruss
walter

Ende von missing_postcodes.log:


...snip...
psql:/home/walter/osm/db/misc/plz/find_missing.sql:3: NOTICE:  after big query
psql:/home/walter/osm/db/misc/plz/find_missing.sql:3: NOTICE:  cnt=8306

 checking for missing pcboundaries


 checking for new pcboundaries

Di 30. Sep 05:03:05 CEST 2014

Ja, ich mache eine eigene Analyse und korrigiere vormittags - nicht vor 8.
In den letzten Tagen musste ich auch öfter defekte PLZ-Relationen korrigieren.
Könnte daher gut sein, dass in Deiner Auswertung etwas schräg ist.

Heute morgen waren definitiv die PLZ 54533 und 54538 defekt, weil w56971238 kaputt-optimiert wurde.

Meine ich doch, dass da was bei meiner Auswertung falsch sein könnte.

Nur noch zur Problemeinkreisung: Waren die beiden PLZ-Relationen in deiner DB komplett weg oder nur “angeknabbert”? Im 2. Fall müßte ich wohl den Größenvergleich wie in der Boundaries-Auswertung einbauen. (sollte ich eh machen?)

Gruss
walter

Die 54533 wurde flächenmäßig halbiert. Die 54538 müsste bei Dir komplett weg gewesen sein. Meine DB funktioniert anders (eigene Erweiterung des Snapshot-Schema); da ist nichts weg, aber es kann empty polygons geben - sogar noch eher als bei Dir, weil Geometriefehler wie Selbstüberschneidung nicht toleriert werden.

Ja, kaum macht man es richtig, funktioniert’s :slight_smile:


         dtm         
---------------------
 2014-09-30 18:07:01
(1 row)

 country | Missing postal code |          PcArea           |   id    |                         rel                          
---------+---------------------+---------------------------+---------+------------------------------------------------------
 DEU     | 12205               | 12205 Berlin Lichtenfelde | 1101157 | http://www.openstreetmap.org/browse/relation/1101157
 DEU     | 14169               | 14169 Berlin Zehlendorf   | 1395643 | http://www.openstreetmap.org/browse/relation/1395643
 DEU     | 54538               | 54538 Bausendorf          | 1257313 | http://www.openstreetmap.org/browse/relation/1257313
(3 rows)

 country | New postal code | PcArea | id | rel 
---------+-----------------+--------+----+-----
(0 rows)


War war los? Man sollte auch das richtige Logfile betrachten, dann sieht man auch die Abweichungen.

Das ist die Auswertung von heute früh und nicht etwa eine aktuelle.

Danke und Gruss
walter

magst du mir dein Schema bitte mal schicken? oder die “kritischen” Zeilen hier auflisten?

Ansonsten bin ich dabei osm2pgsql aufzubohren; inbesonders was fehlerhafte Polygone betrifft. Irgendwie scheint was mit der nahezu unbekannten Option/Funktion exclude-invalid-polygon bzw. exclude_broken_polygon() nicht zu funktionieren.

Gruss
walter

Schicke ich Dir heute oder morgen noch zu. Im Moment komme ich nicht dazu.

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 :wink:

Nee, das ist eigentlich nur ein simples Polygon. Aber es hatte einen Geometriefehler (Selbstüberschneidung). Davon merkst Du mit osm2pgsql nichts.

Noch nicht :wink:

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