Ich würde auch sagen, das Code, der sich verhält wie geplant, trotzdem ein Bug sein kann.
Und mit ID etwas einzugeben, was kein A… nutzt (/nutzen kann), ist doch wohl ein Bug, oder ?
Christoph
Das denke ich auch.
Full ACK!
Sarkasmus Eine Warnung im iD? Wo gibts denn sowas? 
/Sarkasmus
Deine Idee (“name” überschreiben, wenn nochmal der Key “name” eingetippt wird) halte ich für wirklich gut.
Im Idealfall würde man direkt über dem Feld mit der Fehleingabe so ein kleines Popup setzen, das sinngemäß “Jeder Tag kann nur einmal pro Objekt vergeben werden; bitte erzeuge für jedes reale Objekt ein OSM-Objekt” sagt. Aber das ist schwierig kurz und prägnant zu formulieren, so das es ein newbie versteht.
Doch gibt es:
iD.validate = function(changes, graph) {
var warnings = [];
// https://github.com/openstreetmap/josm/blob/mirror/src/org/
// openstreetmap/josm/data/validation/tests/UnclosedWays.java#L80
function tagSuggestsArea(change) {
if (_.isEmpty(change.tags)) return false;
var tags = change.tags;
var presence = ['landuse', 'amenities', 'tourism', 'shop'];
for (var i = 0; i < presence.length; i++) {
if (tags[presence[i]] !== undefined) {
return presence[i] + '=' + tags[presence[i]];
}
}
if (tags.building && tags.building === 'yes') return 'building=yes';
}
if (changes.deleted.length > 100) {
warnings.push({
message: t('validations.many_deletions', { n: changes.deleted.length })
});
}
for (var i = 0; i < changes.created.length; i++) {
var change = changes.created[i],
geometry = change.geometry(graph);
if ((geometry === 'point' || geometry === 'line' || geometry === 'area') && !change.isUsed(graph)) {
warnings.push({
message: t('validations.untagged_' + geometry),
tooltip: t('validations.untagged_' + geometry + '_tooltip'),
entity: change
});
}
var deprecatedTags = change.deprecatedTags();
if (!_.isEmpty(deprecatedTags)) {
warnings.push({
message: t('validations.deprecated_tags', {
tags: iD.util.tagText({ tags: deprecatedTags })
}), entity: change });
}
if (geometry === 'line' && tagSuggestsArea(change)) {
warnings.push({
message: t('validations.tag_suggests_area', {tag: tagSuggestsArea(change)}),
entity: change
});
}
}
return warnings;
};
Kurzfassung: 53 Zeilen “Code”, Warnung wenn mehr als 100 Objekte gelöscht werden sollen, alte Tags verwendet werden oder ein Area-Tag fehlt. Eine weitere Überprüfung wohl auf taglose Objekte?
Ich bin immer wieder überwältigt über die Engstirnigkeit mancher Entwickler.
Gruss
walter
jaja, jetzt kommt: “Bau es doch ein” - nee , mach ich net. Da die “Doku” noch schlimmer ist als bei Josm, hab ich eh kein Chance. Oder seht ihr hier einen einzigen Comment?
Können wir einen Link haben um das Geschehen zu verfolgen?
Nicht von mir, war von Nakaner.
Hier ist die Diskussion (es gab keine inhaltliche) zur Einführung der _n-Suffixe: https://github.com/openstreetmap/iD/issues/2043, https://github.com/openstreetmap/iD/pull/2228
Toll. Gerade unsere iD-Zielgruppe der Newbies liest natürlich Informationen im Git. Und beteiligt sich rege an der Diskussion.
Wieder ein Zeichen der Realitätsfremdheit dieser Entwickler.
Gruss
walter
ps: ich hör mal auf zu dem Thema zu motzen, sonst “troll” ich mal wieder. Mir kommt halt nur die Galle hoch.
Ich habe den Bugreport noch nicht verfasst, sondern wollte erst noch eure Meinungen zu der Thematik abwarten. Den Bugreport werde ich vsl. erst heute spätabends oder morgen verfassen.
@ wambacher, Nakaner:
herzlichen Dank für Euer Engagement und Gratulation zu Eure tollen Funden beim Festnageln der iD-Problematik – jetzt wissen wir also, wie dieses Übel in die Welt gekommen ist! Ja ja, die schlimmsten Bugs sind oft diejenigen, die als oberschlaue Features gedacht waren …
Bitte entschuldigt, dass ich, obwohl ich diesen Thread hier eröffnet habe, Euch nicht geantwortet habe – zumindest ein paar Dankesworte wären angebracht gewesen! 
– ich hatte gerade jetzt zuviel anderes zu tun und wollte die Sache erst nochmal selbst in Ruhe in iD ausprobieren (das ich nicht gut kenne), um wirklich zu kapieren, was da vor sich geht.
Man muss diese Schritte übrigens nicht einmal exakt befolgen – iD ist großzügig genug, auf vielen Wegen _1-Tags zu erzeugen :). So kann man z.B. auch ein Node mit einer beliebigen Objektvorlage formatieren (das ist es ja, was Newbies meistens machen werden). Wenn man dann unter “Alle Eigenschaften” einfach einen schon vorhandenen Key nochmals eingibt, hängt iD sein _1, _2 usw. dran. (Z.B.: lege neuen “Punkt” an, wähle Vorlage “Park”, scrolle zu “Alle Eigenschaften”, wo korrekt leisure=park angezeigt wird, tippe dort links erneut leisure ein, springe mit dem Tab nach rechts – voilà, schon benennt iD unser neues leisure in leisure_1 um.)
Ich schließe mich Lösung 2 an, fände es aber wirklich wichtig, dass zuerst eine deutliche Warnung angezeigt wird, bevor die Tags …_1, …_2 etc. verschwinden. Denn: wenn ein Benutzer Tags wie tag=x, tag_1=y verwendet, dann ist ja nicht klar, welcher Wert (x oder y) nun beibehalten werden soll! Ich habe mehrfach Fälle gesehen wie building=yes, building_1=house, in denen offenbar jemand den zuerst eingegebenen Wert verbessern wollte – wenn man building_1=house einfach (stillschweigend bzw. ohne klare Warnung) löschen würde, würde in diesen Fällen gerade der falsche Wert beibehalten. Doch man kann auch nicht umgekehrt einfach den Wert aus tag_1=* in tag=* übertragen. Daher muss der User selbst entscheiden – und deshalb ist eine klare Warnung nötig.
Diese Lösung hätte den großen Vorteil, dass diese _1, _2 etc.-Tags gar nicht erst angelegt würden! Sofort, wenn ich (bei schon vorhandenem *name=**) links erneut name eintippe und den Tab drücke oder irgendwo außerhalb klicke, sollte das Popup erscheinen und das eingetippte name rot o.Ä. markiert und ausgewählt werden; beim nächsten Klick, wenn das Popup verschwindet, würde am besten das eingegebene name gelöscht und der Kursor erneut dort plaziert, als deutliche Aufforderung, einen anderen Wert einzutippen. Das ist aufwändig umzusetzen, wäre aber vielleicht die eleganteste und zugleich penetranteste Lösung, die ganz deutlich werden lässt, dass es nicht so geht :).
Aber schlagt vor, was Ihr für richtig haltet – hauptsache iD hört auf, unsere Daten mit diesem Sch… vollzumüllen und die Leute auf dumme Gedanken zu bringen! Denn, was man nicht vergessen darf: nur ein Teil der _1-Tags wird von iD automatisch erzeugt – ein anderer Teil wird von fortgeschrittenen Newbies angelegt, die eben von iD “gelernt” haben, dass man beliebige Tags mit _1, _2 etc. anlegen kann und sogar soll. Das sind die Folgen dieses dummen Features, und gerade deshalb (weil es sozusagen “die Jugend verdirbt”) halte ich es für einen dicken fetten Bug.
Vielleicht sollte man so etwas (natürlich netter formuliert) auch in den Bug-Report schreiben, damit die iD-Jungs (und Mädels?) kapieren, was sie da anrichten.
Vielen Dank! Kann ich Dich irgendwie unterstützen, z.B. mit einem Kuchen und Kerzen? Im Ernst: wenn es helfen würde, um diesen Blödsinn aus der Welt zu schaffen, backe ich Dir gerne einen Kuchen (soweit meine Künste reichen)! Ich kann ihn Dir per DHL zusenden (dann sollte es aber ein recht stabiler Kuchen werden, nix mit Sahne), oder Du kannst mal in Bad Rappenau vorbeikommen …
Herzlichen Dank und Grüße von
Chrysopras
Die Sache mit dem Kuchen sollte (als Insider-Witz) ausdrücken, dass ich nicht mit einer schnellen Behebung rechne und der Bug erst geschlossen werden wird, wenn sich ein bis zwei Jahre später mal wieder jemand auf Talk über iD aufregt. https://github.com/openstreetmap/iD/issues/1461#issuecomment-68151941 https://lists.openstreetmap.org/pipermail/talk/2015-February/071953.html
Wenn jemand Kuchen bekommt, dann derjenige, der einen ewig offenen Bug fixt.