neu hinzugefügte Keys

Hallo Allerseits,

die letzten zwei Tage habe ich mich (mal wieder) intensiver mit mueschel’s newkeys Liste auseinandergesetzt und zahlreiche PNs, hauptsächlich aber Changeset Diskussionskommentare geschrieben.

Dabei ist mir folgendes aufgefallen - was man auch schon ein bisschen nur beim drüberschauen über die Liste sieht:
Typos, also Tipp-/Schreibfehler

Als Editoren ist aber wirklich auch alles dabei was Rang und Namen hat: OsmAnd, Vespucci, iD, JOSM, maps.me, usw.
Wobei es bei mobilen Apps vermehrt auch noch zu folgende Phänomenen kommt: erster Buchstabe des Keys ist GROSS, oder Leerzeichen nach einem Doppelpunkt, oder Autovervollständigung (webseite anstatt website).

Jetzt frage ich mich natürlich: Wie und auf welchem Wege könnte man nun das Erzeugen neuer Keys minimieren?
Laut der Tabelle wären es durchschnittlich ca. 37 pro Tag, macht im Jahr dann 13.500 neue Keys

Meine Gedanken, einfach mal so Brainstormmäßig:

  • bei den mobilen Apps/Editoren die Eingabefelder aus der Autovervollständigung nehmen
  • bei den mobilen Apps/Editoren beim key keine Großschreibung erlauben (FIXME wäre meiner Meinung nach die einzige Ausnahme)
  • Editoren (allgemein) halten (regelmäßig aktualisiert) eine Liste von keys vor und geben eine Warnung aus, wenn ein key zum Hochladen nicht in dieser Liste ist
  • Editoren (allgemein) checken die hochzuladenden keys live vorm Hochladen gegen die Datenbank
  • Unzulässige Zeichen in key verhindern (was mich echt wundert, dass es Editoren gibt, die Leerzeichen und sogar Gleichheitszeichen = zulassen ?!)

So, darf nun gerne von Euch erweitert und/oder diskutiert werden :wink:

PS: Habe gerade über eine PN auch einen Hinweis auf folgende Liste bekommen, die zumindest für ein paar Länder die keys und deren zuletzt getaggte Werte ausgibt, z.B. für den Anfangsbuchstaben f in Irland/Nordirland

Stimme dir zu. Wir Mapper könnten nur korrigieren, die Editoren können es vermeiden. Die mir bekannten Tickets dazu in iD wurden alle geschlossen. Vielleicht setzt sich ja irgendwann ein Validator durch und bringt Besserung.

Leider wirst du niemanden offiziellen finden, der sich dafür interessiert. Wir reden, was wir nicht in OSM wollen, gegen Typfehler hat aber niemand etwas. Mir sagte mal jemand, ich solle das Objekt als Ganzes betrachten, nicht nur die (falsch geschriebenen) Tags. Dass es dann niemand mehr findet, spielte keine Rolle.

War das vielleicht in Zusammenhang mit Jochen Topf Bereinigungschallenge? Da hat dieser Satz nämlich Sinn, wenn man nachträglich (nach langer Zeit) systematisch taginfo abarbeitet macht es in der Tat mehr Sinn das ganze Objekt zu begutachten. Ich habe bei einigen falschen Keys die Tage auch auf eventuelle andere Ungereimtheiten hingewiesen.

Joa, die meisten der Vorschläge sind soweit ganz gut. Auch für nicht-mobile Editoren ist es wohl sinnvoll, wenn sie Kleinschreibung anmerken. Bei allen Vorschlägen sollte der Editor nur eine Warnung anzeigen (die dafür gerne sehr prominent) und nicht endgültig das Hochladen verbieten, sonst fühlt sich der ein oder andere wieder auf den Schlips getreten und es ist ja so, dass es zwar die Regel ist, z.B. keys klein zu schreiben, aber man theoretisch schon neue keys erfinden darf, die sich nicht daran halten.

Letztlich musst du alle Editorenprogrammierer davon überzeugen, das umzusetzen. Bei id könnte das schwierig werden, fürchte ich.

Aus meiner Sicht wären die idealen Warnungen:

  • sofort beim Eingeben des Tags sichtbar (nicht wie z.B. der JOSM-Validator erst beim Hochladen oder auf Anfrage)

  • nicht gar zu aufdringlich (also kein Popup – das sollte klaren Fehlern vorbehalten sein)

  • mit hilfreichem Erklärungstext und idealerweise automatischem Korrekturvorschlag versehen.

Letztlich also vielleicht so, wie man es als Entwickler von IDEs kennt: Als Icon neben dem Eingabefeld, das beim Anklicken dann den Fehler beschreibt und Lösungen anbietet.

Dürfte in der Tat schwierig werden. Allerdings bringt es durchaus auch schon was, wenn einzelne Editoren mit gutem Beispiel vorangehen. Es würde das Problem zwar nicht komplett aus der Welt schaffen, aber zumindest mengenmäßig reduzieren.

eigentlich ist es ja klar aber denkt dran: Bei Keys keine Großschreibung zu erlauben ist schwierig, da es wahrscheinlich unzählige Ausnahmen geben wird (z. B. ref:IFOPT).
Ansonsten finde ich den Vorschlag gut. Jedoch gibt es aus meiner Sicht, wenn man von Schreibfehler in Keys absieht, noch weitere Aspekte:

  1. Viele Mapper lesen das Wiki nicht (okay, da können wir jetzt nichts für) und wissen daher nicht, dass es für das, was sie eintragen wollen, in der Regel schon einen Key gibt. Dann erfinden sie einfach einen neuen. Aber gut, was soll man da machen…
  2. Das allgemeine Einführen neuer Keys für durchaus relevante aber noch nicht “mappbare” Informationen halte ich für sehr aufwendig. Ich glaube, das wurde auch irgendwo schon mal angesprochen. Da ist man gerne mal so faul und nutzt vielleicht den eigens ausgedachten Key einfach ohne Diskussion oder Ähnliches (oder geht das nur mir so?)

Viel mehr darauf setzen, dass in den Editoren möglichst nur Freitext für Eigennamen etc. möglich ist und keys und values so weit wie nur irgend möglich über Vorlagen bearbeitet werden zum Beispiel.

Das ist so ein Punkt, wo das Verfahren massiv vereinfacht werden sollte. Wie man das Problem lösen soll dass manche Menschen eben kein Einglisch sprechen habe ich allerdings auch keine Idee…

  • Es gibt keinen weit verbreiteten Editor der keine automatische Vervollständigung bei bekannten Keys macht (aus irgendwelchen Gründen macht das JOSM case sensitive, was wohl schlicht ein Bug ist)
  • iD arbeitet normalerweise über Presets, wie auch andere Editoren und solche die es gerne wären

Sprich es ist gar nicht so einfach unabsichtlich einen “neuen” Key einzugeben.

Wenn man die Liste anschaut ist es auch nicht so, dass Tippfehler bei wichtigen Keys überwiegen, sondern zum grössten Teil sind es irgendwelche Zusatzinformation die mehr schlecht als recht erfasst wurden.

IMHO wird das Problem, dass sich eh im %% Bereich bewegt völlig überbewertet und da die Hilfsmittel schon da sind, ist es eher unwahrscheinlich, dass noch mehr technische Massnahmen irgendwas bringen werden solange man irgendwo dann doch selber direkt Keys eingeben kann (was wir ja wohl als Möglichkeit immer noch zulassen wollen).

Ja wenn denn die User auch die Presets nutzen würden. Hatte z.b. ein Beispiel, wo nachträglich an einem barrier=fence die Höhe, leider manuell mit “heigth” erfasst wurde.
Aber ja, natürlich liegt das alles im Promille Bereich.

Und klar, eine andere Möglichkeit wäre natürlich auf Grund der “newkey” Liste viel häufiger und konsequenter entsprechende Changesets zu kommentieren und danach zu fragen, was die neuen Keys aussagen, was sie bedeuten, ob sie wirklich öffentlicher und allgemeiner Natur sind, usw.

SimonPoole schrieb:

Sehe ich auch so.

Da ist wirklich alles dabei:
Tippfehler, Notbezeichnungen (weil der richtige Tag garde nicht greifbar ist) oder man dem Englischen nicht mächtig ist, sinnvolle Zusatzinfos (ob die jemals relevant werden ist etwas anderes) und natürlich auch komisches.

Was die Editoren betrifft so decken diese vielleicht 99% der gängigen tags ab aber auch nicht mehr.
Es passiert mir regelmäßig, dass komplette keys fehlen oder aber tags, weil es sich noch nicht bis zu den Editorentwicklern herumgesprochen hat oder etwas im Moment noch exotisch oder noch nicht etabliert ist.

Systematisch nach Tippfehler suchen und diese halb-automatisch korrigieren. Das wäre mein Vorschlag.
Da die Bedeutung/Sinn/Zweck NICHT angefaßt wird sollte das ohne große Diskussion machbar sein.

Grüße,
G.

Das halte ich auch für die beste Lösung.
Könnte man nicht WallE (hieß doch so?) wieder aktivieren, da wurden doch Tippfehler korrigiert?

Da ist aber, IMHO, das Problem das Vorlagen vor allem in JOSM nur umständlich zu nutzen sind, ev. was für GSOC 2018.

Eins der Probleme ist schlicht, dass sich der Stand der Presets zwischen den Editoren stark unterscheidet (siehe auch https://github.com/simonpoole/beautified-JOSM-preset/issues/27 im default preset von JOSM fehlen noch ein paar mehr). Der Effekt ist weniger ausgeprägt bei den wirklich häufig vorkommenden Objekten (Strassen etc), dort sind es eher irgendwelche Subtags, aber bei den Sachen die ein paar 1000 mal vorkommen oder seltener.

Zur Info: heute haben sich Potlatch und JOSM gleichberechtigt die Klinke in die Hand gegeben, iD war aber auch vertreten…

PS: und die heutige Version von website war webiste …

So, und wieder die Liste des heutigen Tages abgearbeitet. Mal gucken wie lange ich das durchhalte … pro Tag durchschnittlich ca. eine Stunde Aufwand :confused:

Was hast du denn jetzt gemacht? User per CS-Diskussion angefragt? Keys verbessert? oder beides?

gruss
walter

Guck doch mal bei pascal neis osm discussions :wink:
Ich maße mir nicht unbedingt an, die eventuellen Fehler zu verbessern - und mir somit ein Haufen weiterer osmose, keepright, und sonstiger QA Tools aufzuhalsen - Spaß beiseite, häufig frage ich auch nach, was denn der neue Key aussagt, wenn es sich nicht um einen reinen Typo handelt.

ADD: bzw. meine erzeugten Changeset Kommentare.

Da ich die letzten Tage einiges mit iD gemacht habe:
Eigentlich nutze ich die Presets nur selten.
Meistens die Autovervollständigung in den “unteren” Roh-Feldern, also bi warten cycle tab d warten esignated …

Das bringt mich auf die Idee, ob es evtl. ein Tool gibt / jemand schreiben könnte hüstel, dass die EIGENEN Keys (und values) auflistet. womöglich entdeckt man dabei auch manche nette Neukreation wie bi=d weil man wieder zu ungeduldig war … :wink:

Immerhin die Tage zum Ausmerzen eines key-value-Paares beigetragen in Vorbereitung auf die aktuelle session. Bei taginfo bicycle=use_cycleway statt use_sidepath entdeckt in einer Region, war offensichtlich nur ein einziger Autor vor rund einem Jahr, der das nach Anschreiben binnen weniger Stunden reparierte …
Dafür mache ich gerade einen Praxistest für einen neuen value … :wink:

So, und jetzt gibt es ein Problem, bei dem auch ich nicht mehr weiter weiß. Gleich der erste Eintrag in der Liste mit dem “Nichts”, und folgender OverpassQuery Abfrage:


[out:json];(node[""];way[""];>;rel[""];);out meta;

overpass meldet natürlich einen Fehler

was ja auch richtig ist. Wer kann helfen das Element mit dem “empty” String zu finden?

PS: Ich habe in meinen letzten Beitrag hier noch die Links zu osm discussions ergänzt.