JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

skyper · 2021-11-02 22:08:07

Es gab seit Jahren einen JOSM Bug, der Werte zerschossen hat ohne das die Benutzenden das direkt mitbekommen haben. Konkret wurde bei der Verwendung von Vorlagen mit mehreren Objekten gleichzeitig, die Werte von Schlüsseln mit unterschiedlichen Werten zerschossen. Beispiele sind https://taginfo.openstreetmap.org/tags/height=%3Cdiffer oder https://www.openstreetmap.org/api/0.6/way/197175790/5.
Jetzt, wo er endlich repariert ist, geht es wohl ans Aufräumen. Ist das ein Fall für MapRoulette oder was für andere Lösungen gibt es?

Es bedarf der Suche nach Werten welche ein "<" enthalten und dann sollte mit Hilfe der Objekthistorie der richtige Wert rausgesucht bzw. der Schlüssel ganz gelöscht werden.

SimonPoole · 2021-11-02 23:04:24

Denke zuerst ist es sinnvoll zu bestimmen wie viele Objekte überhaupt davon betroffen sind (ich nehme an eher wenig).

mmd · 2021-11-02 23:34:17

Um mal irgendeinen Wert in den Raum zu werfen, Overpass liefert 15630 Objekte, die Tags-Werte beginnend mit "<diff" haben. Davon 9197 Nodes, 6428 Ways, 5 Relationen.

Einer davon ist ein kaputter Import oder sowas in der Nähe von Port-au-Prince: https://www.openstreetmap.org/node/3850305054 (massenhaft Nodes mit source=<différent>,UAV,IOM,COSMHA,SIGHA)

Ein weiterer kaputter Import ist in Florida in der Nähe von https://www.openstreetmap.org/node/6034446103 - im Umkreis von ein 1-2km massenhaft Nodes mit "height=<differ". Gleiches Bild auch für Ways im Umkreis von 1-2km von https://www.openstreetmap.org/way/913967276 sowie https://www.openstreetmap.org/way/522420080

Last edited by mmd (2021-11-02 23:47:22)

skyper · 2021-11-03 00:37:39

mmd wrote:

Um mal irgendeinen Wert in den Raum zu werfen, Overpass liefert 15630 Objekte, die Tags-Werte beginnend mit "<diff" haben. Davon 9197 Nodes, 6428 Ways, 5 Relationen.

Das ist zumindest ein Zeichen zu viel, da es Vorlagen mit `length=4` gibt. Ich habe aber auch Übersetzungen von "<different>" und diese wiederum gekürzt gefunden, z.B. "<различ" oder "<unters". Zusätzlich bin ich mir nicht einmal sicher, ob es als ausschließlich als erster Wert vorkommen muss.

Mag sein, dass nicht alles direkt auf JOSM zurückzuführen ist, aber merkwürdig ist wohl "<" als Teil des Wertes bei fast allen Schlüsseln.
Spricht ja dann auch für eine Validator Regel, wobei für z.B. `height=*` haben wir ja schon eine und Menschen ignorieren halt auch Warnungen.

Last edited by skyper (2021-11-03 00:39:02)

mmd · 2021-11-03 08:00:40

* "<dif" mit vier Zeichen liefert mit 15729 nur unwesentlich mehr Objekte.
* "<dif" irgendwo mittendrin gibt es auch https://www.openstreetmap.org/way/129517100 - aber global nur 24 Objekte

* "<" irgendwo im Value: 101598 Objekte
* Value beginnt mit "<": 34250 Objekte

In den beiden letztgenannten Fällen ist doch einiges an Beifang dabei, wie capacity:persons=<50 oder irgendwelche URLs

"<many>" scheint es auch noch zu geben: https://www.openstreetmap.org/way/46087220/history
"addr:postcode" = <различные>" wurde schon genannt

Last edited by mmd (2021-11-03 08:01:26)

Cyber Alert Red · 2021-11-03 09:22:41

nhd:com_id<many> ist Absicht, es wurden wohl mehrere Ausgangswege mit unterschiedlichen com_ids zusammengefügt.

SimonPoole · 2021-11-03 09:25:42

mmd wrote:

....
Ein weiterer kaputter Import ist in Florida in der Nähe von https://www.openstreetmap.org/node/6034446103 - im Umkreis von ein 1-2km massenhaft Nodes mit "height=<differ". Gleiches Bild auch für Ways im Umkreis von 1-2km von https://www.openstreetmap.org/way/913967276 sowie https://www.openstreetmap.org/way/522420080

Das spricht wohl eigentlich gegen Maproulette, da das abarbeiten einzelner Objekte in Maproulette in solchen Fällen keinen Sinn macht.

SimonPoole · 2021-11-03 09:28:35

mmd wrote:

In den beiden letztgenannten Fällen ist doch einiges an Beifang dabei,...

conditional Werte können < und > beinhalten.

SimonPoole · 2021-11-03 09:59:30

PS: an die JOSM Entwickler: niemand ist vor Fehlern gefreit, und vor peinlichen erst recht nicht. Für das nächste Mal: als ihr den Fehler entdeckt habt, hättet ihr mit einer Meldung auf der talk Mailingliste und twitter, dass man bis auf weiteres multi-select mit Vorlagen nicht verwenden soll den Schaden vermutlich deutlich begrenzen können. Natürlich wäre auch eine Meldung auf dem Startfenster eine Möglichkeit gewesen.

Last edited by SimonPoole (2021-11-03 10:03:25)

mmd · 2021-11-03 11:56:34

Lustiger Beifang dabei. Mein neuer Favorit: traffic:hourly:* - Fussgängerzahlen pro Jahreszeit/Wochentag/Stunde auf einem footway: https://www.openstreetmap.org/way/206354052

Last edited by mmd (2021-11-03 11:58:16)

MKnight · 2021-11-03 12:37:45

mmd wrote:

Um mal irgendeinen Wert in den Raum zu werfen, Overpass liefert 15630 Objekte, die Tags-Werte beginnend mit "<diff" haben.

Magst Du die Abfrage mal teilen?

mmd · 2021-11-03 12:58:44

Die Query ist eigentlich so wie man das erwarten würde: https://overpass-turbo.eu/s/1cFv
Leider läuft das Ding auf der offiziellen Instanz zwischen 10-15 Minuten und generiert so recht viel Last.

skyper · 2021-11-03 17:44:18

SimonPoole wrote:

mmd wrote:
....
Ein weiterer kaputter Import ist in Florida in der Nähe von https://www.openstreetmap.org/node/6034446103 - im Umkreis von ein 1-2km massenhaft Nodes mit "height=<differ". Gleiches Bild auch für Ways im Umkreis von 1-2km von https://www.openstreetmap.org/way/913967276 sowie https://www.openstreetmap.org/way/522420080
Das spricht wohl eigentlich gegen Maproulette, da das abarbeiten einzelner Objekte in Maproulette in solchen Fällen keinen Sinn macht.

Gut die Imports sollten wohl "einfach" Revertet werden. Ich dachte wir könnten die Aufgabe aufteilen aber vielleicht sind andere Tools besser geeignet oder es finden sich ein paar Freiwillige.

SimonPoole wrote:

PS: an die JOSM Entwickler: niemand ist vor Fehlern gefreit, und vor peinlichen erst recht nicht. Für das nächste Mal: als ihr den Fehler entdeckt habt, hättet ihr mit einer Meldung auf der talk Mailingliste und twitter, dass man bis auf weiteres multi-select mit Vorlagen nicht verwenden soll den Schaden vermutlich deutlich begrenzen können. Natürlich wäre auch eine Meldung auf dem Startfenster eine Möglichkeit gewesen.

Ich weiß überhaupt nicht wieviel Entwickler (soviel ich weiß sind alle männlich, ansonsten sorry) hier mitlesen.
Hast Du mir bitte Zahlen darüber wie viele dieser Werte die letzten fünf Wochen beschädigt wurden.
Ich gebe Dir durch aus Recht, dass ein Hinweis über öffentliche Kommunikationskanäle bei einem lange vorkommenden Bug, Sinn macht. Allerdings sollte die Priorität bei besonders schweren Fehlern wohl verhindern, dass sie über Monate nach der genauer Erkenntnis darüber nicht repariert werden.
Stellst Du eigentlich diese Bedingungen an alle Editor-Software? Ich stelle mir es ja spannend vor, wenn iD über alle schwerwiegenderen Fehler warnt und nebenbei, habe ich von denen noch nicht einmal eine Stellungsnahme zum leidigen Thema PTv-Relationen in einem der Threads in dem Forum gefunden.

Persönlich, war ich der Meinung/Hoffnung, dass wir den Bug innerhalb von ein paar Wochen nach der Erkenntnis darüber behoben bekommen, aber dann gab es letzten Monat kein Update. Insgesamt, hatte ich die Hoffnung, dass es bei einem Bug, der seit Jahren vorhanden ist und nicht berichtet wird, ein paar Wochen keinen großen Unterschied mehr machen. Das war vielleicht naiv.

mmd wrote:

Lustiger Beifang dabei. Mein neuer Favorit: traffic:hourly:* - Fussgängerzahlen pro Jahreszeit/Wochentag/Stunde auf einem footway: https://www.openstreetmap.org/way/206354052

Und das hat sich seit Jahren nicht geändert?
Habe auch schon mitbekommen, wie Personen (1€-Job) mehrere Stunden lang Personen an einem Übergang zu ermitteln, um zu entscheiden welche baulichen Veränderungen angebracht sind. Aber ich glaube, dafür haben wir doch einen eigenen Thread.

Last edited by skyper (2021-11-03 17:47:13)

SimonPoole · 2021-11-03 19:57:53

skyper wrote:

...
SimonPoole wrote:
PS: an die JOSM Entwickler: niemand ist vor Fehlern gefreit, und vor peinlichen erst recht nicht. Für das nächste Mal: als ihr den Fehler entdeckt habt, hättet ihr mit einer Meldung auf der talk Mailingliste und twitter, dass man bis auf weiteres multi-select mit Vorlagen nicht verwenden soll den Schaden vermutlich deutlich begrenzen können. Natürlich wäre auch eine Meldung auf dem Startfenster eine Möglichkeit gewesen.
Ich weiß überhaupt nicht wieviel Entwickler (soviel ich weiß sind alle männlich, ansonsten sorry) hier mitlesen.
Hast Du mir bitte Zahlen darüber wie viele dieser Werte die letzten fünf Wochen beschädigt wurden.

Ich gebe Dir durch aus Recht, dass ein Hinweis über öffentliche Kommunikationskanäle bei einem lange vorkommenden Bug, Sinn macht. Allerdings sollte die Priorität bei besonders schweren Fehlern wohl verhindern, dass sie über Monate nach der genauer Erkenntnis darüber nicht repariert werden.
Stellst Du eigentlich diese Bedingungen an alle Editor-Software?

Ja, wenn es um Fehler geht die die Daten unabsichtlich beschädigen.

Ich stelle mir es ja spannend vor, wenn iD über alle schwerwiegenderen Fehler warnt und nebenbei, habe ich von denen noch nicht einmal eine Stellungsnahme zum leidigen Thema PTv-Relationen in einem der Threads in dem Forum gefunden.

Mal abgesehen davon, dass es kein "iD" gibt, da die Maintainerstelle bekanntlich verwaist ist, ja ich würde erwarten, dass es mindestens einen Hinweis gibt, dass es möglicherweise ein Problem gibt und man besonders sorgfältig sein sollte wenn man in Gebieten mit vielen ÖV-Routen editiert (meines Wissens hat noch niemand den Fehler nachvollziehbar nachgestellt).

Simon

skyper · 2021-11-03 21:10:00

SimonPoole wrote:

skyper wrote:
...
SimonPoole wrote:
PS: an die JOSM Entwickler: niemand ist vor Fehlern gefreit, und vor peinlichen erst recht nicht. Für das nächste Mal: als ihr den Fehler entdeckt habt, hättet ihr mit einer Meldung auf der talk Mailingliste und twitter, dass man bis auf weiteres multi-select mit Vorlagen nicht verwenden soll den Schaden vermutlich deutlich begrenzen können. Natürlich wäre auch eine Meldung auf dem Startfenster eine Möglichkeit gewesen.
Ich weiß überhaupt nicht wieviel Entwickler (soviel ich weiß sind alle männlich, ansonsten sorry) hier mitlesen.
Hast Du mir bitte Zahlen darüber wie viele dieser Werte die letzten fünf Wochen beschädigt wurden.
Ich gebe Dir durch aus Recht, dass ein Hinweis über öffentliche Kommunikationskanäle bei einem lange vorkommenden Bug, Sinn macht. Allerdings sollte die Priorität bei besonders schweren Fehlern wohl verhindern, dass sie über Monate nach der genauer Erkenntnis darüber nicht repariert werden.
Stellst Du eigentlich diese Bedingungen an alle Editor-Software?
Ja, wenn es um Fehler geht die die Daten unabsichtlich beschädigen.
Ich stelle mir es ja spannend vor, wenn iD über alle schwerwiegenderen Fehler warnt und nebenbei, habe ich von denen noch nicht einmal eine Stellungsnahme zum leidigen Thema PTv-Relationen in einem der Threads in dem Forum gefunden.
Mal abgesehen davon, dass es kein "iD" gibt, da die Maintainerstelle bekanntlich verwaist ist, ja ich würde erwarten, dass es mindestens einen Hinweis gibt, dass es möglicherweise ein Problem gibt und man besonders sorgfältig sein sollte wenn man in Gebieten mit vielen ÖV-Routen editiert (meines Wissens hat noch niemand den Fehler nachvollziehbar nachgestellt).
Simon

Es sind alle Routenrelationen betroffen inklusive TMC und detour. Es handelt sich dabei um zumindest einige Varianten oder mehrere Problem. Sorry, ich habe schon Stunden in JOSM investiert um zumindest mal die meisten Fehler in diesem Bereich zu finden. Vielleicht mögen sich ja von iD begeisterte Personen mal dann die Mühe machen hier ein bisschen OSM zu unterstützen und Fehleranalyse betreiben. Beispiele (CSs) kann ich gerne zu Verfügung stellen.

Mmh, JOSM hatte nie hauptamtliche Beschäftigte von daher sind wir hier immer auf Freiwillige angewiesen. Ich weiß jetzt nicht wer den Mist in iD verzapft hat, aber wenn es bezahlte Personen waren, macht das für mich schon einen Unterschied und wir können ja nicht Tomaten mit Auberginen vergleichen, oder?
Wenn Du einen Hinweis in JOSM haben willst, bearbeite doch einfach die Wikiseite. Ich persönlich würde mir beim JOSM-Wiki generell ein bisschen mehr Unterstützung wünschen, z.B. bei der deutsche Übersetzung.

Bevor ich jetzt noch weiter abschweife und Zeit mit leider eher mMn fruchtlosen Diskussionen verschwende. Finden wir eine Lösung hier sauber und effektive das Problem zu lösen? Mein Können + Zeit reichen leider nicht ganz so weit, aber ich kann natürlich anfangen, anstatt für JOSM 21.11 beizutragen.

Grüße skyper

skyper · 2021-11-04 22:42:43

mmd wrote:

Um mal irgendeinen Wert in den Raum zu werfen, Overpass liefert 15630 Objekte, die Tags-Werte beginnend mit "<diff" haben. Davon 9197 Nodes, 6428 Ways, 5 Relationen.
Einer davon ist ein kaputter Import oder sowas in der Nähe von Port-au-Prince: https://www.openstreetmap.org/node/3850305054 (massenhaft Nodes mit source=<différent>,UAV,IOM,COSMHA,SIGHA)
Ein weiterer kaputter Import ist in Florida in der Nähe von https://www.openstreetmap.org/node/6034446103 - im Umkreis von ein 1-2km massenhaft Nodes mit "height=<differ". Gleiches Bild auch für Ways im Umkreis von 1-2km von https://www.openstreetmap.org/way/913967276 sowie https://www.openstreetmap.org/way/522420080

Puh, diese Imports sollte ich jetzt bereinigt haben. Hab festgestellt, dass ich ein bisschen aus der Übung bekommen bin, was so große Reverts angeht. Wenn also ein bis viele Personen noch mal drüber schauen wollen, nur zu. Freue mich über Feedback.

Jetzt geht es wohl ans Kleinteiliger.

Hungerburg · 2021-11-05 11:59:29

Mach oft Änderungen an mehreren Dingen auf einmal, meist ohne Vorlage. Heute wieder, also mit Vorlage, und der Fehler tritt nicht auf, Version ist 18303.

In der Vorlage steht aber "<unterschiedlich>", nicht "<diff…" - findet man damit eventuell noch mehr?

mmd · 2021-11-05 12:10:21

Klar, der Text ist sprachabhängig, d.h. es gibt auch eine dt. Variante davon.
Beispiel: https://www.openstreetmap.org/changeset/87229242 sind z.B. die addr:suburb = <unterschiedlich>

skyper · 2021-11-05 15:12:46

Ja, die ganzen `addr:*=*` habe ich auch schon entdeckt und bin dabei sie zu korrigieren.
Das mit den sprachabhängigen Varianten hatte ich doch schon geschrieben. Spannend ist da z.B. <差異あり>

Leider bin ich immer noch am Tüfteln an einer anständigen Regex, die möglichst viele nur positiven Treffer findet, aber gleichzeitig die Api nicht so belastet. Bei einzeln Schlüsseln gibt es kein Problem den ganzen Planeten abzugrasen aber mir wären eigentlich kleinere Gebiete mit möglichst den meisten Problemen lieber.

Soweit kann ich nur sagen, das nach dem "<" noch drei Buchstaben kommen ohne Leerzeichen. Meist steht es am Anfang des Wertes, es muss aber nicht sein.

Last edited by skyper (2021-11-05 15:13:54)

mmd · 2021-11-05 15:30:44

https://www.openstreetmap.org/changeset/15870833 und https://www.openstreetmap.org/changeset/15881801 haben einiges mit 差異あり

Es gibt doch sicherlich irgendwo eine Liste mit allen Übersetzungen. Die kann man doch problemlos in einen Regex packen.

skyper · 2021-11-05 17:19:38

mmd wrote:

https://www.openstreetmap.org/changeset/15870833 und https://www.openstreetmap.org/changeset/15881801 haben einiges mit 差異あり
Es gibt doch sicherlich irgendwo eine Liste mit allen Übersetzungen. Die kann man doch problemlos in einen Regex packen.

Oh je, mit dem Übersetzungskram kenne ich mich überhaupt nicht aus. In den .lang Dateien ist ja nur jeweils die Übersetzung der jeweiligen Sprache. Bekomme ich von Launchpad eine Liste mit allen Übersetzungen eines einzigen Begriffs?

Performance mäßig, bin ich mir eh nicht schlüssig, ob es nicht schlauer ist nach "größer" + drei Zeichen, aber keine Zahlen, zu suchen und nicht mit einer Regex mit zig "und" oder "oder". Das filtere ich dann doch besser im zweiten Schritt.

Announcement

#1 2021-11-02 22:08:07

JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#2 2021-11-02 23:04:24

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#3 2021-11-02 23:34:17

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#4 2021-11-03 00:37:39

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#5 2021-11-03 08:00:40

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#6 2021-11-03 09:22:41

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#7 2021-11-03 09:25:42

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#8 2021-11-03 09:28:35

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#9 2021-11-03 09:59:30

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#10 2021-11-03 11:56:34

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#11 2021-11-03 12:37:45

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#12 2021-11-03 12:58:44

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#13 2021-11-03 17:44:18

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#14 2021-11-03 19:57:53

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#15 2021-11-03 21:10:00

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#16 2021-11-04 22:42:43

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#17 2021-11-05 11:59:29

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#18 2021-11-05 12:10:21

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#19 2021-11-05 15:12:46

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#20 2021-11-05 15:30:44

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

#21 2021-11-05 17:19:38

Re: JOSM Bug: Werte mit "<…" (MapRoulette-Aufgabe?)

Board footer