Dein hidden iFrame ist verloren gegangen! Wenn ich auf das (J) in der rechten Spalte clicke, bekomme ich wieder eine neue Seite im Browser, in der nur OK steht. Auch im Quelltext finde ich keine Definition, was bei target=“hI” angezeigt werden soll.
Beim Hochladen sind anscheinend die letzten 15 kByte verloren gegangen, die Tabelle wird auch nicht richtig beendet im Code… Habe es nochmal manuell auf den Server geschoben und im Durchlauf morgen sollte es auch wieder / immer noch passen.
Da ist für mich auch die API gefragt - Keys abseits von a bis z, underscore und Doppelpunkt sind immer eine schlechte Idee (denn was nützen viele menschenlesbare Infos, die aber nicht automatisiert verwertbar sind?). Und allmählich dürften auch geügend Keys beisammen sein, so dass man darüber nachdenken darf neue Keys nur noch nach Diskussion und expliziter Aufnahme zu erlauben. Das mögliche Erfinden eigener Keys (und - je nach Key - auch der Values) war mal eine gute und notwendige Sache, mittlerweile ist das IMO unterm Strich aber kontraproduktiv. Leider.
Im Prinzip schon, siehe Wall-E.
Bei nur wenigen Einträgen sind die aber von Hand schneller beseitigt, als man braucht, um eine neue Regel zu erstellen und zu testen.
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.