Beispiele für Mapping-Unfälle und Vandalismus gesucht

Üblicherweise hat jemand den tag ergänzt, damit KeepRight Ruhe gibt statt Brücken oder Düker einzuzeichnen.

QA steht für Quality Assurance, also KeepRight, OSMInspector etc. http://wiki.openstreetmap.org/wiki/QA

Baßtölpel

ach so, für JOSM habe ich schon ein ticket eröffnet: http://josm.openstreetmap.de/ticket/9182

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.

Mapping-Unfall: Verschobener Wald…

Da bin ich heute drauf gestoßen:
http://tools.geofabrik.de/osmi/?view=routing&lon=13.92636&lat=51.91998&zoom=12

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… :expressionless:

Edit: hier der Link zur Relation: http://www.openstreetmap.org/browse/relation/1906768

Sven

@ 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?

wieder hingeschoben.

Changeset: http://www.openstreetmap.org/browse/changeset/18432804

Sven

http://taginfo.openstreetmap.org/keys/?key=layer#values

Legale/empfohlene Werte -5,…,0,…,5

layer=spaceport :)))

Irgendjemand hat wohl an einer größeren Relation herum gebastelt und dabei die Ländergrenzen (adminlevel 4) zerschossen:
http://www.flosm.de/html/Verwaltungsgrenzen.html?accthm=osm-admin0&startx=15.1287698745728&starty=53.5383911132813&startr=325131.28125&grp_adminlabelc=1&grp_adminc=1
Die Daten sind aus dem noch aktuellen(?) planet-file vom 10. Oktober.
Ich hbe mir das zwar mal angeschaut, bin aber nicht schlauer geworden, wo da genau was kaputt gegangen ist.

tha

Schicke Karte. Des weiteren fallen mir die fehlenden PLZ Areas östlich von Düsseldorf und Hannover auf.

Hannover habe ich eigentlich gestern komplettiert. Neben Düsseldorf sehe ich noch Lücken in Hamburg.

Das fiel mir heute in keepright auf:
http://keepright.ipax.at/report_map.php?lang=de&ch30=1&ch40=1&ch50=1&ch60=1&ch70=1&ch90=1&ch100=1&ch110=1&ch120=1&ch130=1&ch150=1&ch160=1&ch170=1&ch180=1&ch191=1&ch192=1&ch193=1&ch194=1&ch195=1&ch196=1&ch197=1&ch198=1&ch201=1&ch202=1&ch203=1&ch204=1&ch205=1&ch206=1&ch207=1&ch208=1&ch210=1&ch220=1&ch231=1&ch232=1&ch270=1&ch281=1&ch282=1&ch283=1&ch284=1&ch291=1&ch292=1&ch293=1&ch311=1&ch312=1&ch313=1&ch350=1&ch370=1&ch380=1&ch411=1&ch412=1&ch413=1&number_of_tristate_checkboxes=7&highlight_error_id=0&highlight_schema=0&lat=48.32786&lon=8.07116&zoom=14&show_ign=0&show_tmpign=0&layers=B0T&ch=0%2C30%2C40%2C50%2C70%2C110%2C120%2C130%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C231%2C232%2C270%2C291%2C292%2C293%2C311%2C312%2C313%2C350%2C370%2C380%2C20%2C300
Die braunen Pfeile deuten auf Linien ohne tags hin, welche wohl aus diesem Änderungssatz (und anderen desselben Users vom gleichen Tag) stammen:
http://www.openstreetmap.org/browse/changeset/18501942

Kann man das reverten und wer macht’s?

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.

Edbert (EvanE)

Danke für den Tip. Werde ich nachher mal prüfen, da hier vom “Smahtfohn” im Zug eher schwierig.

Ich habe mir mal ein Beispiel angeschaut. Zuerst war da der way http://www.openstreetmap.org/browse/way/39166142/history , welcher zuletzt mehrere Bearbeitungen im Minutenabstand verzeichnet.
Auf dem geschlossenen way liegen verschiedene Schnipsel, die gemeinsame Knoten mit dem genannten way haben. Zum Beispiel diese:
http://www.openstreetmap.org/browse/way/243207999
http://www.openstreetmap.org/browse/way/243208000
Der Schnipsel http://www.openstreetmap.org/browse/way/243238202 ist deckungsgleich mit einem Teil von way http://www.openstreetmap.org/browse/way/243165234
Alle drei Schnipsel haben keine tags und gehören zu keiner Relation.
Die Frage “Ist das Kunst oder kann das weg?” lässt sich für mich klar mit “kann weg” beantworten, auch wenn es eine (ungewollte) Kunst sein mag, so etwas zu produzieren. Kann das mit upload-Problemen zusammenhängen? ID war’s diesmal nicht. Da wurde mit JOSM/1.5 (6238 de) geschafft.

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…

Habe gerade gesehen, dass in Nürnberg bei der U1 zwischen Messe und Scharfreiterring Gleise fehlen. Hier ein Ausschnitt: http://www.openstreetmap.org/#map=18/49.41551/11.11596

Nach einer schnellen Recherche habe ich unter Anderem diesen Änderungssatz im Verdacht:
http://www.openstreetmap.org/browse/changeset/16409114

Es können aber duchaus auch noch Änderungen anderer Benutzer die Ursache sein.

Könnte das bitte mal jemand noch genauer überprüfen, den Benutzer informieren und das evtl. reverten? Danke!