You are not logged in.

Announcement

*** NOTICE: forum.openstreetmap.org is being retired. Please request a category for your community in the new ones as soon as possible using this process, which will allow you to propose your community moderators.
Please create new topics on the new site at community.openstreetmap.org. We expect the migration of data will take a few weeks, you can follow its progress here.***

#26 2016-01-16 10:36:30

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,769
Website

Re: Neue Keys in der Datenbank - meistens falsch

Joachim Moskalewski wrote:

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.

+1

Und wenn man dann auch noch "variable Keys" - ein Widerspruch in  sich - zulässt, wird es chaotisch.

Aber ich wiederhole mich mad

Gruss
walter

Last edited by wambacher (2016-01-16 10:37:35)

Offline

#27 2016-01-16 11:23:08

seichter
Member
Registered: 2011-05-21
Posts: 3,336

Re: Neue Keys in der Datenbank - meistens falsch

geri-oc wrote:

Viele sind aber auch schnell wieder weg (Schreibfehler) - geht das nicht eigentlich automatisch?
biuilding -> building

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.

Offline

#28 2016-05-01 22:22:28

FvGordon
Member
Registered: 2009-08-29
Posts: 726

Re: Neue Keys in der Datenbank - meistens falsch

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

Offline

#29 2016-05-01 23:09:02

woodpeck
Member
Registered: 2009-12-02
Posts: 1,210

Re: Neue Keys in der Datenbank - meistens falsch

FvGordon wrote:

Wie komme ich zu den IDs, über die ich diese Objekte in JOSM öffnen und korrigieren kann?

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

Offline

#30 2016-05-02 20:47:02

mueschel
Member
Registered: 2012-06-11
Posts: 1,181
Website

Re: Neue Keys in der Datenbank - meistens falsch

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.

Offline

#31 2016-05-02 21:17:02

FvGordon
Member
Registered: 2009-08-29
Posts: 726

Re: Neue Keys in der Datenbank - meistens falsch

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

Last edited by FvGordon (2016-05-02 21:32:47)

Offline

#32 2016-05-02 21:34:36

mueschel
Member
Registered: 2012-06-11
Posts: 1,181
Website

Re: Neue Keys in der Datenbank - meistens falsch

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.

Last edited by mueschel (2016-05-02 21:42:17)

Offline

#33 2016-05-02 21:58:24

FvGordon
Member
Registered: 2009-08-29
Posts: 726

Re: Neue Keys in der Datenbank - meistens falsch

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

Last edited by FvGordon (2016-05-02 22:22:57)

Offline

#34 2016-05-02 22:11:58

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,769
Website

Re: Neue Keys in der Datenbank - meistens falsch

FvGordon wrote:

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 .

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.

Last edited by wambacher (2016-05-02 22:13:02)

Offline

#35 2016-05-02 22:28:12

FvGordon
Member
Registered: 2009-08-29
Posts: 726

Re: Neue Keys in der Datenbank - meistens falsch

In mehreren Beispielen kann ich den Editor Potlatch 2 als Quelle für diese %7F nachweisen.

Franz

Offline

#36 2016-05-02 22:29:24

mueschel
Member
Registered: 2012-06-11
Posts: 1,181
Website

Re: Neue Keys in der Datenbank - meistens falsch

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.

Last edited by mueschel (2016-05-02 22:37:02)

Offline

#37 2016-05-02 22:39:56

mmd
Member
Registered: 2010-11-06
Posts: 2,150

Re: Neue Keys in der Datenbank - meistens falsch

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"/>.|

Last edited by mmd (2016-05-02 22:40:37)

Offline

#38 2016-05-02 23:15:21

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,769
Website

Re: Neue Keys in der Datenbank - meistens falsch

mmd wrote:

Ja, schon, aber in den diffs ist kein 0x7f drin:

Und in der DB auch net. Für mich ist das Thema erledigt.

Gruss
walter

Last edited by wambacher (2016-05-02 23:15:36)

Offline

#39 2016-05-02 23:58:41

mueschel
Member
Registered: 2012-06-11
Posts: 1,181
Website

Re: Neue Keys in der Datenbank - meistens falsch

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.

Offline

#40 2016-05-03 08:42:54

mmd
Member
Registered: 2010-11-06
Posts: 2,150

Re: Neue Keys in der Datenbank - meistens falsch

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/openst … te/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.

Last edited by mmd (2016-05-03 09:43:25)

Offline

#41 2016-05-03 09:02:27

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 5,055
Website

Re: Neue Keys in der Datenbank - meistens falsch

Das ist mir auch schon beim übertragen aus Commons oder WIKI passiert.

http://commons.wikimedia.org/wiki/File: … C3%9Fe.jpg

statt http://commons.wikimedia.org/wiki/File: … straße.jpg

Offline

#42 2016-05-03 09:34:25

mmd
Member
Registered: 2010-11-06
Posts: 2,150

Re: Neue Keys in der Datenbank - meistens falsch

@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:

25415811ta.png

Sieht man in Firefox übrigens unter http://www.openstreetmap.org/api/0.6/node/3188718399

Last edited by mmd (2016-05-03 09:41:21)

Offline

#43 2016-05-03 19:02:14

mmd
Member
Registered: 2010-11-06
Posts: 2,150

Re: Neue Keys in der Datenbank - meistens falsch

Offline

#44 2016-05-06 08:52:13

mmd
Member
Registered: 2010-11-06
Posts: 2,150

Re: Neue Keys in der Datenbank - meistens falsch

Lt. aktuellem Planet gibt es etwa 1200 Fundstellen mit 0x7f irgendwo in den Tags:

Link zur Auswertung

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.

Last edited by mmd (2016-05-06 09:54:47)

Offline

#45 2016-05-06 11:34:26

FvGordon
Member
Registered: 2009-08-29
Posts: 726

Re: Neue Keys in der Datenbank - meistens falsch

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

Offline

#46 2018-06-23 08:26:26

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 5,055
Website

Re: Neue Keys in der Datenbank - meistens falsch

ideditor:walkthrough_completed=yes
ideditor:walkthrough_progress=welcome;navigation;point;area;line;building;startEditing
ideditor:walkthrough_started=yes

Sollte das gelöscht werden? Ich kann keinen Sinn erkennen: https://www.openstreetmap.org/changeset/59691406

Offline

#47 2018-06-23 09:08:47

mmd
Member
Registered: 2010-11-06
Posts: 2,150

Re: Neue Keys in der Datenbank - meistens falsch

geri-oc wrote:

ideditor:walkthrough_completed=yes
ideditor:walkthrough_progress=welcome;navigation;point;area;line;building;startEditing
ideditor:walkthrough_started=yes

Sollte das gelöscht werden? Ich kann keinen Sinn erkennen: https://www.openstreetmap.org/changeset/59691406

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.

Last edited by mmd (2018-06-23 09:12:26)

Offline

Board footer

Powered by FluxBB