Hallo,
mir sind imho sinnfreie “Ergänzung”, erst vor 2 Tagen, mit diesem Key in einem von mir intensiv bearbeiteten Gebiet aufgefallen (image per wikimedia UND Commons Kategorie war vorhanden, inzwischen dort revertiert).
Das scheint mir aber kein Einzelfall:
http://overpass-turbo.eu/s/1eHM
Ist sowas ganz normal bei iD?
https://www.openstreetmap.org/way/741245778
Anscheinend ja :(… meine Abfrage zu dem Thema für Brandenburg:
https://overpass-turbo.eu/s/1eHN
Sven
… … Ach du Schei… was ein Elend 
Das doch wohl ein nicht gelungener Scherz…
Nein, das ist keinn Scherz… leider… 
ausgeheckt hatte ich mit die Abfrage mal im Zusammenhang mit dem THW… aber dann mal auf alles erweitert… Bei der Abfrage ist TMC und alles mit fuel* auskommentiert… Mit diesen beiden würde es sicher noch mehr sein…
Bei Dingen wie https://www.openstreetmap.org/way/666904079 weiß ich daß es iD war… den User kenne ich seit Jahren persönlich und freiwillig macht er das zu 100% sicher nicht…! Dinge wie https://www.openstreetmap.org/node/3803682626/history war auch iD… vgl. Historie…
Sven
irgendeine Idee, wie iD das machen soll? In den Gegenden wo ich bisher intensiv gemappt habe, finde ich sowas entweder gar nicht oder zumindest nicht von mir. Bei einigen Tausend CS mit iD hätte ich aber schon erwartet, dass es auch mir mal passiert wäre. Also doch eher ein user-Problem? Allenfalls eine fehlende oder ignorierte Warnung?
https://www.openstreetmap.org/way/55955050 → auch http://openpoimap.org/?map=various&zoom=16&lat=51.58959&lon=14.74714&layers=B00FFFFFFFFFFFFFTFFFFFF
Kann es sein, das er die Quelle meint (Mapillary-Bilder) die eventuell mit dem gpx-track zusammen hängen. Eventuell eine Ebene gpx oder Mapillary mit den Daten vereint?
Am besten wird er selbst Auskunft geben können. Wenn du ihn gut kennst, vielleicht mal anschreiben.
Gesundes 2022 wünscht Gerd
Ich habe mir anhand der Abfrage von Jo Cassel einige image:x angesehen. Die CS beschränken sich nicht ausschließlich auf iD, sondern betrifft auch MapComplete.
Auffällig ebenfalls: in der Hauptsache betrifft es den user km2bp. Alle anderen user sind eher user mit ganz wenigen CS.
In der Summe sehe ich das also weiterhin eher als ein Anwender-Problem. Ich kann das auch nicht in iD reproduzieren, zumindest nicht, dass iD das automatisch machen würde. iD schlägt da auch nichts vor bei der Eingabe. Ich bekomme das nur hin, wenn ich das :0,:1 usw. explizit manuell eintrage.
nö, schau dir mal das Ergebnis genau an… es betrifft nicht nur image_= sondern vieles andere auch…
etwas wie: roof:shape=gabled + roof:shape_1=gabled macht man nicht bewußt, kann ich mit nicht vorstellen…
Sven
@streckenkundler: es sind offensichtlich verschiedene Fehler!
lt. Abfrage von Jo Cassel: image**:=
bei Deiner Abfrage: [tag]_**=
In manchen Fällen handelt es sich um eine reine Dopplung (wie in Deinem Beispiel roof:shape), in anderen Fällen ist es eine Aufzählung mehrerer Attribute zu einem Tag (z.B. Angabe mehrerer Telefonnummern, verschiedene Arten von Shops an einem Poi …)
Und nochmals: ein programmtechnischer Fehler lässt sich in iD im Moment nicht reproduzieren. Selbst wenn ich manuell, von Hand, also mit voller Absicht zweimal roof:shape=gabled eintrage, akzeptiert dies iD nicht und löscht spätestens beim Hochladen den zweiten Eintrag. Es kommen auch keine automatischen Vorschläge in dieser Richtung.
Möglicherweise ein Problem, das mittlerweile gefixt ist? Ich habe bei meinen Stichproben bisher auch keine halbwegs aktuellen Änderungen gefunden, war alles mind. 2 Jahre her.
Und was ist mit MapComplete?
Jedenfalls kann ich in iD im Moment ein [tag]_[Ziffer]=* oder [tag]:[Ziffer]=* nur erzeugen, indem ich dies explizit (!) so eintrage.
Ich habe jetzt mal die Query über Hessen laufen lassen.
geladen – Nodes: 3547, Ways: 316, Relations: 4
angezeigt – POIs: 208, Linien: 198, Polygone: 120
Ich habe jetzt auf die schnelle mir einig Nodes angesehen. Alle Änderungen wo im TAG ein “_” auftaucht, sind alle vor 2019 von den unterschiedlichsten Usern mit iD durchgeführt. Die höchste iD-Version ist momentan 2.8.2.
image ist bei mir noch nicht aufgetauscht.
OK, das Ganze hat weder mit einer alten iD Version, noch mit irgend einem früheren Jahr zu tun.
Ich bin jetzt auf einen Änderung gestoßen, die vom 25.12.21 in der Version 2.20.2 entstanden ist.
https://www.openstreetmap.org/edit?editor=id&way=727117147#map=19/50.54023/8.40423
Jein.
Es gab mal eine iD-Version, die ziemlich große “Freude” mit name_1 bis name_xx u.ä. verursacht hat und was nur zögerlich vom Maintainer geändert wurde.
Vor allem die Auswerter protestierten heftig, weil sie dadurch ständig neue Hauptschlüssel vorgesetzt bekamen.
Das wurde halt nicht generell beseitigt und geistert als “Vorlage” für manuelle Edits immer noch durch die (Mapping-)Welt.
Bei meinen Sichtungen sah es eher so aus, dass die abc_1 etc willentlich vom Mapper so eingetragen wurden, da es keine Doppelungen waren, sondern eher nähere Beschreibungen des abc waren. Und das wird man auch nicht in den Griff bekommen, da “Jeder machen kann, was er will”.
Und ich muss zu zugeben, in der Zeit von 2010 bis 2020 hatte ich auch keine Ahnung, dass dieser Satz nur eingeschränkt gilt. Ich habe gemappt, was der Editor zuließ. Und ich denke, dass das bei den meisten Gelegenheitsmappern so ist.
Das ist egal, meiner Ansicht nach sollten und müssen Tags dieser Form immer vermieden werden! Ich betrachte das stets als Fehler…
Sven
Da ist ein feiner, aber bedeutender Unterschied:
1 ist ein neuer Schlüssel, :1 ist es nicht.
Das ist im Syntax begründet, da "" Teil eines Schlüsselnamens sein kann, “:” aber nicht.
Für den Auswerter ist das ein großer Unterschied.
:n kommt dann vor, wenn man mehrere Werte zu hat, die man nicht vernünftig per “;” hintereinander hängen kann.
Beispiel sind mehrere Richtungsangaben auf Wegweisern, die alle in die selbe Richtung zeigen.
Ansonsten bräuchte man mehrere Wegweiser-Nodes an der selben Stelle oder eine Wegweiser-Relation.
Da scheint mir der “:” das kleinere Übel.
Egal wie: ich bin der Meinung, man käme vom Regen in die Traufe… wenn man sowohl hinter “_” als auch hinter “:” rein numerische Werte anwendet… Darum geht es mir…
Sven
+1
Hier in der Umgebung gibt es einige wenige dieser Objekte, wo die numerischen Keys ohne Zweifel mit Absicht angelegt wurden, und zwar genau aus dem o.g. Grund, allerdings mit “_” statt “:” , z.B. wurde ein großer Löschwasserteich mit Saugstelle so gataggt:
emergency=fire_hydrant
emergency_1=suction_point
emergency_2=fire_water_pond
Auch wenn das jetzt nicht unbedingt Sinn macht, ist die Absicht unverkennbar. An den anderen Stellen ist es ähnlich. Ich denke, das lässt sich hier relativ leicht bereinigen, aber grundsätzlich macht das m.E. in bestimmten Fällen schon Sinn, es sei denn, jemand hat eine deutlich bessere Idee.
Hier ist m.E. schon ein inhaltlicher Fehler:
Ein Hydrant ist kein Feuerlöschteich, das kann man m.E. nicht in einem Objekt vereinigen.
Ein Feuerlöschteich sollte eine Fläche sein, eine Löschwasserentnahmestelle nur ein Punkt am Rad dieses Feuerlöschteiches. Das geht auch nicht zusammen.
Ein Hydrant ist eine technische Einrichtung, an die ein Feuerlöschschlauch mit definierten (genormten) Anschlüssen angeschlossen werden kann. An einer Löschwasserentnahmestelle (an einem Gewässer) wird der Schlauch zum Ansaugen mehr oder weniger direkt ins Gewässer gehängt (mal etwas salopp ausgedrückt). Also auch zwei verschiedene Objekte.
Man kann es bereinigen, wenn man drei Objekte draus macht.
Also für mich ist das widersprüchlich… entweder ist es ein echter Hydrant, oder nur eine Saugstelle. Beides geht nicht.
Ein Löschwasserteich (=flächige Ausdehnung) kann eine Saugstelle (Punkt) haben, muß aber nicht. Alles drei an einem Punkt geht eigenlich nicht…
Sven