Bei KeepRight habe ich es mit einer Email versucht, mal sehen. Vielleicht sollte man im wiki die Anleitung etwas ändern - in dem Sinne “lieber einen gut sichtbaren Fehler stehen lassen als Fehler durch Tricks zu verstecken” ?
Bei den automatischen Prüfungen sollte man z.B. auch beachten das es kleinere und größere Bäche ohne Brücke oder Röhre gibt.
OK, dann sollte man eine Furt, Key:ford, eintragen, aber wer macht das bei einem kleinen “Rinnsal”.
Teilweise habe ich es gemacht, aber es gibt hier sicher Stellen wo es noch fehlt, das werde ich mal ansehen.
Wenn das Rinnsal bedeutend genug erschien, um als waterway eingetragen zu werden, sollte auch jede Kreuzung mit einem highway (drüber oder mitten durch) bearbeitet werden. Zumindest für den Nicht-Amphibien-Fahrer ist ja schon von Interesse, was ihn da in etwa erwartet.
Ich würde das aber nicht unter Mapping-Unfälle einordnen, eher unter Mapping-Unsitten.
Es sollte recht straight-forward sein, Fehler in Grenzrelationen zu erkennen, die aus geschlossenen Polygonen bestehen sollten.
Durch Unachtsamkeit und Unwissenheit bzgl. Relationen entstehen allein in Deutschland täglich “geöffnete” Relationen. Immer sehr ärgerlich.
In der Software-Entwicklung würde man das wohl mit automatisierten Tests und ggf. Check-In-Hooks angehen. Ein fehlerhafter Edit würde dann schon vor dem Check-in erkannt und nicht zugelassen.
Ob da durch das Role-Mismatch entstanden ist, weß ich nicht. Ein zurückschieben funktioniert leider nicht mehr, da andere Teile (die wohl danach eingetragen wirden) dann nicht mehr passen würde. Also Bleibt nur Handarbeit der Stützpunkte…
@ Oli-Wan: Wie du siehst besteht (dringender) Bedarf an dem von dir vogeschlagenen Tool.
Mal so als Frage für zwischendurch, weil es mich interessiert: Hast du vielleicht schon ein klareres Bild davon, wie das Tool arbeiten soll? Hast du Unterstützung von der Data Working Group erhalten? Wie können wir dir weiter helfen, außer Mapping-Unfälle zu sammeln?
Bist du sicher, dass da nicht jemand einfach Taggs von den Outer-Linien an ein Multipolygon verschoben hat (oder zumindest wollte)? In dem Fall gibt es solche Tagg-losen Linien.
Bei längeren Linien markiere ich die zumindest mit einer Beschreibung, wozu die Linie gehört. Aber daran denken nicht viele.
Upload-Probleme halte ich für ziemlich unwahrscheinlich. Die einzige vorstellbare Konstellation in dieser Richtung wäre, daß die ungetaggten Wege Teil eines Multipolygons werden sollten und dieses nicht erzeugt bzw. geändert werden konnte. Da der User (m/w) aber sonst auch keine MP verwendet hat, ist das wenig plausibel. Außerdem scheinen die Änderungssätze mit einer “krummen” Zahl von Objekten korrekt geschlossen worden zu sein; ein konfliktbedingter Abbruch erfolgt in der Regel nach einem “runden” Block und der Änderungssatz bleibt offen.
Butterspekulatius: vielleicht hat er - evtl. versehentlich - einen Weg aufgespalten, wieder verlängert und vergessen, die Schnipsel aufzuräumen.
Aber warum fragst Du ihn nicht einfach selbst? Der User ist sogar seit kurzem (wieder) hier ein bißchen im Forum unterwegs, kann also doch nicht so schwer zu erreichen sein. Wenn Du ihn ansprichst, weise ihn bitte auf jeden Fall auf den JOSM-Validator hin: die ungetaggten Wege wird JOSM beim Hochladen mit Sicherheit gemeldet haben. Viele Fehler wären vermeidbar, wenn die Leute die Warnmeldungen beachten und mindestens ihre eigenen Fehler im Rahmen ihrer Möglichkeiten beheben würden. Manches kann JOSM ja sogar ganz alleine.
Ihn anzuschreiben hatte ich vor, wollte mich aber vorher bei den Gurus im Forum schlau machen, wie so etwas zustande kommen kann. So etwas ist mir in der Masse bisher nie untergekommen. Dann schreibe ich mal am Wochenende…