Mit ID hinzugefügte Wikidata-Tags in Hamburg

Hallo,

in Hamburg entfernt ein Mapper (@sundew) regelmäßig, wenn er einen POI überprüft oder modifiziert, die daran angebrachten brand:wikidata oder operator:wikidata-Tags, aufgrund der Behauptung, dass diese ja unnötig seien (siehe z.B. Diskussion in Changeset: 141266553 | OpenStreetMap, an der auch einige der regelmäßigen Foristen teilgenommen haben).

Ich habe den Mapper bereits gebeten, das zu unterlassen (Changeset: 162273867 | OpenStreetMap).

Ich habe mal analysiert, wie viele *wiki*-Tags von diesem User in Hamburg gelöscht wurden; es sind 3.625. Bei genauerem Hinsehen sind die aber fast alle von solchen Mappern eingetragen worden, die großflächig mit ID “Probleme beheben”; allein rund 2.500 dieser 3.625 Tags stammen von einem einzigen Hamburger Mapper (@Wolfgang Holtz). Ich habe diesen Mapper in Changeset: 162057791 | OpenStreetMap gebeten, mit dem ID-“Rasenmäher” vorsichtig umzugehen.

Ich bin jetzt nicht sicher, ob ich diese 3.625 Wiki-Tags wiederherstellen soll oder nicht; im wesentlichen dürften das automatisch “durchgewunkene” ID-Vorschläge sein, die wenig Zusatznutzen bringen. Aber im großen und ganzen ist die deutsche Community ja mit diesen Tags zufrieden, und ihre Löschung allein aufgrund der Tatsache, dass sie von ID vorgeschlagen wurden, etwas übertrieben, oder?

Bye
Frederik

4 Likes

Das ist möglich. Wir kennen letztendlich aber nicht den Anteil, der bewusst hinzugefügt wurde.

Übrigens nicht nur in Hamburg. Hier z.B. ein Briefkasten, bei dem operator:wikidata und operator:wikipedia via JOSM hinzugefügt wurde. (Gleich der erste Briefkasten, den ich überprüft habe.)

Also persönlich setze ich operater:wikidata regelmäßig, ob Briefkästen, Recycling Container usw. Im Regelfall teilautomatisch nach Eingabe des Betreibers im iD Editor.
Wenn da nur halbwegs richtig lese sind falsch Eingaben kaum möglich.
Wenn die Daten jemand später wieder entfernt weil sie “ihn” stören wäre ich eher verärgert.

:+1: Ja

6 Likes

Hallo Frederik,

ganz ehrlich, bisher hatte ich dich immer als diplomatisch gelesen. Das was du jetzt schreibst, geht nicht in diese Richtung und motiviert mich nicht gerade, irgendwas anders zu machen, sorry. Adminmütze auf und draufhauen geht gar nicht :frowning:

Kurz zu mir: Ich bin kein lokaler Experte wie du schreibst, sondern jemand, der seit anderthalb Jahrzehnten sehr viel Zeit vor Ort draußen ist - bisher für OSM. Jeden Sonntag bin ich Winter wie Sommer bei Tag und bei Dunkelheit ganztägig in halb Norddeutschland mit dem Bike unterwegs, um flächendeckend in Städten und Dörfern bestimmte POIs regelmäßig zu prüfen bzw. Neues zu suchen und zu ergänzen. Da waren zum Teil vom Luftbild gezeichnete Dörfer dabei, wo scheinbar kaum ein Mapper vor mir war.
Dazu kommen noch viele kleine jährliche Überprüfungstouren hier in Hamburg und Umgebung…

Die angesprochenen Tags sind im OSM-Wiki bisher als optional gekennzeichnet. Sie bringen bei Massenobjekten keinerlei Mehrwert, sind in 99 Prozent wohl auch nur maschinell angespamt.
Solche Tags sind für Einzelobjekte (z.B. ein Denkmal) bestimmt, um deren Verbindung zu Wikiseiten herzustellen, nicht jedoch um irgendwelche Apps oder Datenprüfprogramme glücklich zu machen oder um Suchen auszuführen. Für Letzteres genügt Overpass.
Viel ist nicht unbebedingt mehr. Deshalb behalte ich mir vor, die angesprochenen Tags bei Vor-Ort-Überprüfung zu entfernen, vor allem auch, weil sie dem On-the-Ground-Prinzip widersprechen und ich sie manuell nicht verifizieren kann. In sehr vielen Fällen haben andere Mapper Veränderungen an weiteren Objekteigenschaften (z.B. Leerungszeiten) nie korrigiert, was ich immer wieder sehen muss.

Dass ich ab & zu in wenigen Fällen von schlimmen Datenvandalismus, also z.B. User zieht mit zwei weit entfernten Miniedits eine teils Quadratkilometer große Fläche auf, die dann eine der üblichen Apps ungeprüft automatisch umpatcht, dass ich also in solchen Fällen Teilreverts mache, versteht sich sicher von selbst.

Das alles habe ich schon anderswo geschrieben. Ich bin auch der Meinung, dass solche Forendiskussionen eigentlich verschwendete Zeit sind. Geht besser alle raus an und mappt vor Ort. Und trefft Euch mit Gleichgesinnten bei den monatlichen Mappertreffen. Die Diskussionen dort sind erheblich einvernehmlicher, statt in Foren große Töne zu werfen. Viele Meinungsverschiedenheiten haben wir dort entspannt gelöst und jeder war hinterher der Meinung, das Richtige zu tun.

Also was nun?

LG
sundew

2 Likes

Sorry, dann bitte aber auch bei Briefkästen den ref angeben, der vor Ort dran steht. Und nicht mal so und mal so argumentieren.

Schade, dass Du trotz mehrmaliger Bitten mehrere Beitragenden darauf beharrst, dass Deine Auffassung die einzig wahre ist. Ich verstehe nicht, was Dein Problem mit den Tags ist? Ignoriere sie doch bitte einfach.

1 Like

Eigentlich heißt das Grundprinzip ja “ground truth” und besagt, dass eine Überprüfbarkeit geben muss. Welcher operator zu einem Briefkasten gehört sehe ich vor Ort, welches operator:wikidata dazugehört kann jeder mapper ganz leicht mit wikidata überprüfen. Für mich ist da ground truth eindeutig gegeben. Wikidata ist ja nur ein Querverweis auf eine andere Datenbank.

7 Likes

Ich habe exakt dieses Problem auch schon vor einiger Zeit in meiner Gegend angemerkt, da ich es als sehr unfreundlich ansehe korrekte Tags zu löschen, nur weil man sie selber für unnötig hält. Sie werden ja nicht alle durch automatische ID Vorschläge da rein gekommen sein.

Ich setze auch selbst keine Wikidata-Tags, daher ignoriere ich sie halt, wenn sie da sind. Gerade für maschinelle Auswertungen bringen sie unter Umständen ja einen Vorteil. Wer diese oder ID nutzt, wird sie bei Bedarf hoffentlich auch anpassen.

6 Likes

Der Vorteil ist die Eindeutigkeit. Bei den Briefkästen gibt es als operator z.B: “Deutsche Post”, “Deutsche Post AG”, “Post” oder “Post AG”.

7 Likes

Hallo @sundew,
ich freue mich, dass du mit großem Eifer und Umfangreichen Vor-Ort-Kontrollen Daten zu OSM beiträgst. Bitte unterlasse aber das Löschen von korrekten Tags. Verlinkungen zu wikidata sind objektiv prüfbar. Und der von dir in Frage gestellte Mehrwert ist definitiv da. Natürlich kann man sich auch Regex-Abfragen für operator=* zusammenbasteln, da aber dann weder zu wenige noch zu viele Treffer zu verursachen ist nicht so einfach. Eine Abfrage nach operator:wikidata=* ist wesentlich einfacher und weniger fehleranfällig.
Wenn du operator:wikidata=* nicht magst, dann erfasse es nicht. Aber lösche diese Daten nicht, wenn sie nicht falsch sind.

Ich hoffe, dass du das nicht in den falschen Hals kriegst. Ich möchte dich nicht demotivieren oder dir vor den Kopf stoßen. Ich hoffe weiterhin auf deine Mitarbeit.

Ich bin gegen ein vollständiges revertieren der Änderungssätze. Ich befürworte ein Widerherstellen der wikidata-Tags.

7 Likes

Ich füge die gelöschten Wiki-Tags jetzt wieder hinzu.

8 Likes

Danke fürs wieder einfügen in Hamburg. Bekommt man das auch an den Objekten in der Umgebung hin, die das ebenfalls betrifft? @OSM_RogerWilco und ich haben das ja auch in einiger Entfernung von Hamburg beobachtet (bis in den Heidekreis bzw. Raum Bremen).

Ich sehe auch gerade dass da auch ein Haufen POIs geändert wurden, die zuletzt von sundew revertet wurden, z.B. Changeset: 136151917 | OpenStreetMap. D sind jetzt zwar die wikidata tags wieder dran, aber die entsprechenden operator oder network tags fehlen natürlich weiterhin. Da hatte auch jemand mit ID die entsprechenden wikidata tags eingefügt.

Hallo OSM_RogerWilco!
Ich muss jetzt mal fragen, was dieser Nebenschauplatz soll. Wir hatten das schon mehrfach freundlich diskutiert, wenn du die drei/vier Postkästen in der Allerregion meinst, wo die Briefkastenschilder offensichtlich reihum vertauscht und/oder strikt vergessen unaktuell waren. Ich hatte das korrigiert und dort entsprechende note=Tags hinterlassen. Oder was hättest du getan? Aber ich glaube, darum geht es jetzt überhaupt nicht, sondern darum, meine Argumente sinnfrei auszuhebeln. Genauso wie die Sache mit den Operatorschreibweisen, die ja mittlerweile praktisch alle angeglichen sind.

Hallo OS-emmer,
danke für die freundlichen Worte. Eine Abfrage nach wiki-Einträgen ist keinesfalls einfacher, weil genauso fehleranfällig mit den nicht-sprechenden Buchstaben-Zahlen-Folgen. Ich erwarte von OSM, dass man auch ohne Apps & co damit praktisch arbeiten kann.

Hallo mgerken,
wir hatten auch das diskutiert. Aber wie immer in OSM, wenn man etliche verschiedene Möglichkeiten des Taggings hat, wird es zwischen Mappern unterschiedliche Auffassungen geben. Und jeder Mapper, der viel macht, wird irgendwann in Konflikt mit anderen geraten. Das kann man ausdiskutieren, aber falsch ist das nicht.

Im Übrigen finde ich es erschreckend, wie tot das Forum inzwischen ist. Hier bestimmen jetzt wenige Leute, was aus ihrer Sicht Sache sei. Vor einem Jahrzehnt konnte man jeden Tag eine Stunde darin lesen, auch wenn der Umgangston da auch nicht immer freundlich war.

LG
sundew

Naja, wenn Du Dich hier auf das OTG-Prinzip berufst, dann fällt mir halt schon auf, dass Du das mal so und mal so argumentierst. Ich habe nämlich bei den Briefkästen im Heidekreis auf OTG verwiesen und würde da gerne als ref das erfassen, was vor Ort dran steht. Da hast Du aber argumentiert, dass hier OTG nicht relevant sei, weil Du aus anderer (hoffentlich zulässiger) Quelle weißt, dass die falsch sind.

Allgemein finde ich Dein Auftreten hier eher arrogant als kooperativ.

1 Like

Hallo sundew,

Deine Arbeit in OSM achte ich sehr. Du hast viel dazu beigetragen, dass OSM in Deiner Region tatsächlich die Realität widerspiegelt und nicht veralteter oder wiedergekäuter Schrott ist. OSM lebt vom Einsatz von Leuten wie Dir. Allerdings kommt es gerade bei Leuten wie Dir immer mal wieder dazu, dass sie denken “das hier ist alles meins, und ich bestimme, wie es läuft”. Und da fangen dann die Probleme an. Natürlich wollen wir nicht, dass einer aus Neuseeland jetzt plötzlich in Hamburg Murks vom Luftbild abmalt, den die lokalen Mapper dreimal besser wissen. Aber wenn die Community insgesamt den wikidata-Tags gegenüber positiv eingestellt ist und andere Mapper diese hinzufügen, dann steht es Dir nicht zu, die einfach so zu löschen. Die verfälschen ja nichts vor Ort - ein Wikidata-Tag an einem Briefkasten ist nichts, was Du mit vor-Ort-Wissen übertrumpfen kannst (“ich war da und auf dem Briefkasten stand gar kein Wikidata!!!”). Beim konkreten Verlauf eines Weges oder bei der Frage, ob der Briefkasten auf der linken oder rechten Straßenseite steht, hast Du als lokaler Mapper das letzte Wort - nicht aber beim Wikidata-Tag. Das musst Du einsehen. Der Briefkasten “gehört” Dir nicht, auch wenn Du - was, wie gesagt, super ist - zweimal im Jahr prüfst, ob er noch dasteht.

Was das Forum anbetrifft - hier wäre der Platz, ein Thema wie “Wikidata-Tags finde ich doof, ich lösche sie, wenn ich sie sehe” zu diskutieren. Wenn Du das nicht willst, ist das auch ok, aber ohne einen Community-Konsens kannst Du so eine Löschaktion auch nicht durchdrücken - dann heisst es “leben und leben lassen”, auch für die Wikidata-Tags.

Es ist ein schmaler Grat, das ist mir klar. Erst neulich gab es hier im Forum eine ganz umgekehrte Diskussion, da hatte jemand vor Ort Tags zu Denkmälern hinzugefügt, die er sich selber ausgedacht hatte, und die Community war darüber etwas unglücklich und hätte sich eine vorherige Diskussion gewünscht. Hier war also der Mapper für Zusatztags und die Community kritisch. Auch dieser Mapper hatte sich vor Ort auf Mappertreffen mit anderen abgestimmt, und im Grunde ist das ja wünschenswert und es soll ja auch Freiheiten geben in OSM, mal was auszuprobieren und so weiter.

Im Fall der Wikidata-Tags ist es aber völlig albern, wenn einer in Hamburg gegen die Windmühlen kämpft, wenn doch qua ID-Editor diese Tags eh ständig wieder hineinkommen. Da müssen wir entweder als Community entscheiden, dass die Tags unsinnig sind und wir sie nicht wollen, und dann auch beim ID-Editor diese Änderung durchkriegen, oder wir finden die Tags gut und unterstützen das. Aber dass irgendwo in Hamburg einer Wikidata-Tags löscht, weil er sie persönlich irgendwie unnötig findet, das hat doch keinen Sinn.

Dass ein Tag im Wiki als optional gekennzeichnet ist, ist kein Grund für seine Löschung (am Ende löscht jemand sämtliche Höchstgeschwindigkeiten an Straßen mit dem gleichen Grund).

Ich verstehe, dass Dein erster Impuls ist, auf die Angelegenheit mit Trotz zu reagieren (“behalte ich mir vor, die angesprochenen Tags bei Vor-Ort-Überprüfung zu entfernen”). Das ist nur menschlich. Dennoch bitte ich Dich, darüber nachzudenken, ob Du vielleicht einen Kompromiss finden kannst und Tags nur dann löschen, wenn Du sie negativ prüfen kannst (d.h. “ist definitiv falsch”), anstatt eine positive Prüfung (“ist definitiv richtig”) anzulegen. Bedenke, wie viele andere Tags Du an verschiedensten Objekten stehen lässt, ohne sie positiv zu prüfen! Es wäre schade, wenn so eine Bagatell-Auseinandersetzung am Ende dazu führt, dass ein ausgezeichneter Mapper die Lust an OSM verliert.

@mgerken, ich bin nach folgender Logik vorgegangen: “Finde alle Tags in Hamburg, in deren Key “wiki” vorkommt, die von sundew entfernt wurden und die nicht in der Zwischenzeit wieder angebracht wurden, und stelle sie wieder her”. Ich kann diese Logik auch auf umliegende Gebiete und/oder andere Tags anwenden, wenn das gewünscht ist.

11 Likes

Das wäre sehr nett. :slightly_smiling_face:

@Frederik,
danke für die diesmal freundlich einladenden Worte.

Mit deinen Reverts hast du jetzt leider genau das zementiert, was die ID-Massenspammer Jahre vorher ohne jegliche Vor-Ort-Prüfung erreichen wollten. Sehr schade.

Bitte sei so nett und sag mir, wie ich JOSM diese Tags in der Property-Liste ausblenden kann, so wie das scheinbar ja auch dür uralte source=JOSM (oder so ähnlich) bei Wegenodes einstellbar ist.

@OSM_RogerWilco,
dass die Quellen (schon wieder ein Nebenschauplatz?) die ebenso vertauschten Nachbarortsbriefkästen waren, hatte ich dir damals bereits erklärt, warum zerrst du das jetzt hervor? Aber egal.

Arrogant? Nunja, wenn man von allen - nur weil unterschiedlicher Auffassung - zu Unrecht in den Hintern getreten wird, muss man sich wehren.
Bisher habe ich hier nur zwei freundlich vermittelnde Antwort gelesen.

@Mammi71
es heißt “On-the-Ground” und nicht “Ground-Truth”, letzteres wurde wohl von einigen hinzugedichtet. Wenn ich einen Ententeich in einem privaten Garten habe, der nur(!) im Luftbild sichtbar ist, sollte ich den im Normalfall auch nicht erfassen, auch wenn der in Wirklichkeit auf dem Boden ist. Zumindest war das in der Vergangenheit Konsens.

LG
sundew

So, ich bin mit der Wiederherstellung der von @sundew entfernten wiki*, operator und brand-Tags in Hamburg, Niedersachsen und Schleswig-Holstein jetzt durch, ich musste da 1-2x nachbessern, aber jetzt dürfte es passen. Sieht noch jemand ein Problem?

3 Likes

Ich habe ein paar Nodes ausgemacht an denen manuelle Nacharbeit notwendig ist, aber das sieht schon sehr gut aus.

Es sieht so aus als hättest du die operator auch wieder mit eingefügt, allerdings nicht die network tags, korrekt? Es gibt jetzt sehr viele Bushaltestellen mit network:wikidata aber ohne network / network:short. Bevor ich da jetzt manuell irgendwas mache, warte ich lieber noch mal, ob du die bei den angefassten nodes auch wieder einfügen kannst.

Ich habe außerdem auf die schnelle mindestens einen Node gefunden, wo jemand in der Zwischenzeit einen anderen Operator gesetzt hatte, der jetzt überschrieben wurde.

In Illinois gibt es dieses amenity=restaurant mit name=Burger King. Der (bei OSM nicht erfasste) Betreiber heißt laut wikipedia “Burger King LLC of Illinois”. Dieser Burger King hat nichts mit der großen glechnamigen Kette zu tun.

Wenn ich jetzt alle Restaurants der “großen” Burger-King Kette finden will, könnte ich nach folgenden Kriterien suchen:
(amenity=restaurant oder amenity=fast_food) und brand:wikidata=Q177054.

Ohne wiki* wird es schwierig, den ganz oben genannten Burger King nicht aus versehen mit zu finden. Für diesen konkreten Fall kannst du jetzt mit Sicherheit mit Regex eine Abfrage erstellen, die an Hand von irgend einem Kriterium den unabhängigen Burger King ausfiltert. Wenn du von dessen existenz aber nichts gewusst hättest, wärst du dann auf die Idee gekommen, hier irgendwas auszugrenzen?

Eindeutige, kryptische Zahlen-Buchstaben-Codes wie die wikidata IDs haben auch ihre Vorteile. Ob dir das gefällt oder nicht, es ist so. Und es mag ja auch sein, dass du für deine Anwendung (wie auch immer die aussehen mag) keine wiki* tags benötigst. Das ist vollkommen ok. Wenn Regex-Abfragen basierend auf operator=* oder ähnliches für dich funktionieren, dann ist das doch super. Anderen kann es aber anders gehen. Und diesen anderen zerschießt du mit deinem Verhalten die Anwendung.

Wie bereits gesagt, du muss keine Tags erfassen. Wenn du keine Lust hast, die wiki*-tags zu ermitteln und einzupflegen, dann lass es einfach. Aber wenn sich jemand anders die Arbeit macht, den Verweis zu wikidata herzustellen, dann zerstöre diese Arbeit nicht.

4 Likes