OSM-Fools: Einfachere Verwaltung der PLZ-Irrläufer

Ich hab noch 'ne kleine Erweiterung gemacht: oben in der Auswahlliste steht bei “Alle Bundesländer” jetzt die aktuelle Anzahl der Irrläufer in der Irrläuferliste drin, so wie bereits schon bei den einzelnen Bundesländern.

Ist nicht viel, aber wenn da “0” steht, stürzt mein Programm ab haben wir es geschafft. :wink:

Gruss
walter

Über die Update-Problematik grübel ich noch.

Es gibt da zwei Möglichkeiten. Entweder du übernimmst den alten Status für diese Objekte wenn sie in der Auswertung nochvorhanden sind oder du brauchst den Zeitstempel der Änderunge des Attributtes und kannst dann darüber entscheiden wer aktueller ist. Deine Auswertung oder die Erledigung.
Auf die Art bekommst du auf jeden Fall auch Änderungen die nur irrtümlich als berichtigt galten wieder auf den offenen Status.

Besser wäre natürlich bei den gefunden Nach eintrag eine Nachprüfung zu machen. Das wolltest du eh mal in Angriff nehmen wenn die Kinderkrankheiten weg sind :wink:

Ja, das mit dem Timestamp der Status-Änderung könnte es werden. Nur muß der erst mal rein.

jaja, wie war das mit dem Kleinen Finger? :wink:

Gruss
walter

Der JOSM-Link funktioniert bei mir leider nicht.

Muss

Muss am zertifikat liegen. Check das mal

-w-

lies mal Seite 2 dieses Beitragsbaumes die Unterhaltung zwischen mir und berndw…

speziell: http://forum.openstreetmap.org/viewtopic.php?pid=438350#p438350

Sven

sorry, verzögert sich noch ein wenig mit den neuen Auswertungen. Ist komplexer als ich dachte - aber zu schaffen.

Gruss
walter

Könnte bitte jemand (@Gehrke?) nach:

Sachsen	01723	01737 Tharandt u.a.	7	open 1	2014-07-19 23:08:02Z

schauen.

Habe die Grenze Grumbach/Braunsdorf (AL 10) nach meinen Kenntnissen verschoben und müsste in Ordnung sein. Diese Grenze läuft im Süden noch ein Stück zur Grenze Wilsdruff/Tharandt parallel und müsste eventuell korrigiert werden. Im Nordosten ist der Grenzverlauf Grumbach/Kesselsdorf mir nicht genau bekannt.

EDIT: auch geändert (Grenze Bretnig-Hauswalde und Rammenau)

Sachsen	01900	01877 Bischofswerda	4   open 1	  2014-07-19 23:08:02Z	

Im Prinzip schon - habe auch die PN zum Thema Grumbach/Willsdruff erhalten, aber ich kann da wegen Zeitmangels (und Urlaubs) erst am Montag oder Dienstag nächster Woche ran.
Wenn das zu spät ist, müsste ein anderer einspringen.

Dann schönen Urlaub - ich wollte nur nichts “kaputtmachen” - weil Grenzen (Relationen) nicht so mein “Ding” sind.

Es bleibt zumindest mal festzuhalten, dass Postleitzahlen als Gebiete mit Relationen einzutragen, bei OSM sehr hohen Aufwand und viel Wartungsarbeit bedeutet.Vielleicht doch als Extralayer und PLZ ansonsten besser an die Häuser ran?

Hier ging es aber auch um Gemeinderelationen. Ich bin aber auch der Meinung, dass alle Grenzen in einem oder mehreren separaten “Datenlayern” besser aufgehoben wären. Das gilt aber auch für so manch andere “Spezialinteressen” in OSM. Leider gibt das die API und das Datenmodell (noch) nicht her.

Das was OSM durch die PLZ-Relationen kann (Karten, Geocoding), kann derzeit keiner in der Qualität. Apropos Qualität: Durch die OSM-Relationen haben wir tausende falsche PLZ-Angaben korrigiert. Ohne die wäre das kaum möglich gewesen.

+1, da wäre aber dann das Problem, wenn sich Grenzen z.B. mit Flüssen den gleichen way teilen. Vielleicht würde es ja auch schon helfen, wenn die API den Upload von defekten (Multi-)polygonen verweigern würde.

Geteilte Punkte wären in der Tat eine Herausforderung dabei, aber nicht unlösbar (Ändern verboten/eingeschränkt). Diese Diskussion gehört aber wohl nicht in diesen Thread und ist faktisch leider eh irelevant.

Josm “motzt” ja schon bei unvollständigen, normalerweise geschlossenen Relationen - aber dennoch werden die einfach hochgeladen.

Defekte Rels (z.B. Überschneidungen) zu erkennen ist noch aufwändiger. Das kann schon mal einige Sekunden pro Rel dauern, wäre aber für Josm wohl noch akzeptabel.

Die Api als Interface zum Datenspeicher würde da wohl mit überlastet sein.

Nur:

  • nicht alle benutzten Josm
  • die Validierung in den anderen Editoren ist schwach
  • es wird dennoch hochgeladen

Meine Hoffnung: Der Area-Typ sollte wesentlich einfacher strukturiert sein - ein Way für eine Fläche, nix mit Multi-Kulti - und somit on the Fly überprüfbar sein. (*)

Gruss
walter

*) Bin schon über 50, ob ich die Api-0.7 wohl noch erleben werde? :wink:

Iirc aber nur, wenn die Relation vollständig (und vorallem: überhaupt) geladen ist, was bei frisch beschädigten Relationen oft nicht gegeben ist.

jo, hast du Recht.

aber selbst wenn er “hellseherisch” alle möglichen Fehler erkenne könnte, wird das Zeug hochgeladen.

“Multipolygon? Boundary? Member? Role? Was ist das denn? - Egal, hoch damit!”.

Gruss
walter

JOSM meckert aber über so vieles, daß die user dazu konditioniert werden, ihre Änderungen ungeachtet der Warnungen hochzuladen.

Baßtölpel

Wenn ich mal eine Grenze beschädige, liegt das stets daran, dass ich die betroffenen Relation nicht korrekt/vollständig heruntergeladen habe. Für die kann natürlich kein Fehler gemeldet werden. Immer alles runterladen ist bei Relationen aber auch nicht so ohne Weieters möglich, da dann mein Speicher überläuft oder JOSM einfach streikt. Manchmal ist es schlicht meine Unachtsamkeit. Aber Relationen, die JOSM anmeckert, habe ich nie hochgeladen.

Habe gerade alle sechs Zeilen von OSM-Fools (Mecklenburg-Vorpommern) in Rostock und beide Zeilen in Schwerin korrigiert, aber beim Bestätigen, dass der Fehler behoben ist, meldet das Tool nur einen Kommunikationsfehler mit dem Server und deshalb kann ich diese Zeilen nicht auf “done” setzen.

Franz