neu hinzugefügte Keys

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.

Hier hilft die Doku im Wiki weiter:

node[~“^$”~“.”]; // find nodes with empty key (“”) and any value

Das Problem wurde aber zwischenzeitlich schon gefixt: http://www.openstreetmap.org/node/5104989386/history

wenn du mir das in Pseudo-SQL übersetzt, setze ich mal meine DB drauf an.

Gruss
walter

Danke walter, hat sich aber ja mit der Antwort von mmd schon erledigt :wink:

jo gesehen - aber zu spät.

hoppala, so ganz nebenbei sticht man dann halt auch mal ein pulverfass an :expressionless:

Harald wies mich heute (zu recht) auf zwei Schreibfehler hin… ok, der eine… da vergaß ich ein kleines e… geändert.

Das andere ist aber weitläufiger…

Da änderte ich gestern den Key von “de.boundary_name” nach “de:boundary_name” tausche also Punkt gegen Doppelpunkt. Harald wies mich im Changeset zurecht hin, daß es natürlich “boundary_name:de” heißen muß. Ich schaute also nochmal genauer und sah, daß in der Ersterfassung des Steines zwei verschiedene Mapper zugange waren, Radler59 mit drei und ich mit einem Stein… Daß ließ mich vermuten, daß da ein System dahinter steckte… und richtig…

Die ursprüngliche Schreibweise “de.boundary_name” findet sich mindestens Deutschlandweit…: http://overpass-turbo.eu/s/rL3

Ich halte das für die Folge einer fehlerhaften JOSM- Vorlage…

Übrigens “de.boundary_name” findet sich derzeit 694mal in der Datenbank https://taginfo.openstreetmap.org/keys/?key=de.boundary_name#overview

Von der Sache her müsste es in einem Rusch geändert werden, was aber dann unter sie entsprechenden Massenedit-Regelungen fallen würde…

[Edit]
Ich würde es auch machen… Soweit ich es überblicke betrifft es nur D und mit 35 Value-Varianten eine überschaubare Zahl, die auf Grund des Value-Inhaltes kaum Probleme machen dürften, oder?

Ich schreibe auch Lutz nochmal.
[/Edit]

Tja, Harald: kleine Ursache, große Wirkung… Danke für den Blickiges Auge. :slight_smile:

Sven