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.
Wäre ja auch schlimm, wenn JOSM (oder irgendeine andere Anwendung) die Reihenfolge der Unterelemente einer Relation oder eines Ways durcheinanderbringen würde
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).
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?)
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.
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.
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.
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:
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)