Qualitätssicherung

OT:

Geschätzt 100 gehen davon auf mein Konto.

1. Es gibt Couchmapper, die anhand veralteter Luftbilder zusammen mit angeblich gemeinfreien Karten fantasievoll längst zugewachsene Wege in die Brandenburger Landschaft malen. Ein beeindruckendes Beispiel ist die Döberitzer Heide - selbst als das Kerngelände noch “offen” war, gab es dort geschätzt nicht einmal die Hälfte der eingetragenen Wege, schon gar nicht als tracks). Und diese Couchmapper malen dann, wenn ich so einen Sauhaufen bereinigt habe, die Wege wieder rein, vermulich in der Annahme “hat wohl irgendein Vandale gelöscht”. Deswegen lasse ich die Ways jetzt stehen, mache highway=no und klemm noch ein note dran. Btw.: Kontakt mit dem Mapper hat kein Einsehen zur Folge gehabt, DWG rät bloß zum Beobachten…

2. Manchmal erkennen einige Couchmapper auf Luftbildern etwas falsch. Mir ist zum Beispiel ein angeblicher straßenbegleitender cycleway am Waldrand untergekommen, der auf dem Luftbild echt so aussah, aber in Wirklichkeit ein Brandschutzstreifen war. Mit highway=no +note kommt hoffentlich keiner mehr auf die Idee, einen neuen Versuch zu unternehmen.

Wäre es da nicht besser, diesen mit landuse/natrural=haumichblau zu taggen + Dein note.
highway=no ist Unsinn, IMO.

Theoretisch ja, praktisch ist mir die Zeit zu schade.

Aber unschädlich, für Renderer wie Router.

Für diesem Fall ist das lifecycle prefix vorgesehen, also z.B. abandoned:highway=path. Zur Sicherheit noch mit entsprechender note.
Siehe auch http://wiki.openstreetmap.org/wiki/DE:Lifecycle_prefix

Dafür reicht an der betreffenden Linie eine aussagekräftige note aus. Bitte nicht den highway-tag dafür missbrauchen. Evtl. magst du deine Edits entsprechend anpassen, sonst macht das noch Schule

Danke,
geow

Zähneknirsch

Im Rahmen dieses “Qualitätsoffensivethreads” bearbeite ich gerade Fehler und Straßenattribute. Zumindest alle Straßen im Ortskern über die ich mehr als 10 Mal geradelt bin kenne ich ja aus dem Kopf…

Diese Straße ist so kurz sie sein mag falsch. Ich versuche sie in Wiedenhof umzubenennen.

• Lösen aus der Relation:associatedStreet Williburgstraße
• Ändern des Namen der Straße
• Hinzufügen zur Relation:associatedStreet Wiedenhof

→ JOSM Fehlerprüfung: "Warnungen(2): Rolle to fehlt - Problem bei der Rollenprüfung
Zugeordnete Straße (“Williburgstraße”)
Zugeordnete Straße (“Wiedenhof”)

Was habe ich denn da wieder falsch verstanden / gemacht?

Ich finde es besser die Häuser mit der tatsächlichen Adresse zu versehen und die Relation zu entfernen. Zumal die Straßen in den Adressen schon an den Gebäuden vorhanden sind, verstehe ich nicht die Straßenzuordnung mittels Relation. Ist m.E einfacher und Fehler unanfälliger (siehe selbst) - eventuell den Eingang (entrance=main) des Gebäudes zur Navigation setzen - z.B. Williburgstraße 15 wäre nur über Wiedenhof erreichbar.

Bei wie vielen Prozent der Privatgebäude ist denn ein Eingang eingezeichnet? In NRW dürften dies, spätestens seit dem NRW-Atlas-Chaos, nur noch eine geringe Prozentzahl sein.

Die “Bedenken” gegen diese Art Relation habe ich schon gelesen, bin da was das angeht ganz bei dir und habe überlegt wenn ich mal selber was “neues” erfasse diese gar nicht erst anzulegen. Die Häuser / Adressen die ich bisher angelegt / korrigiert habe haben von mir auch alle den vollen Satz Adress Tags verpasst bekommen. Da diese Relationen im Ort aber nicht von mir angelegt wurden, dachte ich es ginge so “mininalinvasiv” wie bei den letzten Adresskorrekturen, da gab es nämlich diese Fehlermeldung nicht. Fremde Relationen zu löschen kam mir daher erst mal so nicht in den Sinn.

Das Aufarbeiten des Orts birgt offensichtlich noch jede Menge Stolperfallen denen ich noch nicht gewachsen bin…

Davon mal abgesehen wäre es für den Lernfortschritt wichtig wenn jemand diesen Fehler genauer erklären könnte und wie man den behandelt. Lösche ich die Relationen müsste ich wohl für alle Objekte die ich nicht angefasst habe vorher prüfen ob die den vollen Satz Adress Tags schon haben - für die beiden kleinen Straßen kein Riesending, für größere Straßen die jemand so angelegt hat eher schon.

Ich habe mir mal eine Reihe Kandidaten angesehen, das waren alles mMn Fehltaggings, z.T. mit tunnel=culvert drunter.
Eine Brücke ist ein eigenständiges Bauwerk, das den Verlauf der Straße oder des Weges unterbricht, ohne layer>=1 sind sie mir sehr verdächtig.
Z.B. die Zufahrt vom Feldweg zu einem Acker über ein Betonrohr und etwas Erde als Brücke zu bezeichnen, halte ich für etwas übertrieben.
culvert kommt im Wiki weder bei den Werten für bridge=* noch bei denen für bridge:structure vor.

“Unzulässig” ist vielleicht ein unzutreffendes Wort, da in OSM ja (fast) alles erlaubt ist, “discouraged” (bitte nicht) trifft es eher.

(Kurz erklärt:

• den way umbennen

• die Relation williburgstraße aufrufen und den way dort löschen (das Teilstück)

• falls du weiter mit den relationen arbeiten willst:

• relation Wiedenhof aufrufen und dort den way einfügen)

Ich würde die relation prüfen → sind alle building und street erfasst? → ja → relation löschen
Oder kurz den Mapper anschreiben - und auf Relation:associatedStreet verweisen.

Genau dabei trat die Fehlermeldung auf. Die übrigens aber auch mehrfach erscheint, wenn man ohne Auswahl manuell auf prüfen klickt und andere Relationen geprüft werden. Umso wichtiger wäre es zu wissen warum der Fehler bemängelt wird.

Genau so habe ich es gemacht nachdem ich alle Häuser einzeln angesehen habe. Vielen Dank!

Deiner Meinung schließe ich mich gerne an

Ich habe mal versucht nachzuvollziehen, woher im Wiki die Dokumentation bridge=culvert kommt.

Die Seite Tag:tunnel=culvert wurde am 29. August 2010, 16:23 Uhr angelegt. Die Begründung verweißt auf eine Diskussion auf der Mailingliste wenige Tage zuvor.

Soweit ich erkennen kann, ist der Hintergrund der Diskussion, die Seite Key:culvert (culvert=yes) zu Tag:tunnel=culvert zu ändern.

Aus der Diskussion ergibt sich aber auch, dass es für bridge=culvert Stimmen dafür und dagegen gibt. Eine Einigung gab es für bridge=culvert nicht. Lediglich die Änderung von Key:culvert zu Tag:tunnel=culvert fand Zustimmung.

Dennoch wurde die neue Wikiseite für Tag:tunnel=culvert mit verweis auf bridge=culvert erstellt und dies wurde bis heute nicht geändert.

Hab ich was übersehen?

Das Tagging bridge=culvert kommt also tatsächlich im Wiki vor, ob mit Einigung sei mal außen vor.
Die englische Version “the culvert structure is directly reused as a bridge” wäre so etwas wie ein blankes Rohr, über das man drüberholpert. Ich würde das nicht Brücke nennen, aber es mag Grenzfälle geben.
Die deutsche Version dagegen (“bei größeren Wasserläufen”) ist mMn Unfug, danach wäre jede Brücke über ein Gewässer ein “culvert”, denn sie lässt ja immer das Gewässer unten durch.

Was ich aber bisher gesehen habe, waren entweder eindeutig Brücken oder eindeutig Durchlässe.

Korrekt, ich habe heute auch einige bridge=culvert gesichtet und habe diese mehrheitlich zu tunnel=culvert geändert. Wobei auch viele Fälle dabei waren, wo der Wasserweg bereits als tunnel=culvert gemappt war und der Weg darüber zusätzlich als bridge=culvert.
In diesen Fällen wurde die Brücke ausgebaut

Ich finde, sie werden viel zu viel angewandt. Ich würde mir mehr Mapper wünschen und weniger Datenpolizisten. Die meisten dieser vermeintlichen Korrekturen sind in Wahrheit Verschlimmbesserungen. Und fast immer läuft das ohne Absprache mit den ursprünglichen Mappern, die die eigentliche Arbeit gemacht haben.

Wenn es der eigene Ort ist oder zumindest einer, wo man schon war, ok. Das Tückische an diesen Tools ist, dass man sich dann auch den Nachbarort anschaut usw., und manche Leute werden davon so süchtig, dass sie dann in ganz Mitteleuropa herumkorrigiereren ohne irgendeine Ahnung zu haben von dem, was sie tun.

Also das sehe ich zumindest mit Blick auf den Umkreis den ich überschauen kann eher wie geri-oc. Wenn die Karte voller Fehlersymbole ist, sollte sich das ändern.

Was meinst Du mit Verschlimmbesserungen? Und (warum) sollte man jede Ergänzung Korrektur mit dem ursprünglichen Mapper absprechen? Für mich als Anfänger wäre das schon sehr wichtig, wenn Du das näher erklären würdest.

Zum einen war der Aufruf so zu verstehen, dass sich jeder seinen Ort ansehen soll. Zum Anderen wird jeder seinen Ort individuell auslegen müssen. Ich kann jedenfalls nichtmals in ganz Dortmund alles mappen / korrigieren, weil der Ort einfach zu groß ist. Und ich war schon in Ecken, die der gemeine Dortmunder niemals kennen lernen wird
Darüber hinaus gibt es aber auch Fehler, für die braucht es keine Ortskenntnis. Ich hoffe sehr, dass keiner hinter mir her meine Anfängerfehler ausbügeln muss. Aber es gibt Fehler, die es massenhaft gibt und die man durchaus auch ohne Ortskenntnis reparieren kann, kreuzende unverbundene Linien etc. kann ich auch in Castrop-Rauxel fixen.

Aber ganz grundsätzlich bin ich in einem Punkt ganz bei dir: Aktuelle Ortskenntnis ist wohl durch nichts zu ersetzen.

ich bin hier ganz bei meinen Vorrednern: bitte nur das korrigieren, was aus eigener Kenntnis (d.h. man ist kürzlich vor Ort gewesen) verbessert werden kann, und wo man sich sicher ist, was der Fehler ist. Tippfehler in tags zu korrigieren ist wichtig, aber tags die einem unüblich vorkommen zu “verbessern” ist oft problematisch, und sollte man m.E. erst nach Rücksprache mit dem Mapper tun. Nur weil die Tools derzeit ein bestimmtes tag nicht kennen heisst das noch lange nicht, dass das tag “falsch” ist. Luftbilder sind darüberhinaus grundsätzlich alt, livebilder gibt es derzeit AFAIK nirgendwo für OSM benutzbar. Scheinbar redundante tags zu entfernen ist eine weitere Sünde, die oft im Rahmen von solchen “Aufräumaktionen” begangen wird.

Also wenn es so aussieht als hätte vor Jahren jemand so ein Vektornachmaldingsbums auf die örtlichen Kirchen losgelassen und Zwischen- und Nebengebäude, Gemeindehaus, Kindergärten vergessen, dann frage ich nicht nach, sondern korrigiere falls nötig die Gebäude und beschrifte von Grund auf neu, als wenn ich es selber angelegt hätte. Inkl. Öffnungszeiten des Gemeindebüros. Und wenn jemand vergessen hat Linien zu verbinden mache ich das mal eben.

Bitte aber nicht rein sklavisch nach NRW-Atlas. Der ist auch an manchen Stellen nicht OTG-kompatibel. Mindestens nach Luftbild, besser noch nach vor-Ort-begehung.

Manche gemeldeten Fehler sind keine Fehler. Beispielsweise die “touching inner rings” in OSMI. Man müsste den Validator ändern und nicht die Daten. Die Prüfung auf “duplicate tags on inner ring” ist eine nützliche Funktion, aber auch hier sind die Tags manchmal doch richtig (z.B. barrier=wall oder source:geometry=*). Viele Validatorbenutzer (und dazu gehören anscheinend auch die JOSM-Benutzer) sind sich dessen nicht bewusst, sie möchten die Karte sauber bekommen, wie in einem Computerspiel, wo Pacman alle Pillen fressen muss. Schockierender als die Rücksichtslosigkeit, die hier an den Tag gelegt wird, ist eigentlich das blinde Vertrauen, das selbst erfahrene User wie geri-oc, die es eigentlich besser wissen müssten, in die Software haben. Mir fällt dazu Napoleons Zitat ein, dass es kein leichtgläubigeres Volk als die Deutschen gibt.

Vorbildlich finde ich den in Keepright umgesetzte Funktion, “false positives” zu markieren. Leider wird sie viel zu wenig genutzt.

Eben z.B. dass durch “Korrektur” von touching inner rings sich die Anzahl der Ways und Relationen in einem Gebiet verfielfacht. Oder das hier schon angeschnittene Thema, dass Brücken eingezeichnet werden, die gar nicht existieren. Das macht die Daten nicht nur falscher als vorher, sondern auch die Fehler schwerer erkennbar. An manchen Stellen muss man sich weit übers Geländer beugen oder sogar durchs Gestrüpp um zu erkennen, ob es sich um ein Rohr, eine Brücke oder eine Kombination von beidem handelt. Das macht keiner, wenn eh schon eine Brücke eingezeichnet ist.

Lästig ist es auch, wenn “alte” Tags (z.B. type=* auf Bäumen oder power=sub_station wie gerade im anderen Thread besprochen) auf neue geändert werden und dabei Information verloren geht. Oder auch umgekehrt, wenn neue Tags, die der Validator noch nicht kennt, auf ähnliche Tags geändert werden, wie z.B. vor ein paar Jahren barrier=swing_gate auf barrier=lift_gate.

Weiters gibt es Leute, die den ganzen Tag nur Routing-Fixes machen und dabei je nach Lust und Laune Wege zusammenhängen oder noexit=yes setzen. Die Wahrscheinlichkeit, dass so eine Änderung stimmt, ist nicht mal 50%, denn es gibt in der Realität Fälle, wo der Weg aufhört und man trotzdem weitergehen kann.

Erstens weil der ursprüngliche Mapper vielleicht einen guten Grund gehabt hat um es so zu mappen. Wenn das aber nicht der Fall ist, dann kommen wir zu zweitens, dass der Mapper es in Zukunft richtig macht. Einen Mapper zu überzeugen kann mehr Wirkung haben als tausend Datenfehler zu beheben.