Mapperkollege revertiert wiederholt korrekte Fehlerbeseitigung

Am 06.06.2021 habe ich eine schwer beschädigte Buslinie überarbeitet. Vor dem Hochladen habe ich direkt im JOSM-Editor den Button „Prüfung“ angeklickt. Es kam dann die Meldung:

„Fehlendes Merkmal - shelter_type ohne amenity=shelter …“

Deshalb habe ich den Tag shelter_type gem. JOSM und Wiki gelöscht. In dem Zusammenhang habe ich auch festgestellt, dass an einigen Bus-Plattformen das falsche „waste_basket=yes“ statt dem gem. Wiki richtigen „bin=yes“ gesetzt war. Dies habe ich dann ebenfalls geändert.
Kollege P. wollte daraufhin, dass ich den Tag „shelter_type=public_transport“ wieder hinzufüge, siehe:
https://www.openstreetmap.org/changeset/105922648#map=14/48.8042/9.0506
Ich habe ihn dann darauf hingewiesen, dass statt waste_basket an der Bus-Plattform das „bin“ zu verwenden ist und shelter_type=public_transport ohne den Tag amenity=shelter nicht verwendet werden darf. Darauf hat er nicht geantwortet, weshalb ich davon ausging, dass er das im Wiki nachgeprüft hat und nun mit den Änderungen einverstanden ist.

Nachdem sich im Juli 2021 einige vom ZOB Bietigheim ausgehende Nachtbuslinien geändert haben, musste ich diese überarbeiten. Beim Prüfen der Linien im JOSM erhielt ich dann wieder die Warnung auf das fehlende Merkmal shelter_type ohne amenity=shelter.

Da Kollege P. auf meine Antwort vom 06.06.2021 bis zum 13.07.2021 nicht geantwortet hat, ging ich weiterhin davon aus, dass er mit meinen Änderungen einverstanden ist. Deshalb habe ich auch die overpass-turbo-Abfragen mit den entsprechenden Tags durchgeführt und im Kreis Ludwigsburg am 13.07.2021 die Fehler berichtigt. An 14 Bus-Plattformen habe ich das falsche „waste_basket=yes“ gem. Wiki auf „bin=yes“ geändert, an 5 Stellen das vom JOSM-Editor als Fehler angemahnte „shelter_type=public_transport“ entfernt, sowie zwei weitere durch JOSM angemahnte Fehler in unmittelbarer Nähe der Bushaltestellen korrigiert (Gebäude ohne Straßennamen und Fehler bei einem Überweg), siehe
https://www.openstreetmap.org/changeset/107893654
Vor einigen Tagen habe ich nun festgestellt, dass Kollege P. bereits wenige Stunden nach dem Hochladen meines Änderungssatzes ohne Kontaktaufnahme mit mir gleich einen Revert durchführt hat, siehe
https://www.openstreetmap.org/changeset/107920685

Einen Revert durchzuführen, ohne vorher mit dem Kollegen Kontakt aufzunehmen, finde ich als absolut unangebracht. Dies sieht wohl auch das Wiki so:
https://wiki.openstreetmap.org/wiki/DE:JOSM/Plugins/Reverter
Unter der Überschrift „Achtung“ steht nämlich:
„Setze keine Änderungen von anderen Nutzern zurück, ohne sie vorher höflich zu kontaktieren und ihnen genügend Zeit für eine Antwort zu geben (mindestens eine Woche). Fehlerhafte Daten können problemlos behoben werden, aber eine zerbrochene Gemeinschaft ist nicht so leicht wieder herzustellen.

Lass dich nicht dazu verleiten, einfach mal Änderungen zurückzusetzen, nur um mögliche Bearbeitungs-Konflikte mit anderen Nutzer zu umgehen! Besprich im Zweifelsfall die Dinge auf der Mailingliste, bevor du loslegst.“

Durch Missachtung dieser Verhaltensregeln besteht m.E. auch die Gefahr, andere Mapper aus OSM rauszuekeln. Bei mir hat es jedenfalls schon zu 90 % gewirkt. Ich habe mich zu einer Auszeit beim Mappen auf unbestimmte Zeit entschlossen. Es erscheint mir sinnlos zu sein, von mir als Fehler erkannte Tags auf bundesweit einheitlich verwendete und gem. Wiki richtige Tags zu korrigieren, wenn dann ein anderer Mapper rücksichtslos ohne vorherige Kontaktaufnahme meinen Änderungssatz revertiert.

Ich habe nun im Wiki erneut nachgesehen. Für wichtig halte ich u.a. folgende Seiten:

https://wiki.openstreetmap.org/wiki/DE:%C3%96ffentlicher_Verkehr

https://wiki.openstreetmap.org/wiki/DE:Key:shelter
Unter „Ähnliche Tags“:
amenity=shelter - eine eigenständige Schutzhütte

https://wiki.openstreetmap.org/wiki/DE:Key:shelter_type
Erster Satz:
Der Schlüssel shelter_type=* beschreibt den Verwendungszweck von Objekten, die mit amenity=shelter erfasst wurden.

„shelter_type“ wird also nur bei Objekten verwendet, die mit „amenity=shelter“ erfasst wurden und dieses „amenity=shelter“ ist für eine eigenständige Schutzhütte vorgesehen, aber nicht für eine Bus-Plattform und wird deshalb vom JOSM-Editor zurecht dort beanstandet.

https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dwaste_basket
Zweitletzte Überschrift:
Verwandte Tags (letzter Punkt)
• bin=yes: Mülleimer als Teil eines Objekts z.B. Bushaltestelle

https://wiki.openstreetmap.org/wiki/DE:Key:bin
Letzter Absatz:
Siehe auch
amenity=waste_basket (separat gemappter Mülleimer auf einzelnen Node)

Auf den zuvor angeführten Seiten habe ich mehrmals das „amenity=waste_basket“ (für einen separat aufgestellten Mülleimer) gefunden, aber nirgends das „waste_basket=yes“.

Nun habe ich nachgesehen, wie dies deutschlandweit getaggt wird und ob dies nur ein Stuttgarter Problem ist, verursacht insbesondere durch einen bestimmten Mapper. Dazu habe ich drei overpass-turbo-Abfragen erstellt
http://overpass-turbo.eu/
und dort im Wizard im Eingabefeld als Suchbegriff eingegeben:

public_transport=platform and waste_basket=yes
bzw.
public_transport=platform and bin=yes
bzw.
public_transport=platform and shelter_type=public_transport

Danach habe ich einzelne Bereiche überprüft (jeweils nicht zu große Bereiche, sonst kommt eine Fehlermeldung). Diese Bereiche waren die 4 Millionenstädte der BRD, etliche weitere Großstädte bundesweit, sowie in BW die Städte HN, MA, KA, FR, UL.

Das nicht korrekte waste_basket=yes habe ich bis auf einzelne Ausnahmen nirgends gefunden, in Stuttgart aber flächendeckend.
Das korrekte bin=yes habe ich überall flächendeckend gefunden (Anzahl mal mehr, mal weniger), selbst in Stuttgart. Hier besteht also ein Mischmasch zwischen waste_basket=yes und bin=yes.
Das falsche shelter_type=public_transport habe ich bis auf einzelne Ausnahmen nirgends gefunden, in Stuttgart aber flächendeckend.

Es ist also ein rein Stuttgarter Problem. Kollege P. führt als Begründung für seinen unberechtigten Revert an:
„es waren sachlich zutreffende Attribute erfasst. Deren Löschung ist ein inakzeptabler Informationsverlust.“

Dies ist schlichtweg falsch und entspricht absolut nicht der Realität. Durch die nach wie vor vorhandenen Tags „highway=bus_stop“ bzw. „public_transport=platform“ ist dokumentiert, dass sich der shelter an einer Bushaltestelle befindet. So kann durch die Entfernung des gem. JOSM-Editors falschen Tags keine Information verloren gehen. Und durch die Berichtigung des Mülleimers vom gem. Wiki falschen „waste_basket=yes“ auf das gem. Wiki richtige und bundesweit bis auf Stuttgart einheitlich verwendeten „bin=yes“ ist dieser weiterhin vorhanden. Er würde dann sogar bei einer entsprechenden Recherche miterfasst.

Da ich nun nicht mehr weiterwusste, habe ich meine Erkenntnisse einem erfahrenen und besonnenen Mapperkollegen mitgeteilt und auch dass ich das Verhalten des Kollegen P. als unverschämt empfinde und ich unter solchen Voraussetzungen keinen Sinn mehr am Mappen sehe. Er hat dann den ihm persönlich bekannten Kollegen P. informiert, dass ich mit seinem Verhalten nicht einverstanden bin. Trotzdem (oder gerade deshalb?) hat dieser direkt am nächsten Tag den weiteren von mir am 11.07.2021 erstellten Änderungssatz:
https://www.openstreetmap.org/changeset/107775248
mit der Begründung revertiert: „Das waren nachweislich zutreffende Informationen, die hier gelöscht wurden.“, siehe:
https://www.openstreetmap.org/changeset/108669451#map=14/48.9595/9.1074
Das spricht für sich. Einen Tag, nachdem er erfuhr, dass ich mit seinem Verhalten nicht einverstanden bin, ohne Kontaktaufnahme gleich den nächsten Revert durchzuführen, nur damit seine Taggingfehler weiterhin Bestand in der Datenbank haben. Ob er noch weitere Änderungssätze von mir revertiert hat, habe ich nicht nachgeprüft.

Meine Fragen sind nun:

1. Wenn bundesweit das gem. Wiki richtige „bin=yes“ für einen Mülleimer an einer Bus-Plattform verwendet wird, ist es dann korrekt, wenn in Stuttgart aber das „waste_basket=yes“ eingesetzt wird, obwohl das laut Wiki nur für einen separat aufgestellten Mülleimer vorgesehen ist?
2. Wenn bundesweit an einer Bus-Plattform gem. Wiki das „shelter_type=public_transport“ nicht gesetzt wird, ist es dann korrekt, wenn in Stuttgart aber entgegen dem Wiki und unter Missachtung der Fehlermeldung des JOSM-Editors flächendeckend dieser Tag verwendet wird?
3. Ist es inzwischen in OSM üblich, dass man die für eine funktionierende Gemeinschaft erforderlichen Verhaltensregeln missachtet und Änderungen eines Mappers rigoros revertiert, nur weil er anderer Meinung ist?

Sollte eine oder mehrere der vorliegenden Fragen mit „nein“ beantwortet werden, erhebt sich für mich die nächste Frage:

Wie bringt man einem uneinsichtigen Mapper bei, sich an das bundesweit einheitliche und dem Wiki entsprechende Tagging sowie die erforderlichen Verhaltensregeln zu halten und wer ist dazu überhaupt in der Lage, dies insbesondere dann, wenn einem Mapper evtl. das nötige Einsichtsvermögen in ein möglicherweise eigenes Fehlverhalten abhandengekommen ist?

ghostrider44

der Hinweis „shelter_type“ ohne amenity=shelter ist nur ein Hinweis, deswegen einen tag zu löschen halte ich auch nicht für angebracht, zumal der tag hier irgendwie zuzutreffen scheint. Den Josm-Validator muss man im Zweifel lieber ignorieren bevor man tags löscht wo man sich nicht ganz sicher ist.

Ob waste_basket oder bin besser ist für einen Mülleimer entscheidet das Wiki wohl für „bin“, und das ist auch nach Nutzungen vorn, aber waste basket hat auch bereits schon 12000 Nutzungen, ist also wohl kein Tippfehler, da gibt es zum Löschen keinen Anlass (man kann bin auch ergänzen ohne waste_basket zu löschen). Ehrlich gesagt finde ich waste basket in gewisser Hinsicht besser, da eindeutiger, „bin=yes“ könnte auch z.B. binär heißen, andererseits würde ich wohl bin bevorzugen da viel öfter verwendet. Ich habe im Wiki nirgendwo den Hinweis gefunden, dass man waste_basket als key löschen soll, oder dass man bin „stattdessen“ verwenden soll, grundsätzlich gilt in OpenStreetMap „Alle tags die man will.“ any tag you like

Zur Frage nach „bundesweiten“ Entscheidungen, diese sollte man wenn es irgend geht vermeiden. Wir entscheiden am liebsten weltweit, oder ggf. lokal, d.h. am besten sprechen wir uns global ab, wie wir Unterstände und Mülleimer als Eigenschaften taggen wollen. Wenn jedes Land da eigene Regeln aufstellen würde hätten wir bald hundert Varianten die alle mehr oder weniger dasselbe ausdrücken wollen

Hmpf, ja, dieses shelter_type ohne amenity=shelter ist wirklich irgendwie was bissl Blödes.

Ist mir auch schon untergekommen.

Das Problem ist halt dieses:
Wie gibt man weitere Details zu einem Objekt an, das nur indirekt getaggt ist? Wie in dem Fall, der shelter über shelter=yes aber nicht über amenity=shelter.

Ich habe z. B. auch schon seats=* an Bushaltestellen gesehen, um die Anzahl der Sitzplätze der dortigen Bank anzugeben.
Nur die Bank war da dann eben auch mit bench=yes und nicht mir amenity=bench getaggt.

Man kann es so und so sehen…

Ich finde, ein shelter_type kann durchaus auch an einen shelter, der nicht eigenständig als amenity=shelter erfasst ist, sondern nur als shelter=yes an eine Haltestelle getaggt ist. Der zitierte Satz aus dem Wiki soll wahrscheinlich besagen, dass shelter_type nicht an ganz andere Objekte wie amenity=bench oder building=shed getaggt werden soll. Den würde ich nicht auf die Goldwaage legen.

Mmh

• shelter_type=public_transport (bei shelter=yes an einem “public_transport-Ding”) ist irgendwo zwischen Redundanz und Datenmüll
• die Anzahl der Sitzplätze dort ist demgegenüber eine Zusatzinformation

an shelter=yes Objekten kann der shelter_type ggf. Sinn machen, bei einer Bushaltestelle ist public transport sicherlich redundant, einen „Fehler“ würde ich es nicht nennen.
In keinem Fall ein Fehler kann „waste_basket“ als Schlüssel sein, weil der tag bisher nicht dokumentiert ist, von daher kann man ihn auch nicht „falsch“ anwenden.

Update: Es gibt doch schon Doku, und die besagt dass der tag dieselbe Bedeutung hat wie bin, von daher ist er hier richtig angewendet gewesen

Du bist wahrscheinlich Jurist?

Da “hier ist ein Mülleimer dran” laut Wiki als “bin=yes” zu taggen ist, würde ich alle anderen Versuche durchaus als “nicht im Sinne des Erfinders” betrachten, ohne dass jeder davon extra im Wiki stehen und als falsch erkennbar sein müsste.

Der Witz ist ja, dass “bin=yes” genau dieses eine Beispiel ist, das nicht dem Mantra “A=B kann unter Umständen auch als B=yes getaggt werden” folgt. Weil ein Mülleimer ist ja amenity=waste_basket. Wie das zustande kam - keine Ahnung, ist an dieser Stelle wsl. auch nicht so wichtig, passiert halt. Wsl. auch (doch) nicht das einzige Beispiel…

Nur Manche meinen nun, das irgendwie “rückgängig” oder “besser” oder “passender” machen zu können, indem sie das aus ihrer (oder aus logischer?) Sicht “eigentlich richtige” dann anwenden, also waste_basket=yes. Nur wieder andere meinen dann, das hat doch keinen Sinn. bin=yes hat so und so viele Verwendungen, und das kann man allerhöchstens mit einer “großen Absprache” ändern. Und wieder andere sagen dann, “das bringt doch nix, weil es keinen Mehrwert hat. Es schiebt nur eins zum anderen ohne sonst irgendetwas zu ändern. Lassen wir es doch einfach so, wie es ist”.

Und so geht es hin und her…

Möchte mich da jetzt gar nicht auf eine Seite stellen. Ich weiß ja auch nicht, was besser ist. Ist nur eine ungefähre Beschreibung der Situation.

Ja, ist bescheuert aka unlogisch, “schwer vermittelbar” etc., aber letztendlich sind das nur keys+values in einer relationalen Datenbank.
Entscheidend ist imho, dass wir uns auf eine gemeinsame Dokumentation einigen und danach agieren (und da sehe ich hier “bin”)

Vieles ist unlogisch. Zum Beispiel building=yes als Haupttag, das von seiner struktur her eher ein Subtag zu man_made=building ist.

Bezüglich waste_basked=* oder bin=* bei Bushaltestellen, ist mir aktuell auch aufgefallen, dass bei der Verwendung von StreetComplete bin=* für die Bushaltestellen verwendet wird, waste_basket=* von StreetComplete jedoch komplett ignoriert wird. Dadurch habe ich bereits einige Bushaltestellen entsprechend mit StreetComplete getaggt und die Haltestellen hatten danach dann natürlich beide Tags (also bin=* und waste_basket=*). Dies wurde ebenfalls vom selben Mapperkollegen zurück gesetzt.
Hier habe ich ihn dazu kurz angeschrieben: https://www.openstreetmap.org/changeset/108667751

Persönlich fände ich es ebenfalls sinnvoll ein einheitliches Tagging dafür zu verwenden, auch wenn ich seinen Punkt auch gut verstehen kann.

Wieso sollte, angesichts der Dokumentation, ein Auswerter/Datennutzer auch auf diese Idee kommen.
Wenn P. dazu im CS schreibt “… das muss man nicht dringend doppelt haben.” so zeugt das von Unverständnis der grundsätzlichen Problematik.

Eine Information, die nicht entsprechend der Dokumentation, sondern stattdessen z.B. nach “Stuttgarter Gutsherrenmeinung” getaggt ist, ist für normale Nutzer unzugänglich.
Nutzbar ist diese nur für den Gutsherren - aber auch nur in Stuttgart.

Mülleimer als Bestandteil von ÖPNV Infrastruktur kenne ich auch nur als bin=yes, welches mit 136478 Nutzungen auch klar vor waste_basket=yes mit 7425 Nutzungen liegt. Es wäre schön, wenn man sich hier einigen könnte und nicht regionale Sonderwege geht. OSM ist bekanntermaßen nicht frei von Inkonsistenzen, aber man muss es auch nicht mit Absicht noch komplizierter machen, in dem man Tags pusht, nur damit es der eigenen Logik entspricht. Sehe ich es richtig, dass die Wikiseite zu waste_basket=yes (https://wiki.openstreetmap.org/w/index.php?title=Key:waste_basket&redirect=no) erst 2019 geschrieben wurde?

+1

Ehrlich gesagt, verstehe ich die ganze Diskussion hier nicht Haben wir keine anderen Probleme als Mülleimer an Bushaltestellen?

Der Eingangspost liest sich wie eine Klageschrift vor Gericht; mit den entsprechenden Verweisen zu den Gesetzestexten. Dafür hätte ich maxhimal Verständnis, wenn es da um einen grundsätzlichen Streit zu den PTV-Schemas gehen würde. Aber in der Richtung gibt es ja seit Jahren keine Bewegung. Wie die Diskussion hier zeigt, gibt es in OSM mehrere Wege zum Ziel und keiner ist wirklich richtig oder falsch. Das ist es ja gerade, was den Reiz an diesem Projekt ausmacht.

Das finde ich löblich. Mann kann in dieser Auszeit runterkommen und das ganze evtl. auch nochmal aus einem anderen Blickwinkel betrachten.

Wie lange bleibt OSM noch nutzbar, wenn jeder seinen eigenen Stil durchzieht?

@ghostrider44: Du hast recht, dass die Begründung für den Revert unzutreffend ist. Generell können solche Konflikte schon den Spaß am Mappen trüben. Wenn einige lokale Mapper aber halt Wert auf diese unüblichen Tags legen, würde ich an deiner Stelle (auch zur Schonung deiner eigenen Nerven) vielleicht die Standard-Tags nur ergänzen, aber deren spezielle Lieblingstags trotzdem zusätzlich am Objekt belassen. Das ist nicht ideal, aber ein redundantes Tag macht ja erst mal nicht viel kaputt. Und wenn dadurch allen Beteiligten die Lust am Mappen erhalten bleibt, wäre mir das wichtiger.

Naja, für mich zumindest ist das allfällige Taggingchaos bestenfalls ein notwendiges Übel. Ich fände es doch schön, wenn von unseren Daten auch tatsächlich jemand einen praktischen Nutzen hat, und dafür braucht es eine gewisse Einheitlichkeit. Und trotz einer vorhersagbaren beim Eintragen eines Mülleimers als Attribut einer Bushaltestelle gibt es sehr wohl einen Weg, der “richtiger” ist als die Alternativen, nämlich bin=yes. Wäre es besser, wenn der Schlüssel anders hieße? Vielleicht, aber das kann man über Proposals besser durchsetzen als über Editwars.

Kann man so sehen, ist aber doch auch gescheitert vgl. #11

Ja, (genau genommen wurde ein bestehender Redirect erweitert) aber quasi zeitgleich auch in “bin” die synonym-Vorlage eingebaut:
https://wiki.openstreetmap.org/w/index.php?title=Key%3Abin&type=revision&diff=1872786&oldid=1803959

Spricht etwas dagegen, diese Vorlage auch in die DE-Version von “bin” zu übernehmen?
(die übliche DE-Zwischenüberschrift ist afaik “Mögliche Tagging Fehler”)

+1

Editwars gibt es insbesondere, wenn man die Alternativen löscht. Dieses „alles Löschen was man nicht kennt oder anders mappen will“ sorgt für böses Blut und verhindert zum Teil auch, dass sich neue Taggingschemata entwickeln ohne Proposal. Solange unterschiedliche keys genutzt werden gibt es technisch keinen Zwang zum Löschen.

Ich persönlich werde immer etwas hellhörig, wenn jemand mehrmals betont, das bestimmte Tags “bundesweit einheitlich und dem Wiki entsprechend” sind. Das sind die gleichen Worte, wie man sie von “Gärtnern” hört, die OSM auf der Suche nach Unkraut durchstreifen, das sie jäten können

Und da spielen dann halt auch oft persönliche Befindlichkeiten mit hinein. Der eine “gärtnert”, ohne sich Gedanken zu machen, dass sein “ich passe Deine Tags hier mal an das an, was bundesweit einheitlich und dem Wiki entsprechend ist” bei einem entsprechend aufgestellten Gegenüber ankommt als “Du Depp bist schon 5 Jahre länger dabei als ich und trotzdem muss ich Dir hinterherputzen”. Das Gegenüber ist jetzt in der Defensive und sucht sich irgendeine Regel, mit der es den Gärtner zurückweisen kann (wenn gar nichts anderes geht, dann “hab ich schon immer so gemacht gab nie Beschwerden”). Nun ist der Gärtner der, der sich verteidigen muss… etc. etc. ad infinitum. Beide sind gekränkt, das Ego verlangt Genugtuung, am Ende stampft einer beleidigt mit dem Fuß auf und verlässt OSM.

Wir müssen schon aufpassen, dass wir uns keine Provinzfürsten heranzüchten, die meinen, sie können bei sich alles selber bestimmen. Aber zugleich muss man auch mal fünfe gerade sein lassen und zu einem achselzuckenden “Du hast Recht und ich meine Ruh” bereit sein.

Ich bin in solchen Fällen eher dafür, beides einzutragen. So, wie es Tordanik in #16 vorschlägt. Parallel kann man gerne über Proposal und Forumsdiskussionen versuchen, sich mittelfristig auf eine Version zu einigen.

Bei Wegweisern trage ich - weil es in der Hinsicht auch zwei “Lehrmeinungen” gibt, sowohl “bicycle=yes” als auch “guidepost=bicycle” ein, wenn es sich um einen Radwegweiser handelt. Beides meint das Gleiche. Es tut nicht weh, dass dadurch an vielen Wegweisern nun beides steht.