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

Das sieht mir auch nach einem Mapping-Unfall aus:
http://www.openstreetmap.org/browse/changeset/18371644
Outer way eines Multipolygons gelöscht, Wald gerodet.

In Kandel wurde eine Kreuzung getrennt und dadurch eine Strasse abgeschnitten.

waterway=*, layer=-1 and not tunnel ist eigentlich immer verdächtig, besonders wenn es mehr als ein kurzer Abschnitt in Städten ist. Spezialisten haben es innerhalb eines Jahres geschafft alle Italienischen Flüsse unter die Erde zu leiten und vor kurzem wieder rauszubuddeln, vielleicht die Wetterkapriolen heuer?

In der Umgebung von Lenggries sind auch alle waterways unterirdisch verlegt?

So etwas müsste doch mit einem QA transparent zu machen sein. :confused:
Wenn ich auf so etwas stoße, baue ich es um. Dann muss ich aber auch ggf. kreuzende Wege checken, ob da bridge und layer fehlen.

Bin noch etwas neu hier, wo/was ist QA? Ich habe in beiden mir untergekommenen Fällen die betreffenden User kontaktiert, in Italien ist es schnell repariert worden, bei Lenggries will ich dem User noch ein wenig Zeit zum Nachdenken lassen.

Kreuzende Wege usw gibt es Haufenweise, man glaubt gar nicht wieviele Warnungen vom Validator kommen wenn man den felherhaften layer=-1 tag entfernt.

Es ist (leider) eine weit verbreitete Praxis, Flüsse und vor allem Bäche in ganzer Länge mit layer=-1 zu versehen, damit man sich die Arbeiten mit Brücken und Durchlässen spart und beim Hochladen nicht z.B. vom JOSM-Validator angemeckert wird.
Wer den layer rausnimmt, darf sich auf etwas Nacharbeit gefasst machen. Um die Änderungsgebiete im Rahmen zu halten, kann es ratsam sein, den Gewässerlauf zu splitten, am besten an Durchlässen, wo man wegen layer-Wechsel sowieso aufspalten muss.
[Edit:] QA heißt Quality Assurance, also Tools wie der JOSM-Validator, der OSM-Inspektor (OSMI), KeepRight und viele mehr.

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