iD scheint diesbezüglich irgendeine Überwachung zu besitzen, da mir mal beim Hochladen ein Konfliktfehler (das wohl zwischenzeitlich zufällig ein anderen Mapper an denselben Objekten dran war) ausgegeben wurde.
Konflikte werden vom OSM API erkannt und (hoffentlich) in jedem OSM-Editor angezeigt. Wenn aber mehrere Leute das gleiche Objekt mappen, also z.B. ein Haus, dann malt jeder einen Kasten und hängt building=* dran und lädt das hoch. Das ergibt keinen Konflikt, aber im Ergebnis mehrere sich überlappende / überschneidende Liniien. Sowas erkennt dann erst ein Mensch, der die Gegend im Editor runterlädt oder ein QA-Tool.
Das ist nicht das Problem.
das Problem ist, dass ich über ein bestehendes Objekt ein anderes drübermalen kann (egal welche Richtung) und der Validator nicht muckt
Ich bin gestern durch Zufall und unabhängig von diesem Faden auf eine Reihe von Duplikaten dieses Users gestoßen und habe das im Vorbeigehen korrigiert. Dass bereits eine Diskussion hier und in CS-Kommentaren läuft, war mir zu dem Zeitpunkt nicht bewusst. Die Duplikate wurden mir alle vom JOSM-Validator als “Doppelte Linien” und “Doppelte Straßenpunkte” gemeldet.
und 4. sind hier eigentlich unnötig. Wenn nach dem Hochladen die osm-Datei nicht gespeichert wird, bleibt die ID für den Weg 0. Da springt auch der Validator nicht an. Der springt erst an, wenn man Daten aktualisiert (Strg+U).
Natürlich kommen das Fenster was gemacht werden soll: Hochladen? Speichern? Wenn man hier aber was ignoriert, kommt es zu solchen Wegedubletten…
User MKnight schrieb ja, daß, wenn man einen Weg genau auf bekannte Stützpunkte mit osm-ID neu zeichnet, keine Fehlermeldung kommt…
Ich frage mich allerdings, wie man auf die Idee kommt, einen Weg doppelt zu zeichnen, wenn man ihn schon sieht…?
Man müsste noch mal schauen, ob vielleicht eine Kombination aus beiden passiert ist…
Ja, bei mir lagen Punkte nur übereinander… wenn man dann aber die verschmilzt, müsste es zum selben Effekt kommen, wie MKnight es beschrieben hat. Das habe ich aber nicht getestet…
Wie auch immer, irgendwie müsste das abgefangen werden.
Mein Vorgehen:
Ich lade ein Gebiet runter und lasse die Prüfung ohne Selektion laufen. Damit bekomme ich einen Überblick, was ohne mein Zutun schon an Fehlern/Problemen existiert. Dann beseitige ich entweder Fehler oder ich mappe das, was mir fehlt. Vorm Hochladen mache ich wieder eine volle Prüfung und schaue, ob neue Probleme dazu gekommen sind. Die versuche ich dann zu korrigieren. Dann erst wird hochgeladen.
Der Validator meldet mir sowohl dein Beispiel als auch die Objekte bei der Mehrzweckhalle in Granheim als “Fehler - Doppelte Linien”. Letztere sind zwar deckungsgleich, haben aber jeweils eigene Knoten, Beispiel:
Dazu fällt mir nichts mehr ein, außer raten…
…vieleicht das irgendwann mal auf die ignorieren-Liste gesetzt? Da mal schauen und mal die Einträge löschen…
Es gibt sich bei den Einstellungen für den Datenprüfer die Liste der Merkmalsregeln (zweiter Reiter)… das vielleicht mal zurücksetzen?
Man könnte in JOSM den “automatischen Test vor Upload” umbauen, so dass auch alle Tests funktionieren, die nicht nur ein einzelnes Objekt betrachten. Teilweise (insbesondere für die *.mapcss Tests) habe ich das bereits implementiert, aber in speziellen Situationen dauert der Test dann bereits jetzt sehr lange und u.U. sieht das für den Anwender so aus, als ob JOSM abgestürtzt wäre, weil es keine Fortschrittsanzeige gibt.
Es gibt mindestens ein weiteres potentielles Problem:
Der relativ hohe Speicherverbrauch einiger Tests kann JOSM unbrauchbar machen, wenn sehr viele Daten geladen sind. Sehr unangenehm, wenn das ausgerechnet beim Upload passiert.
Ist halt für den Entwickler immer schwierig, wenn sich Anwender drauf verlassen, dass JOSM schon meckern wird, wenn was falsch ist, aber umgekehrt auch immer alles(!) möglich sein soll und nichts “normales” lange dauern darf.