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? 
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
ja, hab ich gesehen. ich suche noch.
gruss
walter
oops: ist bei allen Datensätzen von Meck-Pomm, Brandenburg und BW der Fall. Liegt wohl am gestrigen Update.
melde mich wieder.
so, ich hab es wohl korrigieren können.
Update des Status sollte jetzt wieder sauber funktionieren.
Gruss
walter
Jetzt wohl endlich endgültig fertig:
Fools 1.2.1 zeigt jetzt die Anzahl der offenen und die Anzahl aller Irrläufern an (open/total). Damit kann man leicht erkennen, wo noch was zu tun ist.
Gruss
walter
Berlin 41 runter auf 7.
Gruss
walter