Neue Keys in der Datenbank - meistens falsch

Hallo allerseits,
auf Basis der von Taginfo aufbereiteten Daten habe ich ein kleines Tool geschrieben, das automatisch eine Liste mit denjenigen Keys erzeugt, die vor kurzem neu im OSM-Datenbestand aufgetaucht sind:
http://osm.mueschelsoft.de/taginfo/newkeys.htm

Wie man sieht, in den meisten Fällen handelt es sich einfach um Tippfehler (die man einfach korrigieren kann), in einigen Fällen um falsch verstandene Tagging-Anleitungen (wo ein ein netter Hinweis an den jeweiligen Mapper häufig gerne angenommen wird) und nur in ganz wenigen Fällen um richtige Keys.

Anmerkungen, Tipps und Verbesserungsvorschläge sind natürlich sehr gerne gesehen!

Moin,

die Liste enthält etwa das, was ich erwartet habe: viele falsch geschriebene Tags und manche unverständliche Keys.

Für Deutschland hat der Bot Wall-E bislang viele Fehler korrigiert. Er ist leider seit einigen Monaten nicht mehr aktiv.
Vielleicht kann man ihn reaktivieren oder sogar ein ähnliches Tool weltweit einsetzen.

Die Fehler zu analysieren und die Verursacher auf potentielle Missverständnisse hinzuweisen, ist sehr viel Aufwand.
Es könnte auch zu Verstimmungen führen, wenn man andere Mapper fragt, ob sie die korrekte Schreibweise eines Tags nicht kennen. :wink:

Vielleicht sollte man das Problem in der Wurzel (Editor) anpacken und beim Speichern prüfen, ob unbekannte Keys und übliche Tippfehler vorkommen. Der Mapper könnte dann aufgefordert werden, die Fehler zu korrigieren und für bewusst erstellte Keys einen kurzen Kommentar abzugeben. Keys mit variablen Teilen müsste man davon ausnehmen.

Klingt für mich nach einer super Idee, schon um meine eigenen Tag-Tippfehler zu minimieren. :wink: Das wäre doch in JOSM sicher “relativ leicht” umsetzbar (schließlich hat es schon eine Fehlerprüfungs-Funktion, die beim Upload zumindest die geänderten Objekte prüft, also “nur” noch auf Tag-Kontrolle erweitert werden müsste). Bei iD allerdings … aber hoffentlich belehrt mich da jemand eines Besseren.

Keys mit variablen Teilen sollte man prinzipiell “verbieten”, also nicht empfehlen/benutzen, da deren Auswertung so gut wie unmöglich bzw. sehr, sehr schwierig ist.

Gruss
walter

ps: wer es nicht glauben mag, der möge mal eine Abfrage (egal ob Overpass oder SQL) scheiben, die einen String innerhalb aller name:XX-Tags sucht.

Diese Funktion gibt es in JOSM im Prizip bereits. Man muss dazu in den Validator-Einstellungen “unwichtige Warnungen beim Hochladen anzeigen” und ggf. weiter unten “Eigenschaftsprüfer” aktivieren. Dann werden alle Schlüssel bzw. Werte welche nicht in den Vorlagen sind ausgegeben. Die Fehlermeldungsgruppe heißt dann “Vorlagen enthalten Schlüssel nicht” bzw. “Vorlagen enthalten Wert nicht”.

Ups – danke! – wieder was gelernt. Muss ich ausprobieren. Das Tolle (und ein bisschen auch das Problem) an JOSM ist, dass es so viele Funktionen und Optionen hat, dass man (ich) nie alles kennt. :wink:

… und dann gibt es auch noch die explizite Liste mit falsch geschriebenen Schlüsseln in JOSM, da wird dann z.B. folgende Meldung angezeigt “Schlüssel amienty ähnelt amenity’.” https://josm.openstreetmap.de/browser/josm/trunk/data/validator/words.cfg

Schöne Auswertung, aber regional oder auf bbox und/oder per RSS wäre irgendwie richtig gut.

Ich nutze die Funktion seit langem, weil ich fast nur noch QA mache und dann in dem Abwasch noch andere Abfälle sehe und bei eindeutigen Fällen auch korrigiere.
Meine Meinung dazu: Wenn das standardmässig aktiv wäre und zwar nur für selbst geschriebene Tags und nicht (wählbar für User, die wissen, was sie wollen) für geänderte Objekte, dann wäre es ganz hilfreich. Leider gibt es soweit ich weiss keine Möglichkeit für so eine feine Granulation.
Problem 1: ist eben auch, dass bei vielen Murxtags nicht immer eindeutig ist, dass es ein Schreibfehler ist. Und dann gibt’s noch so “Murxtags” wie bspw. building=part, die man mit viel Mühe irgendwo in irgendnem Proposal vergraben findet … aber das is wieder ein anderes Thema.
Problem 2: wenn ich als Laie was bearbeite und eine Fehlermeldung bekomme die ich nicht verursache, dann schaue ich mir das 2-3 Mal an und irgendwann kippe ich auch eigene Warnungen und Fehler in die DB.

Danke für den Tipp.
Ich habe den Validator einmal auf einen halben Stadtteil angesetzt. Es wurden Dutzende unbekannter Keys angezeigt.
Beim schnellen Durchsehen konnte ich einige mir unbekannte Tags, aber keine offensichtlichen Fehler finden.
Um Buchstabendreher und falsche Syntax (z.B. Punkt statt Doppelpunkt) zu finden, hätte ich die Keys buchstabieren und zum Teil im Wiki nachschlagen müssen.
Diese Prüfung werden wohl nur wenige Mapper nutzen und nur auf die eigenen Änderungen anwenden.

Die Aussage, dass ein Key bislang seltener als N mal benutzt wurde (z.B. mit N=25) würde viel weniger falsche Warnungen verursachen und vermutlich eher aktiviert und beachtet.

Wenn ein Mapper die Möglichkeit hätte, einen neuen Tag im Editor mit einem kurzen Kommentar zu versehen und so von Warnungen auszunehmen, wäre dies viel niederschwelliger als eine Wikiseite anzulegen. Eine Liste der Keys mit Kommentaren würde helfen neue Tags von Tippfehlern zu unterscheiden und zumindest eine grobe Idee von Sinn der Keys vermitteln.

Diese Funktion finde ich sehr nützlich. Sie hat mich schon häufiger davor bewahrt, Tippfehler zu speichern.

Es gibt in JOSM eine Liste von tags, welche bei der Überprüfung ignoriert werden sollen, d.h. tags, die offenstichtlich in Ordnung sind, für die aber noch keine Vorlage erstellt wurde, oder es keinen Sinn macht eine zu erstellen. Diese Liste wurde in den letzten Tagen noch erweitert, sodass nun weniger false-positive erscheinen sollten (u.a. wird nun das ganze TMC-Zeugs ignoriert). Für weitere Vorschläge für diese Liste können gerne JOSM-tickets erstellt werden.

Liste: https://josm.openstreetmap.de/browser/josm/trunk/data/validator/ignoretags.cfg

Wo muss man die hinkopieren?
EDIT: erledigt, scheint “hart verdrahtet” zu sein, wie man in Programmierersprache sagt.

Am besten in ein JOSM-ticket https://josm.openstreetmap.de/newticket

Ich fürchte, das wird nichts. Taginfo liefert ja nur globale Daten (und von einigen Ländern in denen lokale Kopien laufen) - für Regionen und bbox geht wohl nichts ohne eine komplette Datenbank inklusive History.

Es geht ja eigentlich nicht um Keys, die in einer bestimmten Region neu auftauchen, sondern um global neue Keys, die sich in einer bestimmten Region befinden. Daher sollte man die Ergebnisse aus dem globalen Taginfo zum Beispiel mit Overpass auf die Region filtern können.

Problematisch ist nur, wenn sich in bestimmten Regionen niemand dieser Keys annimmt, da dann häufige Schreibfehler nicht mehr neu bzw. selten in der Datenbank sind.


[out:json][timeout:25];
// gather results
(
  // query part for: “~"name:*"~Munich”
  node[~"name:.*"~"Munich"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

http://overpass-turbo.eu/s/cSG

Toll :slight_smile:


select distinct id
 from (select id, value "name", localname, level, (each(tags)).*
            from boundaries) foo
          where (key = 'name' or key like 'name:%')
             and key != 'name:suffix'
             and value ilike 'munich'
;
   id   
--------
 181652
  62428
(2 Zeilen)

Zeit: 4506,648 ms

Geht, aber einfach war das net, gell? Gibt es nicht irgendwo eine Wiki-Seite mit Overpass-Abfragen? Bau diese “Perle” doch bitte ein.

Gruss
walter

Stimmt natürlich… Ich werde mal schauen, ob das mit verträglicher Performance in Overpass läuft.

Mein Hintergrund ist der, dass ich keine möglicherweise fehlerhaften Keys in Timbuktu korrigieren möchte, sondern nur die in meiner “Homezone” und/oder in DACH. Bin da mal in Polen auf die Fresse gefallen, die sich da einig waren lokal irgendwas Neues einführen zu müssen.

Tja, da habe ich leider ein Problem. Die Overpass-Query wird leider zu lang um sie direkt an Overpass-Turbo übergeben zu können und ich bekomme es nicht hin, dass OT meine Query lzw-komprimiert-base64-encoded annimmt, obwohl das eigentlich gehen sollte.

Hallo mueschel,
seit gestern ist in Deiner Auswertung noch die Spalte Editor hinzugekommen. Wenn ich dort auf J für JOSM klicke, erscheint immer ein neues Fenster mit den Buchstaben OK, das JOSM als Antwort auf das Fernsteuer-Kommando antwortet. In den meisten Anwendungen, die JOSM über einen Klick aufrufen, wird diese Antwort nicht angezeigt - wäre hier auch ganz vorteilhaft. Wie das geht, steht in diesem Posting (Die Frage in #1104, die Antwort (hiddenIframe) in #1106).

Franz