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.
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)
Das ist zumindest ein Zeichen zu viel, da es Vorlagen mit length=4 gibt. Ich habe aber auch Übersetzungen von “” 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.
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.
Lustiger Beifang dabei. Mein neuer Favorit: traffic:hourly:* - Fussgängerzahlen pro Jahreszeit/Wochentag/Stunde auf einem footway: https://www.openstreetmap.org/way/206354052
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.
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.
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.
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.
Ja, wenn es um Fehler geht die die Daten unabsichtlich beschädigen.
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).
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.
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.
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 “”, nicht “<diff…” - findet man damit eventuell noch mehr?
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.
