Hallo Chrysopras,
könntest du ein paar Beispiele (Changeset- oder Node-/Way-IDs) nennen, damit man sich das mal mit Achavi anschauen kann? Vielleicht kann man dann durch gezieltes Mergen von Objekten in iD den Bug reproduzieren.
Sollte das ein absichtliches Feature von iD sein, dann bestätigt das mein Bild der iD-Entwickler.
Viele Grüße
Michael
Hier mal eine zufällige Auswertung der POI:
-- Beispiel einer Abfrage
select * from (
select osm_id,skeys(tags) "key"
from planet_osm_point limit 100000000
) tags
where key like '%\_3'
order by osm_id;
osm_id | key
------------+-------------------------
501454437 | alt_name_1
501518801 | alt_name_1
501519345 | alt_name_1
1096391136 | alt_name_1
1538882779 | highway_1
1562369220 | amenity_1
2312676153 | website_1
2312676153 | shop_1
2754996975 | cuisine_1
2756001790 | email_1
2826218483 | name_1
3049300115 | name_1
3053351433 | fire_hydrant:position_1
3124416274 | inscription_1
3293164669 | shop_1
3294569636 | shop_1
3325205294 | historic_1
3334330742 | alt_name_1
3343587614 | historic_1
3399326431 | public_transport_1
3399326438 | public_transport_1
3400211945 | name_1
3400211946 | name_1
3400508828 | phone_1
3413066740 | highway_1
3415858965 | highway_1
3415858966 | highway_1
3415873411 | shop_1
3433367130 | cuisine_1
(29 Zeilen)
osm_id | key
------------+--------------------------------
86002384 | name_2
424298019 | country_code_iso3166_1_alpha_2
2479805447 | note_2
2746287284 | phone_2
3035532659 | name_2
3056956365 | alt_name_2
3353704076 | alt_name_2
3458015761 | name_2
(8 Zeilen)
osm_id | key
------------+---------------
26608622 | name_3
26608799 | name_3
26608892 | name_3
29907324 | name_3
44998843 | alt_name_3
318156802 | url_3
501264779 | alt_name_3
501411625 | alt_name_3
501450705 | alt_name_3
538190758 | ref_3
538283595 | ref_3
538292790 | ref_3
857474778 | inscription_3
1405220443 | name_3
1606236757 | field_3
1606236758 | field_3
1606236759 | field_3
1606236760 | field_3
1606236766 | field_3
1739119083 | description_3
2037291057 | Doctor_3
2074694277 | image_3
2123443833 | leisure_3
2129660694 | alt_name_3
2189951896 | alt_name_3
2565033190 | note_3
2565131821 | note_3
2565150429 | note_3
2569766698 | inscription_3
2569766724 | inscription_3
2576028073 | note_3
2879593532 | name_3
2885341038 | source_3
2973222270 | phone_3
2999520670 | amenity_3
2999520670 | shop_3
3023074972 | alt_name_3
3025479896 | name_3
3059124627 | sport_3
3085823200 | Doctor_3
3085833328 | Doctor_3
3145759297 | source_3
3215726369 | name_3
3241127149 | name_3
3257065341 | object_3
3265513124 | website_3
3282593487 | alt_name_3
3283272336 | note_3
3302317973 | website_3
3304283861 | amenity_3
3312097227 | cuisine_3
3337030493 | website_3
3355807321 | name_3
3385717144 | addr:street_3
3396913308 | website_3
3408511027 | name_3
3409392953 | inscription_3
3413212933 | amenity_3
3413452046 | inscription_3
3429829064 | name_3
(60 Zeilen)
%_1 in 1 Mio, %_2 in 10 Mio und %_3 in 100 Mio zufällig ausgewählter Tags, weil allzu häufig sind die wohl nicht.
Eine Auswertung über alle Tags würde “etwas länger” brauchen, ist aber natürlich machbar. Nur fragen.
Gruss
walter
Wenn ich sowas wie http://www.openstreetmap.org/way/253224206 sehe, dann weiss ich, wieso ich gegen das “_n”-Schema bin.
Die einzelnen Adressen gehören an die Eingänge. Wenn man dann will, kann man eine Site-Relation für das “Quartier 17” einbauen. Aber mit addr:street_3 wird kein Router was anfangen können…
Ich schaue mir gerade die name_1=* in Deutschland an. Sie stammen meist (nicht immer von iD-Usern). Entweder ist das ein übler versteckter, nicht beabsichtigter Bug von iD oder die User haben das absichtlich eingegeben.
Wieso denn so optimistisch? Das könnte auch Absicht (in iD) sein, da einen Bug, der an das, was der Anwender eingibt, einfach _N dranhängt, ist mir schwer vorstellbar.
Ich schau mir mal die Sourcen an.
Gruss
walter
Bingo: In iD/js/id/ui/raw_tag_editor.js gibt es eine Funktion, die wohl genau sowas macht.
function keyChange(d) {
var kOld = d.key,
kNew = this.value.trim(),
tag = {};
if (kNew && kNew !== kOld) {
var match = kNew.match(/^(.*?)(?:_(\d+))?$/),
base = match[1],
suffix = +(match[2] || 1);
while (tags[kNew]) { // rename key if already in use
kNew = base + '_' + suffix++; // <----------- da
}
}
tag[kOld] = undefined;
tag[kNew] = d.value;
d.key = kNew; // Maintain DOM identity through the subsequent update.
this.value = kNew;
event.change(tag);
}
Hallo,
Ich habe den Bug jetzt reproduzieren können. In der folgenden Anleitung lernt ihr, wie ihr einen Node anlegen könnt, der eine doppelte Ampel ist.
highway=traffic_signals
highway_1=traffic_signals
Jetzt ist mir auch klar, warum Newbies, von denen ich nicht erwarte, dass sie im Wiki nach einem Tagging für zwei Namen suchen, name_1 usw. verwenden. Sie geben einen Namen ein und geben, weil sie nicht wissen, dass Keys bloß einmal pro Objekt erlaubt sind, erneut den Key ein. iD macht daraus ein name_1 und perfekt ist der Quark.
Jetzt guck ich mal in den Bugtracker und melde es ggf. Wahrscheinlich werde ich aber auch eine Torte backen und eine Kerze anzünden müssen. 
Viele Grüße
Michael
Hat sich überschnitten. Das ist kein Bug - das ist ein Feature. Siehe meinen vorherigen Beitrag.
Gruss
walter
Ja, es ist ein Feature. Danke für den Blick in den Code. Aber es ist ein IMHO bescheuertes Feature.
JOSM löst das anders. Wenn ein Objekt schon name=* hat und ich bei der Tag-Eingabe wieder “name” eingebe, wird kein “name” vorgeschlagen, sondern alles andere, was mit “name” beginnt, z.B. “name:de”.
In iD wäre das zu lösen, indem man entweder wie JOSM agiert oder vor oder nach der Eingabe des Values dem User eine Warnung anzeigt und spätestens beim Wechsel zum nächsten Tag die Fehleingabe, die derzeit als name_1 gespeichert werden würde, sich in Luft auflöst. Ich würde Lösung 2 bevorzugen, da Lösung 1 für einen Newbie-Editor Risiken bzgl. der Datenqualität birgt. Wenn dem User, der einen Zweitnamen eingeben will, “name:de” präsentiert wird, dann tippt der eben blind und unwissend, wie er ist, den Zweitnamen bei name:de ein.
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.