In der heutigen Liste der fehlerhaften Keys (Link siehe Beitrag #1) kamen einige Keys mit dem Zeichen 0x7F vor, die sich über Overpass-Suche nicht direkt finden lassen.
Hier die Liste mit den Keys, die das Zeichen 0x7F enthalten:
Falls Du die Objekte einzeln anschaust (und überlegst, was genau gemeint war und es entsprechend korrigierst),ist das ok. Falls Du aber eher Suchen-und-Ersetzen-mässig vorgehen möchtest, ist es ein “mechanischer Edit”, der zuvor diskutiert werden müsste.
Bei einem mechanischen Edit könnte beispielsweise das Problem auftreten, dass ein Objekt ein “landuse=forest” und ein “landuse%7F=foobar” hat, und jemand, der nicht hinschaut, verpasst dem Objekt dann “landuse=foobar” und überschreibt damit die vermutlich richtigen Daten.
Ausserdem - egal ob mechanisch oder von Hand repariert wird - wäre auch eine Ursachenforschung interessant: Ist es immer der gleiche User oder immer der gleiche Editor? Dann liegt vielliecht ein systematischer Fehler vor, den man beheben muss, weil er sonst immer wieder auftaucht.
Zu Deiner eigentlichen Frage: Wenn Du weisst, dass ein bestimmtes Tag ein an einem bestimmten Tag (…) neu hinzukam, kannst Du von planet.openstreetmap.org das Tagesdiff dieses Tages herunterladen und darin suchen, das müsste noch gut handhabbar sein.
Taginfo lief am 29. und 30. nicht, und am 1. waren diese Tags in der Auswertung drinnen. In den daily diffs 325, 326 und 327 finde ich allerdings nichts. Auf der Taginfo-Seite kann man in der Tag-Liste nach filtern - das sind von den values her völlig unterschiedliche Dinge aus verschiedenen Ländern.
Die Diffs habe ich auch durchsucht und nichts gefunden. Auch mittels Overpass-Turbo finde ich keine Ergebnisse für z.B. “serv\u007fice”. Daher vermute ich, dass diese 7F erst nach dem Lesen der Diffs und vor dem / beim Zusammenbau dieser Liste für die Webseite hinzugekommen sind - also in unserer Datenbank nicht enthalten sind .
Edit:
Wenn ich das Zeichen %7F als ersten und einzigen Buchstaben bei Taginfo ins Suchfeld eingebe, bekomme ich die Liste aller Zeilen aus Beitrag #28, die mit dem %7F beginnen. Wenn ich nun einige Zeilen anklicke, bekomme ich in der Überschrift des neuen Tabs des Browsers die gleiche Anzahl an %7F, wie in der Liste.
Nun stellt sich die Frage, wie kommen wir an die IDs dieser Objekte, wenn Overpass-Turbo dieses Zeichen nicht verarbeitet?
In Australien habe ich zufällig auch eine Fläche (Insel) mit 3x %7F am Anfang des Keys und 2x %7F am Anfang des Values gefunden. (“source:description” als Suche in Overpass-Turbo (ohne die %7F am Anfang)).
Edit:
In Südamerika den loc_name mit 3x %7F am Anfang.
Node 3188718399 wird von der API mit dem %7F ausgeliefert. Laut Overpass zuletzt geändert am 29.03… Im daily diff vom 30.03. finde ich ihn aber nicht. Könnte also sein, dass sie bei Walter nicht auftauchen weil sie in den dailies gefiltert sind.
Edit: Jahreszahlen sollte man lesen können… 001/929.osc.gz hat ihn.
Ich gehe mal davon aus, dass es im kompletten planet-file drin ist, nur in den diffs gefiltert. Kann ich aber leider erst in ein paar Tagen verifizieren. Vielleicht findet sich ja noch jemand der vor kurzem seine DB neu eingespielt hat und die IDs liefern kann.
Ich hatte schon mal so einen Fall, dass in der Main DB irgendwelcher Müll drin war. Tom Hughes hatte das direkt in der Datenbank geputzt, und auch ungültige Zeichen für die Zukunft über einen Fix ausgeschlossen. Ältere Diffs werden dabei nicht mehr neu erzeugt.
Tom kann dann immer noch entscheiden, wie es weiter geht mit den 0x7f.
Ich weiß nicht genau, woher taginfo die Daten bezieht, würde aber auch mal tippen, dass die merkwürdigen Zeichen aktuell nur über einen Planet zur Verfügung gestellt werden.
Kurz zum Format der Auswertung: für jede Fundstelle - das sind Zeilennummern mit einem Doppelpunkt am Ende - werden die 10 vorausgehenden Zeilen mit ausgegeben. So hat z.B. Knoten 73931797 einen entsprechenden Wert mit 0x7f im name Tag.
In dieser Auswertung aus dem vorigen Beitrage habe ich etwa 20 Vorkommen angesehen und immer den Editor Potlatch 2 als Ursache finden können.
Kann es sein, dass, wenn man sich bei P2 vertippt hat und das falsche Zeichen löscht, ein 0x7F für jedes Betätigen der “Zurück”- oder “Entf”-Taste eingetragen wird? - Möglicherweise nur bei bestimmten Betriebssystemen (Win, Linux, Mac, …)?
Deshalb finde ich auch einen Fix bei P2 erforderlich!
Das sind Changeset (!) Tags die vom iD Editor gesetzt wurden. Sie sollen dokumentieren, ob sich ein Mapper mit der Mapping-Einführung beschäftigt hat. Sobald das Changeset geschlossen ist, können sie auch nicht mehr geändert oder gelöscht werden. Passt so und hat auch nicht wirklich was mit dem Thema in diesem Thread zu tun.
