Frustrierende Löschwut

Ich beschreibe diesen Fall nicht, um jemanden an den Pranger zu stellen, sondern ein allgemeineres Problem anzusprechen: Löschwut in OSM. Ich bin nun mehrfach dem Problem begegnet, dass von mir eingetragene Informationen kommentarlos rückgängig gemacht wurden. Das ist sehr frustrierend und auch einfach unhöflich. Außerdem sorgt es dafür, dass ich mich nicht dagegen wehren kann, wenn ich nicht regelmäßig in die Chronik schaue.

Der aktuelle und bisher extremste Fall ist dieser hier:
https://www.openstreetmap.org/changeset/60324083#map=16/54.3285/10.1238

Damit ich es nicht doppelt schreiben muss, mein Kommentar dazu:

Eine Löschung von etlichen Informationen, viele davon gerade erst von mir eingetragen. Wofür mache ich mir überhaupt die ganze Arbeit? Kann man nicht erst einmal nachfragen? Warum wird das gelöscht? Ist es falsch? Überflüssig? Sowas macht mich echt wütend.

Muss ich das jetz alles händisch wieder neu eintragen? Oder kann man das reverten? Oder hat Omegatherion am Ende doch Recht und ich rege mich umsonst auf?

Bei den Wegen im Park ist bicycle=no tatsächlich überflüssig, da highway=footway das bereits impliziert.

Hallo,

Tagging-fachlich hat Omegatherion, wie SpaLeo schon schrieb, Recht. Gleichzeitig hat er aber auch Unrecht, denn bicycle=no transportiert auch eine Information, wenn es absichtlich verwendet worden ist und nicht nur gesetzt wurde, weil jemand eine Vorlage fleißig bis ins letzte Detail ausgefüllt hat. Es sagt nämlich aus, dass du vor Ort warst und festgestellt hast, dass auch kein Zusatzschild “Radfahrer frei” (d.h. mit Schrittgeschwindigkeit) angebracht ist.

Es ist dennoch kein guter Stil von ihm, einfach so anderer Leute Beiträge nach kurzer Zeit an die eigenen Vorstellungen zurechtzustutzen. Es wäre angemessen gewesen, dir einen Änderungssatzkommentar zu schreiben – spätestens dann, wenn er das nicht nur bei einem Änderungssatz von dir gemacht hat.

Dein Vorgehen, gleichzeitig einen Änderungssatzkommentar und einen Forenbeitrag zu schreiben, finde ich nicht so freundlich. Das erste, dann das zweite, wenn das erste nicht zielführend ist, wäre der freundlichere Weg.

Ich habe ihn per Änderungssatzkommentar gebeten, sich hier zu beteiligen.

Viele Grüße

Michael

Es geht Discostu36 nur um die bicycle=use_sidepath. Bei den Wegen im Park wurde der Tag vor einem Jahr von mir gesetzt.
Diesen Tag habe ich entfernt, weil es keinen Straßenbegleitenden Radweg und damit auch kein Fahrbahnbenutzungsverbot gibt. Es gibt einen parallel verlaufenden Radweg, dieser ist aber eigenständig.

Heißt das, wir düfen uns komplett von default-Werten verabschieden? Mit StreetComplete wird ja schon jeder öffentliche Parkplatz mit access=yes und fee=no getaggt. Nun muß also jeder überprüfte Fußweg vehicle=no und horse=no bekommen?

immer wieder das gleiche: Wie drückt man bei Openstreetmap aus, das **“weggelassen” eine bewusste Entscheidung **und nicht nur einfach **fehlende Daten **sind?

Datentechnisch machen die ganzen komischen “Selbstverständlichkeitstags” überhaupt keinen Sinn. Aber wie kann man die Information “dieser Weg wurde in Hinblick auf diesen Aspekt gemappt” denn sonst kodieren?

Ich selbst sehe sogar in der “Löschwut” einen Sinn: Fange ich an, “verdrehtrum” zu mappen ist ja auch die willkürliche Auswahl von Eigenschaften datentechnisch nicht sauber. Stelle ich die Implikationen einen Footways in Frage, müsste ich ja jetzt da alles (horse, motorvehicel, moped…) mit nein drankleben, damit die Daten “ordentlich” sind.

Das macht nur halt überhaupt keinen Sinn.

Dieser Meinung moechte ich mich nach meinem derzeitigen Wissenstand nicht anschliessen.

Mir waere es lieber, wenn man offensichtliche Defaultwerte nicht ausfuellt.

[Edit: Quote-Fix]

Sollte das “vor Ort” nicht Prinzip bei OSM sein?

highway=footway + traffic_sign=DE:239 ?

Oder ganz allgemein im note=*? Das ist doch eigens dafür da, dem nächsten vorbeikommenden Kollegen das Mapping zu begründen, sofern es sich nicht (was in der Regel der Fall sein sollte) von selbst erschließt.

–ks

Wir müssen sehen, dass jeder vor Ort Anderes als wichtig kartiert. Gerade aktive Fahrradfahrer neigen dazu, alles hierzu einzutragen. Ich habe schon ganze Stadtteile gesehen, die mit bicycle=yes und cycleway=no gemappt waren, irgendeiner mag da eine Aussage drin sehen, aber in D. ist das nun mal Standard. Und nur um auszudrücken, dass man vor Ort war und es wirklich kein Verbotsschild oder Radwege gibt, ist dann nicht wirklich ein Argument.

Wenn ich sowas sehe und es nicht falsch ist, lasse ich es meistens. Eine Löschung verbessert ja nichts, denn dann gelten die gleichen Werte implizit als Default, und man frustriert jemanden, wenn man es löscht.

Letztendlich müsst ihr aber euch wohl grundsätzlich damit abfinden, dass solche “impliziten” und “no” Werte über Apps (wie z.B. StreetComplete) immer öfters den Weg in die Datenbank finden … außer ihr tut etwas dagegen … aber solche Löschungen wie oben sind da definitiv der falsche Weg.

Ich denke das größte Problem das durch weglassen von Tags entsteht ist, dass man Default-Werte nicht von “unbekannt” unterscheiden kann. Das gilt dann auch besonders für Apps wie Street Complete, wodurch dann eine entsprechende Quest generiert wird.

Für Programmierer aller Anwendungen (auch Navis) macht ein vollständiges tagging die Sache einfacher, weil sie sich die Implementierung von lokalen “Eigenheiten”, sowohl gesetzlichen als auch der jeweiligen OSM Community nicht berücksichtigen müssen. Auf der anderen Seite füllt es die Datenbank (kleineres Problem da Speicher auch immer billiger wird) aber Änderungen von Gesetzen oder Communitymeinungen ein Riesenaufwand betrieben werden muss um nachzukorrigieren.

Lösung könnte sein, bei solchen Tags ein explizites “Default” oder “Implicit” als Wert zu setzen. Damit wäre man bei Änderungen immer noch flexibel und Apps würden den Status nicht als “unbekannt” interepretieren. Datenbanktechnisch ließe sich dies eventuell mit einem Kürzel beschreiben sodass nicht der komplette String “Default” gespeichert werden muss sondern vllt nur ein “@”.

Was sagt denn die örtliche Grünanlagensatzung (oder wo auch immer dieses Thema kodifiziert ist, kann auch eine allg. Polizeiverordnung o.ä. sein) dazu aus?
Hier in Karlsruhe wurde das vor paar Jahren geändert von

  • Radfahren auf Parkwegen grundsätzlich verboten, wenn nicht anders beschildert
    auf
  • Radfahren auf Parkwegen grundsätzlich mit Schrittgeschw. erlaubt, wenn nicht anders beschildert
    An der Beschilderung hat sich seitdem vor Ort selten was geändert …

Irgendwie scheint es aber unterschiedliche Auffassungen darüber zu geben, was Default ist und was extra angegeben werden muss. Ich wurde kürzlich kritisiert, dass ich bei Fußwegen nicht explizit angegeben habe bicycle=no. Und der iD, der ja Default-Werte bereits vorausfüllt, zeigt beim Anlegen eine Fußwegs “bicycle=Nicht angegeben” an, ein Hinweis darauf, dass laut der Macher des iD (immerhin des offiziellen Standarteditors) bicycle=no nicht als Default ansehen. Die Aufstellung hier: https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany sieht das aber wiederum anders.
Eine vergleichbare Diskussion hatte ich in Bezug auf die Default-Werte von Waldwegen (Highway=track) neulich hier angestoßen.

Woran machst du das fest?

Dann viel Spaß mit der russischen StVO, wenn du eine Karte von Russland erstellen möchtest…

Also, ja so kann man es dokumentieren und auch mit einem note=* geht es. Aber das wertet neben den Mappern beim Mappen keiner aus.

Allgemein denke ich, dass es sinnvoll ist, die Default-Werte zu erfassen. Jedenfalls sinnvoll genug, sie in der DB zu lassen, wenn sie von einem Mapper erfasst wurden. Setzt natürlich voraus, dass sie richtig erfasst sind. Es schadet ja nun nicht.

Was halt nicht geht, sind massenedits ala Suche alle Fußwege und füge man bicycle=no hinzu. Damit ist nichts gewonnen.

Hier https://www.mapillary.com/app/?pKey=QmUBwre2CvNRnOzZyzeKbQ&focus=photo&lat=54.3319013&lng=10.1243526&z=17 ist die nach rechts abbiegende Straße die Goethestraße. Ich seh kaum was, aber der Radweg an der rechten Seite der Goethestraße ist auf jeden Fall benutzungspflichtig.

Für die Default-Werte gibt es Access-Restrictions

Wobei der iD damit nur sagen will, dass das betreffende Tag an diesem Element nicht gesetzt ist. Ob Defaultwerte existieren, interessiert ihn dabei nicht. Um das klarzustellen könnte man statt „nicht angegeben“ evtl. „keine Besonderheiten“, „keine speziellen Angaben“ oder so was ausgeben, was nicht so klingt, als sei da noch eine Informationslücke, die unbedingt geschlossen werden muss.

–ks