+1
Und wenn man dann auch noch “variable Keys” - ein Widerspruch in sich - zulässt, wird es chaotisch.
Aber ich wiederhole mich
Gruss
walter
+1
Und wenn man dann auch noch “variable Keys” - ein Widerspruch in sich - zulässt, wird es chaotisch.
Aber ich wiederhole mich
Gruss
walter
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:
addr:%7Fcountry
addr:%7F%7F%7F%7F%7Fstate
admin_l%7Fevel
disused:%7F%7Frailway
disus%7Fed:railway
landuse%7F
serv%7Fice
s%7Fource:name
s%7Fo%7Furce
%7Faddr:full
%7Fdestination:ref
%7Fentrance
%7Fleisure
%7Fman_made
%7Fphone
%7Ftracktype
%7Fwikipedia
%7F%7F%7Falt_name
%7F%7F%7Floc_name
%7F%7F%7Fsource:description
%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7Fbuilding:levels
Wie komme ich zu den IDs, über die ich diese Objekte in JOSM öffnen und korrigieren kann?
Franz
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.
Bye
Frederik
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?
Franz
Und es gibt sie doch:
http://www.openstreetmap.org/node/3188718399
Gefunden über den bei Taginfo hinterlegten Wert und einer bbox auf Kiev.
Wurde schon vor einiger Zeit in die Datenbank hinzugefügt. Wahrscheinlich hat Taginfo die vorher nicht angezeigt und jetzt gab’s ein Softwareupdate.
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.
%7Fwikipedia ist hier.
%7Fdestination:ref ist hier.
Franz
Ich kann diese maroden Tags in meiner SQL-DB (Full Planet) auch nicht finden. Stimmt die Auswertung den wirklich?
Übrigens: HEX 7F ist das Ascii DEL - das wäre merkwürdig, wenn es das in die OSM-Rohdaten DB in UK geschafft hätte.
Gruss
walter
ps: nachher scanne ich mal meine Diffs, die habe ich ab 2015 online bei mir liegen.
In mehreren Beispielen kann ich den Editor Potlatch 2 als Quelle für diese %7F nachweisen.
Franz
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.
Ja, schon, aber in den diffs ist kein 0x7f drin:
gunzip -c 929.osc.gz | grep “3188718399” -A 10 | hexdump -C
00000000 20 20 20 20 3c 6e 6f 64 65 20 69 64 3d 22 33 31 | <node id="31|
00000010 38 38 37 31 38 33 39 39 22 20 76 65 72 73 69 6f |88718399" versio|
00000020 6e 3d 22 32 22 20 74 69 6d 65 73 74 61 6d 70 3d |n="2" timestamp=|
00000030 22 32 30 31 35 2d 30 33 2d 32 39 54 31 38 3a 30 |"2015-03-29T18:0|
00000040 31 3a 30 34 5a 22 20 75 69 64 3d 22 33 37 31 37 |1:04Z" uid="3717|
00000050 31 31 22 20 75 73 65 72 3d 22 6b 6e 6f 63 6b 70 |11" user="knockp|
00000060 65 6e 6e 79 22 20 63 68 61 6e 67 65 73 65 74 3d |enny" changeset=|
00000070 22 32 39 38 33 33 36 36 34 22 20 6c 61 74 3d 22 |"29833664" lat="|
00000080 35 30 2e 34 35 39 33 35 38 31 22 20 6c 6f 6e 3d |50.4593581" lon=|
00000090 22 33 30 2e 34 34 37 30 31 33 34 22 3e 0a 20 20 |"30.4470134">. |
000000a0 20 20 20 20 3c 74 61 67 20 6b 3d 22 61 6d 65 6e | <tag k="amen|
000000b0 69 74 79 22 20 76 3d 22 72 65 73 74 61 75 72 61 |ity" v="restaura|
000000c0 6e 74 22 2f 3e 0a 20 20 20 20 20 20 3c 74 61 67 |nt"/>. <tag|
000000d0 20 6b 3d 22 65 6d 61 69 6c 22 20 76 3d 22 62 61 | k="email" v="ba|
000000e0 67 72 61 74 69 2e 6b 69 65 76 40 79 61 6e 64 65 |grati.kiev@yande|
000000f0 78 2e 72 75 22 2f 3e 0a 20 20 20 20 20 20 3c 74 |x.ru"/>. <t|
00000100 61 67 20 6b 3d 22 6e 61 6d 65 22 20 76 3d 22 d0 |ag k="name" v=".|
00000110 91 d0 b0 d0 b3 d1 80 d0 b0 d1 82 d0 b8 22 2f 3e |............."/>|
00000120 0a 20 20 20 20 20 20 3c 74 61 67 20 6b 3d 22 6e |. <tag k="n|
00000130 61 6d 65 3a 72 75 22 20 76 3d 22 d0 91 d0 b0 d0 |ame:ru" v=".....|
00000140 b3 d1 80 d0 b0 d1 82 d0 b8 22 2f 3e 0a 20 20 20 |........."/>. |
00000150 20 20 20 3c 74 61 67 20 6b 3d 22 70 68 6f 6e 65 | <tag k="phone|
00000160 22 20 76 3d 22 2b 33 38 20 28 30 34 34 29 20 34 |" v="+38 (044) 4|
00000170 35 36 2d 33 35 2d 35 35 3b 2b 33 38 20 28 30 39 |56-35-55;+38 (09|
00000180 38 29 20 37 35 37 2d 38 35 2d 38 35 22 2f 3e 0a |8) 757-85-85"/>.|
00000190 20 20 20 20 20 20 3c 74 61 67 20 6b 3d 22 77 65 | <tag k="we|
000001a0 62 73 69 74 65 22 20 76 3d 22 68 74 74 70 3a 2f |bsite" v="http:/|
000001b0 2f 77 77 77 2e 62 61 67 72 61 74 69 2e 63 6f 6d |/www.bagrati.com|
000001c0 2e 75 61 2f 22 2f 3e 0a 20 20 20 20 3c 2f 6e 6f |.ua/"/>. </no|
000001d0 64 65 3e 0a 20 20 3c 2f 6d 6f 64 69 66 79 3e 0a |de>. </modify>.|
000001e0 20 20 3c 64 65 6c 65 74 65 3e 0a 20 20 20 20 3c | <delete>. <|
000001f0 6e 6f 64 65 20 69 64 3d 22 33 31 38 38 37 35 32 |node id="3188752|
00000200 39 30 39 22 20 76 65 72 73 69 6f 6e 3d 22 32 22 |909" version="2"|
00000210 20 74 69 6d 65 73 74 61 6d 70 3d 22 32 30 31 35 | timestamp="2015|
00000220 2d 30 33 2d 32 39 54 31 35 3a 34 35 3a 31 38 5a |-03-29T15:45:18Z|
00000230 22 20 75 69 64 3d 22 31 34 37 36 31 34 36 22 20 |" uid="1476146" |
00000240 75 73 65 72 3d 22 41 6c 65 63 73 30 31 22 20 63 |user="Alecs01" c|
00000250 68 61 6e 67 65 73 65 74 3d 22 32 39 38 32 37 37 |hangeset="298277|
00000260 33 36 22 20 6c 61 74 3d 22 34 35 2e 39 30 32 32 |36" lat="45.9022|
00000270 31 31 34 22 20 6c 6f 6e 3d 22 38 2e 37 31 36 35 |114" lon="8.7165|
00000280 36 34 32 22 2f 3e 0a |642"/>.|
Und in der DB auch net. Für mich ist das Thema erledigt.
Gruss
walter
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.
Am besten wäre es auch hier, ein Ticket aufzumachen: https://github.com/openstreetmap/openstreetmap-website/issues/
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.
Das ist mir auch schon beim übertragen aus Commons oder WIKI passiert.
http://commons.wikimedia.org/wiki/File:2016_Freital_Spielplatz_Marktstra%C3%9Fe.jpg
statt http://commons.wikimedia.org/wiki/File:2016_Freital_Spielplatz_Marktstraße.jpg
@geri-oc: das ist nicht schlimm…
Hier geht’s um ein Lösch-Steuerzeichen, das da nicht so wirklich hingehört. Zur Verdeutlichung auf dem Screenshot gelb markiert:
Sieht man in Firefox übrigens unter http://www.openstreetmap.org/api/0.6/node/3188718399
Lt. aktuellem Planet gibt es etwa 1200 Fundstellen mit 0x7f irgendwo in den Tags:
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!
Franz