Moin!
Wegen Selbstüberschneidende Linien: arbeitet der Datenprüfer bei JOSM sauber?
schaue ich mir gerade an, was JOSM eigentlich bisher alles prüft, wenn ich z.B.
S1) einen Highway-Knoten verschiebe oder
S2) einen Weg trenne, der zu einer route=* Relation gehört, um dem einen Teil ein anderes surface=* zu geben
und dann sofort den Upload starte.
Ich hätte erwartet, dass eine Liste der Objekte erstellt wird, die zum Server hochgeladen werden müssen und diese Liste dann durch die Prüfungen “geschickt” wird. Die einzelnen Prüfungen schauen evtl. auf weitere Daten, um z.B. bei 1) herauszufinden, dass nun eine Straße einen Fluß kreuzt.
Was tut JOSM tatsächlich?
Beim verschobenen highway-Knoten wird genau nur dieser Knoten geprüft, nicht aber die Wege, die zu diesem Knoten “gehören”. Geometriefehler wie “Spitzer Winkel” werden so bisher nicht gefunden, genausowenig Fehler wie “Überschneidung Gebäude/Straße”
Es werden - wie erwartet - der neue Wegteil und der alte Teil geprüft sowie die Routen-Relation, die sich ja geändert hat, aber auch alle anderen Wege der Routen-Relation, die sich in den heruntergeladenen Daten befinden und auch noch deren Knoten.
In meinem Fall führt das dazu, dass mir ein
" Verdächtige Merkmalskombination - tracktype=grade2 zusammen mit surface=ground (1)"
angezeigt wird und natürlich stoppe ich den Upload, um mir das anzuschauen. Die Meldung bezieht sich aber eben nicht auf die Wegteile, die ich gerade bearbeitet habe, sondern auf einen anderen Weg, der auch zur Route gehört und “zufällig” auch in meinen Daten mit drin ist.
Ich würde es eigentlich genau anders rum haben wollen:
Die Verschiebung eines Wegknotens sollte mindestens dazu führen, dass auch der Weg geprüft wird und so möglichst alle dadurch entstandenen Geometriefehler gefunden werden. Es gibt da aber so einige Problemfälle. “Beliebter” Fehler: Ich rücke einen landuse=residential Wegknoten zurecht und sehe nicht, dass nur ein Teil der Daten runtergeladen ist und damit JOSM gar nicht erkennen kann, dass sich jetzt anderswo Gebiete überlappen oder schneiden, nicht mal, wenn ich die Komplettprüfung anwerfe.
Die Änderung eines Mtgllieds in einer Relation sollte nicht dazu führen, dass mir die (alten) Fehler oder Probleme in anderen Mitgliedern aufgelistet werden, aber da das mindestens seit 2010 so passiert, bin ich da wohl eher alleine? Ich finde das insbesondere dann sehr störend, wenn ich z.B. einen neuen separaten Radweg mappe und dann die Radrouten darauf “verschiebe”. Dann lade ich normalerweise jeweils die komplette Routen-Relation. Beim Upload bekomme ich dann jede Menge Fehler gemeldet, die oft +100 km von der Stelle entfernt sind, an der ich etwas geändert habe. Wer nur mal Relation 1988827 (D7) mit “Relationselementen” runterlädt und dann die Komplett-Prüfung startet, weiß, was ich meine.
Was machen andere OSM-Editoren da? Was sollte JOSM machen?
Gehört zwar nicht direkt zu den Prüfungen, macht diese aber oft erst möglich:
Vielleicht wäre gut, wenn bei geänderten Objekten grundsätzlich die unmittelbar anhängigen Objekte heruntergeladen werden.
Also bei verschobenen Nodes auch die Ways, die noch dranhängen - Nodes müssen ja nicht nur das geladene Objekt betreffen das z.B. geradegezupft wird, sondern kann auch Teil einer Kreuzung/Abzweigung sein. Es wurden schon ganze Straßenzüge verschoben ohne zu merken, was angerichtet wurde (eine Straße verschoben, hunderte geänderte Nodes mit Straßensalat (analog Kabelsalat)). Dann gäbe es die Möglichkeit, den Upload abzubrechen.
Bei geschnittenen oder gemergten Ways sollten auch anhängige Relationen automatisch geladen werden, damit man sieht was man eigentlich verändert und das ebenfalls korrigieren kann. Meist auftretend: Für neu einzupflegende Grenzen wird eine Grundlage an Relationen geladen, um die Linien zu erhalten, und das reicht nicht.
Bei zu löschenden Elementen (also auch beim Mergen) prüft der Server, ob das Element nicht noch wo dazugehört → Konflikte erst lösen, beim Splitten entstehen Lücken in ungeladenen Relationen egal welcher Art. Das passiert auch oft bei Route-Relationen, wenn ein Straßenabschnitt für andere Merkmale abgetrennt wird.
Mit zunehmender Komplexität - also Datendichte und Anhängigkeiten zwischen den Elementen - wird es immer schwieriger und eher nur für erfahrene Leute machbar, neue Daten unfallfrei einzupflegen. Da müsste wenigstens die Kenntnis davon, was man eigentlich alles ändert, verbessert werden.
Ich hatte kürzlich das Problem, dass ich eine ganze Straße kopiert und eingefügt habe, statt nur die Tags zu kopieren. Das habe ich aufgrund der Zoomstufe nicht gesehen und JOSM hat auch nicht gewarnt, obwohl zahlreiche andere Straßen und Gebäude geschnitten wurden.
Arbeiten mit unvollständigen Daten birgt viele Risiken und wird auch nur erfahrenen Personen geraten. Besser ist es auf jeden Fall mit vollständigen Daten und Filtern zu arbeiten. Zu einigen Deiner Vorschläge gibt es auch schon Tickets und wenn nicht macht es Sinn für jedes Beispiel eines zu erstellen.
Hier geht es um Probleme bei der zu starken Eingrenzung der zu prüfenden Objekte beim Hochladen und dabei sollten wir von vollständigen Daten ausgehen. Ansonsten wird dies ein Thread ohne Boden.
Persönlich, kann ich nur sagen, dass ich ehe immer manuell alle Daten vor dem Hochladen prüfe, daher bekomme ich die Probleme der Unterschiede zwischen manueller Prüfung und Prüfung vor dem Hochladen nicht mit.
zu 2.: Ich verstehe, Dein Anliegen, aber frage mich ob es technisch möglich ist hier eine Unterscheidung zwischen Regeln, welche sich nur auf veränderte Objekte beziehen sollen, und Regeln, welche zumindest die angrenzenden Mitglieder betrachten sollen, zu machen. Persönlich lade ich nur angrenzende Mitglieder herunter, wenn ich mich nicht für die Relationen als ganzes interessiere, was allerdings auch so manche Validator Warnung hervorrufen kann (z.B. “incomplete Multipolygon was modified”).
Hast Du ein Beispiel für eine solche Prüfung? Kann mir gerade nicht vorstellen, warum andere Wege einer Relation geprüft werden müssten. Das die Relation selbst geprüft werden muss ist klar und das bei der Prüfung evtl. auch die benachbarten Wege angeschaut werden, auch. Aber warum sollte der benachbarte Weg selbst z.B. darauf geprüft werden, ob er irgendein veraltetes Tag hat oder zu lang ist oder so was?
Vielleicht habe ich Dich ja falsch verstanden. Prüfung, welche sich einzig allein auf die unveränderten Mitglieder beziehen unabhängig davon, ob sie Mitglied einer Relation sind oder nicht, sollten unterdrückt werden. Aber alle Prüfungen welche sich nur im Entferntesten auf Relationen beziehen, z.B. bicycle=no als unverändertes Mitglied einer veränderten route=bicycle sollten weiterhin erscheinen, da JOSM nicht weiß, was Du genau an der Relation geändert hast und es möglich ist, dass Du das Mitglied neu hinzugefügt hast.
da ich ja gewissermaßen der “Ideengeber” zu mindestens eines Problems war:
quote=“GerdP, post:1, topic:107834”]
Ich würde es eigentlich genau anders rum haben wollen:
Die Verschiebung eines Wegknotens sollte mindestens dazu führen, dass auch der Weg geprüft wird und so möglichst alle dadurch entstandenen Geometriefehler gefunden werden. Es gibt da aber so einige Problemfälle. “Beliebter” Fehler: Ich rücke einen landuse=residential Wegknoten zurecht und sehe nicht, dass nur ein Teil der Daten runtergeladen ist und damit JOSM gar nicht erkennen kann, dass sich jetzt anderswo Gebiete überlappen oder schneiden, nicht mal, wenn ich die Komplettprüfung anwerfe.
[/quote]
In dem von mir gestarteten Beitragsfaden hatte ich die Situation geschildert…
@GerdP ja, so in diese Richtung würde ich mir die Lösung vorstellen!
OK, die Variante muss ich mal anschauen.
Vielleicht muss ich da noch mal was klar stellen:
In JOSM gibt es ja divese verschiedene Tests, die auch noch mit verschiedenen Methoden implementiert sind, insbesondere Java und MapCSS.
JOSM bildet vor dem Upload erst mal eine Liste von Objekten, die geprüft werden sollen (um diese Liste geht es mir gerade).
Dann wird jeder einzelne Test nacheinander mit diesen Objekten “geefüttert” und anschließend gefragt, welche Fehler dabei gefunden wurden. Der einzelne Java-Test kann dann praktisch beliebige weitere Objekte anschauen, falls das nötig ist, aber das muss dann im einzelnen Test irgendwie kodiert sein. Bei den MapCSS-Tests ist das nicht ganz so einfach, die können z.B. nicht “mal eben” alle anderen Objekte mit power=* anschauen, aber durchaus auch mehr als nur das gerade aktuelle Objekt, z.B. die Tests in geometry.mapcss, die Meldungen wie “Ferry route is not connected to the road network or branches.” bringen.
Nachdem alle Tests gelaufen sind wäre ausserdem denkbar, die Fehler auszusortieren, die keines der hochzuladenden Elemente betreffen. Das ist aber eigentlich die unschönste Methode, weil man erst Rechenzeit investiert, um den Fehler zu finden und dann noch mal, um ihn wieder zu vergessen. Also eine Notlösung. Wenn Zeit und Geld für Strom egal sind, dann könnte man ja immer einfach alle Objekte testen und anschließend die “uninteresanten” Meldunge löschen. Bei Leuten, die nur kleine Bereiche runterladen ist das wohl egal, aber wenn man viele Daten geladen hat, dann kann ein Komplett-Test mehrere Minuten dauern oder gar wegen Speichermangels stehen bleiben. Darauf will man bestimmt nicht warten, wenn man nur wenig geändert hat und die Änderung hochladen will.