Die erste Uhrzeit (19:19:49) gibt den Start der Auswertung an. Die brauche ich um daraus die Laufzeit (End-Start) zu berechnen.
Der Timestamp der DB zum Zeitpunkt der Auswertung stand auf 2014-04-16T15:25:02Z, das ist 2014-04-16T17:25:02 MESZ (Z steht für Zulu-Time). Da du aber erst um 17:50 verschoben hast, hatte die DB natürlich noch die alten, fehlerhaften Positionen.
habe Hamburg nochmals angeworfen und heute Nacht rennt NRW
Gruss
walter
@sennewald: eventuell liegt dein 21a-Problem auch an sowas?
bin gerade in Sachsen-Anhalt bei Magdeburg angekommen.
Die Brennecketraße 4b und 6 müssen mit in die PLZ-Relation 39118, da hängen aber derzeitig auch noch Admin-Relationen mit dran.
allerdings keiner mit nachlaufenden Blanks. Jetzt muß ich noch die Ways abfragen, ob da welche sind.
Gruss
walter
ps: die Nodes fixe ich natürlich jetzt.
edit:
der erste Node hat eine dänische Adresse, liegt aber laut der Grenzrelation in Deutschland. Da sind aber noch drei Grenzsteine in der Nähe erfaßt. Wenn dort die wirkliche Grenze sein würde, wäre alles ok. **Kann sich das mal jemand bitte näher ansehen?
**
der 2. Node (Meilerhütte in den Alpen) lag fälschlicherweise in Deutschland, ist aber eine korrekte österreichische Adresse. Eine kleine Schiebung und einer weniger
querfurt: Haus liegt nördlich der PLZ-Grenze, also im falschen Gebiet.
marinapark: das selbe
die grenze schau ich mir mal an, dauert etwas länger.
Gruss
walter
Nachtrag: Warum hast du die Administrative Grenze nicht einfach verschoben? Daß die mitten durch diesen Flecken geht, kann doch eh nicht stimmen. also: wozu gehört Drackenstedt?
und warum überhaupt hochgeladen? wenn ich was an Grenzen mache und danach Josm “motzt”, fixe ich erst das Problem, lade aber auf keinen Fall hoch.
Nachtrag2: so, ich hab mich mal für eine Lösung entschieden. du kannst ja die Admin-Grenze jetzt verschieben, wenn ich falsch geraten haben sollte.
In Erfurt und Magdeburg war leider einiges an den innerstädtischen und PLZ-Grenzen kaputtgegangen.
Besonders in Magdeburg musste ich ganz schön herumdoktern. Da waren Grenzen teils doppelt gelegt u.ä.m. Geometrien war auch im Eimer.
EDIT: Ich musste in Magdeburg ein fehlendes Grenzsegment raten und neu hinzufügen (way 275186792).
Alles klar mit der Grenze; hatte ich mir ja schon gedacht, auch wegen der ungenutzten Grenzsteine.
SH schmeisse ich an, wenn die Datenbank nach den heutigen Problemen aktualisiert ist. Könnte bis heute Nacht dauern aber morgen früh sollte eine aktuelle Auswertung da sein.
Dreileben (Ortsteil von Wanzleben-Börde) PLZ 39164 und Drackenstedt (Ortsteil von Eilsleben) PLZ 39365 teilen sich den Bahnhof Dreileben-Drackenstedt und die Grenze geht nach meinen Unterlagen da wirklich mitten durch.
Das kommt aus der Zeit als die Bauern noch auf dem Feld gearbeitet haben, der Gutsherr einen Kutscher hatte und die Kartoffeln und Zuckerrüben auf kürzesten Weg in die Wagons verladen wurden.
Nach meiner Ansicht von heute Früh gehört der Bahnhof Dreileben-Drackenstedt zur PLZ 39365, denn die Straße “Dreilebener Bahnhof” (von Wanzleben-Börde) als auch "Am Bahnhof (von Eilsleben) liegen laut Karte des plzserver im PLZ-Bereich 39365.
Zur Fehlermeldung von JOSM, mir wurde nach dem Aufspalten der PLZ und Grenzrelationen der Fehler 4 überlappende Linien Angezeigt. An den Punkten die ich erzeugt hatte habe ich aber nichts gefunden und mit Punkte vereinigen konnte ich auch nichts beheben.
Also für mich war da nichts zu finden, deshalb habe ich ja auch nochmal um Prüfung gebeten.
ja, da lagen mehrere ways übereinander; hab die halt gelöscht und den letzten in alle Grenz-Rels gepackt. Dann war Ruhe.
Ist nicht schlimm, ich schlage mich schon seit ca 2010 mit Grenzen rum und das war - für mich - ein Klacks. Da gibt es wirklich Schlimmeres (z.B. in Cuba, wo ein Newbie Amok gelaufen ist)