Da sind wir uns ja ausnahmsweise mal in allen Punkte hundertprozentig übereinstimmend einig 
@ Mammi71 @ Streckenkundler
Ich hatte geschrieben:
Natürlich macht das Mehrfachtagging an dieser Stelle keinen Sinn, es ist aber gewiss nicht durch einen Fehler in iD entstanden, sondern durch die Absicht des Benutzters … und nur das wollte ich hier feststellen.
Yo, und dem schließe ich mich daher ebenfalls 100%ig an 
Nachsatz hinzugefügt
Das stimmt. So ähnlich habe ich das ja auch schon geschrieben, aber das wurde bisher eher ignoriert:
Die-Syntax-Problematik wie von seichter angesprochen kommt dann ebenfalls noch hinzu. Wir haben es hier also mit mehreren verschiedenen Problemen zu tun, die im Ergebnis sehr ähnlich aussehen und irgendwie blöd sind. Aber anstatt das auseinander zu halten und strukturiert anzugehen ist iD-Bashing halt einfacher.
Um es nochmals aufzuzählen:
Problem 1 von Jo Cassel gesehen und aufgeworfen: image:0=* und ff. Aufzählungen. Hierzu passt die Syntax-Erläuterung von seichter: schafft für die Auswerter kein neues tag (image bleibt immer gleich) sondern produziert eine Aufzählung (Nummerierung) des gleichen tags mit verschiedenen Werten, die nicht mit Semikola getrennt werden können (macht sich bei links zu verschiedenen Bilder sonst irgendwie doof). Nicht schön, aber das kleinere Übel. Lösungsmöglichkeit? Evtl. über wikidata oder irgendwas anderes (ist nicht so mein Spezialgebiet), wo man nur einen Verweis braucht, aber mehrere Bilder dauerhaft hinterlegen kann.
Problem 2: andere Tags mit :0 ff. als Aufzählung - ebenfalls kein neuer tag, daher nicht schön aber das kleinere Übel. Je nach Einzelfall kann man sehen, ob man solche Aufzählungen nicht doch mit einem tag und Semikola bei den Werten abbilden kann (z.B. mehrere Werte bei shop=*) oder ob es bereits anderweitig unterscheidbare tags gibt (phone=numer vs. contact:phone und contact:mobile)
Problem 3: Mappen verschiedener Objekte in einem OSM-Objekt (siehe Beispiel von Map_HeRo), das gilt für :0 ff. und _0 ff. gleichermaßen - vielleicht hats der Mapper nicht besser gewusst oder gekonnt - Behebung durch Getrennt-Mappen der einzelnen Objekte
Problem 4: Aufzählungen mit _0 ff. - diese tags mit Unterstrich sind tatsächlich problematisch, weil diese durch die Syntax ein neues tag schaffen, was für die Auswerter problematisch ist! Diese können entweder bewusst durch den Mapper gesetzt worden sein oder eventuell automatisch. Können jedoch meist wie Problem 2 oder 3 behoben werden. Muss man sich jedoch natürlich jeden Einzelfall ansehen.
Problem 4 a): zumindest eine Zeit lang scheinen diese Erweiterungen _0 ff. von iD automatisch gesetzt worden zu sein. Dies scheint aber behoben. Da hilft leider nur aufräumen. Sollten jüngere solche tags auftreten, ist dies vielleicht noch in einer persönlichen Vorlage (oder einfach im Kopf) des betreffenden Mappers so “abgespeichert” - dann muss man den Mapper persönlich anschreiben.
Problem 4 b): Bei MapComplete scheint es sowas auch zu geben oder gegeben zu haben. ich bin mir aber jetzt auch nicht sicher, ob es eventuell auch eine Erweiterung mit :0 ff. war und das image-Problem betraf (habe jetzt nicht noch einmal nachgesehen)
Problem 5: echte Dopplungen - gesehen von streckenkundler (und auch Map_HeRo und mir) wie z.B. roof:shape=gabled und roof:shape_1=gabled oder lit=no und lit_1=no. Das ist natürlich vollkommener Blödsinn! Eine Ursache konnte ich bisher nicht feststellen und nicht reproduzieren. Fehlerbehebung durch Löschung des tags mit Ziffererweiterung.
Edit: Ergänzung Problem 5 (ich wusste doch, dass ich noch was vergessen habe - danke Map_HeRo)
@ Mammi71
Messerscharfe Analyse … 
… ich bin beim weiteren Abklappern der “Fundstellen” hier in Hessen auf Problem 2, 3 und 4 (aber in allen Fällen ohne Zweifel mit Absicht gesetzt, also Aufzählungen oder mehrere Objekte in einem) gestoßen. An anderer Stelle eine ganze Serie vo 4a oder 4b, da gibt es zig mal die tags lit=no + lit_1=no, das sieht wirklich mehr nach Programmfehler als nach Absicht aus.
Ich denke, ich fang nachher an, die Fehler von hier ausgehend manuell abzuräumen, habe ohnehin jetzt erst mal genug Häusle gemappt. Wenn ich auf irgend etwas stoßen sollte, was problematisch ist, kann ich es ja hier posten. Oder will jemand das Problem vor Beseitigung erst noch weiter analysieren?
Danke für den hinweis, sowas hatte streckenkundler (und ich selber auch) auch schon gesehen, hatte es nur vergessen. Als eigenständiges Problem 5 ergänzt.
Vermutlich steckt da schon irgendwie Absicht (und kein iD-Unfall) dahinter.
Auffällig ist, dass der sehr aktive image:0-Mapper im CS immer auf die OpenPoiMap verlinkt.
Diese Karte ist aber scheinbar zu blöd, korrekte Verlinkungen auf die Commons-Bildbeschreibungsseite - mit Lizenzinformationen - zu einer Bildanzeige zu nutzen.
Dafür ist diese Karte aber dicke dabei “Zweitbilder” anzuzeigen, incl. Link auf die nichtvorhandene Dokumentation dazu, und auch Bilder mit gleichzeitigem Hinweis auf fehlende Lizenzinformationen (imho juristisch riskante Sache für den/die Kartenmacher)
Beispiel:
http://openpoimap.org/?map=various&zoom=19&lat=51.75997&lon=14.33841&layers=B00FFFFFFFFFFFFFTFFFFFF
(“Wilhelmsmuehle” [sic] anclicken, einen Permalink mit offenem Info-Fenster kann die Karte wohl nicht)
Warum das bei google.com gehostete image:0 hier nicht angezeigt wird, kann ich nicht sagen, das Problem dass tausende mapillary-Bilder nur noch OSM-Linkmüll sind ist ja bekannt.
wikimedia_commons=Category:[…] erlaubt die Einbindung einer unbeschränkten Bildersammlung, im Beispiel ist der Tag nicht gesetzt, obwohl es eine Commons-Kat zum OSM-Objekt gibt.
Die OpenPoiMap ist aber wohl nicht einmal in der Lage, den Commons-Tag dann auch clickbar umzusetzen - was inzwischen sogar die OSM-Homepage hinkriegt.
Kurzum, vermutlich fördert hier eine suboptimale Auswertung das suboptimale Taggen.
Ich kanns anklicken und erhalte ein hübsches Bilderchen
Ich nehme an, Du meinst das google-Bild?
Kaputt sind ja (z.Zt.) “nur” alle mapillary-Links, nach dortiger API-Änderung.
Sinn einer derartigen Map ist es aber doch wohl ein Bild anzuzeigen, statt den hinterlegten Link,
so wie hier bei einem anderen Bildhoster:
http://openpoimap.org/?map=various&zoom=19&lat=48.10513&lon=11.79932&layers=B00FFFFFFFFFFFFFTFFFFFF
Nein, Du hattest geschrieben:
Darauf habe ich mich bezogen und meine am Beispiel der Mühle:
http://commons.wikimedia.org/wiki/File:Cottbus_Wilhelmsmuehle_2014.JPG und das ist anklickbar
Das ist ein anderes Thema, war aber nicht das, was Du geschrieben hattest.
… meinte den Link auf die Commons-Kategorie
Ausführlich als (beliebige) Gegenüberstellung:
Eine gelungene Auswertung:
http://gk.historic.place/historische_objekte/l/de/index.html?zoom=19&lat=51.20472&lon=9.24233&pid=HaHbHcSaHe&select=n6960288135
- Bild auf Commons wird angezeigt - mit der in der Lizenz geforderten Autorennennung
- Der OSM Commons-Kategorie-Tag wird clickbar aufgelöst/angezeigt
- Permalink mit Infobox
Demgegenüber eine suboptimale Auswertung am identischen OSM-Objekt:
http://openpoimap.org/?map=various&zoom=19&lat=51.20451&lon=9.24193&layers=B00FFFFFFFFFFFFFTFFFFFF
- Bild auf Commons wird NICHT angezeigt - die anderer Hoster möglicherweise/vielleicht(?) schon
- Der OSM Commons-Kategorie-Tag wird NICHT clickbar aufgelöst/angezeigt
- Permalink mit Infobox geht wohl nicht
verständlich so? … daher mein Gedanke, dass eine derartig suboptimale Auswertung möglichweise dazu verleitet, mit image:0 ff. bildtechnisch “nachzuhelfen”.
Gruß
Jo
Ach so, Du meinst die ganze Commons-Kategorie. Jetzt wird es klarer.
Wie bereits geschrieben, istnicht mein Spezialgebiet. Aber vielleicht kannst Du das zuerst dem Seitenbetreiber und dann dem betreffenden user verklickern, wie es besser zu machen geht.
Dann hätten wir mal ein Problem angegangen.
Ich kenne Wegweiser-Richtungsangaben so, dass die verschiedenen Richtungsangaben mit ; getrennt hintereinander gemappt werden:
direction_south=Dingenskirchen 9km;Hintertupfingen 12km; Hauptstadt 34km
Ich habe gestern mal einen Teil dieser Mehrfachtags mit *_1 ff bearbeitet und es gibt eigentlich kaum echte Doppel. Das sind alles Einzelfälle, wo sich jemand was bei gedacht hat, auch wenn es nicht unbedingt den gängigen Taggingschemata entspricht. Z.B. 2 oder mehr unterschiedliche name, landuse, craft, shop, website etc. Fast alles lässt sich relativ einfach bereinigen, man darf aber davon ausgehen, dass das auch in Zukunft immer wieder passieren wird.
Was ist denn mit den echten/eindeutigen Fehlern, wie lit=no + lit_1=no und ähnliche? Kann man die mit einem Bot abräumen oder widerspricht das der “automatischen Massenedit”-Regel? Bundesweit gibt es ja wohl doch eine ganze Menge dieser Doubletten.
Als langjähriger iD-Verwender kenne ich keinen einzelnen Fall, indem der iD–Editor irgendwas mit beispiel:0=* angeboten hat.
In früheren Versionen gab es mal, dass - wenn man ein Attribut (ich nenne es mal “beispiel”) ein zweitesmal eintragen wollte - der iD-Editor dann was mit beispiel_1=… angeboten hat. Das ist mir in Fällen passiert, in denen ich ein Attribut hinzufügen wollte, dabei aber übersehen hatte, dass dieses Attribut schon mit einem Wert vorhanden war. Ich habe sowas dann immer entsprechend korrigiert, bevor ich gespeichert habe.
Wenn man zwei Objekte mit unterschiedlichen Werten bei einem bestimmten Attribut zusammengefügte hat iD aus beispiel=ersterWert und besipiel=zweiterWert beispiel=ersterWert;zweiter Wert gemacht. Inzwischen warnt aber der iD-Editor beim Zusammenfügen z.B. von zwei Straßenschnipseln mit unterschiedlichem surface, dass es unterschiedliche Werte gibt und verweigert das Zusammenfügen. Ich weiß allerdings nicht, ob das der iD-Editor grundsätzlich inzwischen so macht, oder nur bei Attributen, wo Doppelwerte keinen Sinn machen, wie z.B. bei Surface.
Ich stoße im Zuge der zunehmenden Beliebtheit von Themen-, Fernwander- und sonstigen Wegen auf Wegweiser mit bis zu fünf Richtungstafeln derselben Richtung mit jeweils drei Zielen pro Tafel.
Da wird es mit “;” ziemlich unübersichtlich und man überschreitet auch ziemlich schnell die zulässige Länge der Strings im Werte-Feld.
Bei simplem Nah-, Mittel- und Fernziel reichen die “;” natürlich und sollten auch so verwendet werden (KISS).
Darauf habe ich mich bezogen. Ein “:” war damals nicht im Angebot.