Re: Daten in osm DB ändern?

Nahmd,

abrensch wrote:

Es ist ja eine Aenderung mit einem funktionalen Impakt. Alle Anwender haben ja irgendeinen Weg gefunden, damit umzugehen, die einen normalisieren, die anderen ignorieren solche Tags.

Was willst Du jetzt machen? Löschst Du persistent, dann triffst Du die ersten, mindestens mal in dem Sinne, dass Regressionstests Amok laufen. Und normalisiest Du persistent, dann trifft es die anderen.

Es ist natürlich nicht schön, dass diese zusätzliche Entropie in der Datenbank steckt, und es ist auch nicht schön, wenn ein Router was nimmt was der Renderer nicht malt oder umgekehrt. Aber es ist eben auch *Information*, weil der highway="service " mit Sicherheit weniger qualitätsgesichert ist als der highway="service", und Du solltest nicht sämtlichen OSM-Routern die Entscheidung abnehmen, die Anwender da drüber zu schicken.

Für mich steht an dieser Stelle der Erfasser im Vordergrund. Den halte ich für weder bösartig noch für doof (bei letzterem ist Kollege Woodpeck möglicherweise anderer Ansicht). Ich gehe davon aus, dass der Erfasser eine Zufahrtsstraße erfassen wollte und dass das Space aus Versehen ans Ende des Values gerutscht ist. Kombination aus menschlicher und technischischer Unzulänglichkeit. Taste berührt, Software führt keine Normalisierung durch, DB-Schnittstelle hat keine Abfrage, DB-Feld keine Constraints. Keine Absicht. Nur dumm gelaufen.

Mit wenig Aufwand kann man erreichen, dass die DB das enthält, was der Erfasser — und hier maße ich mir einfach mal an, das ahnen zu können — gewollt hat.

Dem Nutzer von qualitätsgesicherten Daten unterstelle ich mal, dass er weiß, dass die OSM-Datenbank dynamisch ist, dass er also auf die Möglichkeit von Änderungen in den Daten vorbereitet ist. Und anhand der Mtime erkennen kann: oops! Das wurde nach meinem letzten Check geändert, ist also nicht mehr qualitätsgesichert.

Ein unsinninges Blank zu entfernen ist etwas, was jeder normale Bearbeiter auch nebenbei tun würde. Damit muss jeder Nutzer der DB rechnen.

Toll fände ichs, wenn's sowas wie eine "common sense" Normalisierung gäbe, z.B. in Form einer Berechnungsvorschrift auf Basis von Regular Expressions, wo man davon ausgehen kann: ja, so machens die meisten, "oneway=true" wird gerendered, "oneway=ja" aber nicht. Hast Du sowas?

Letztes Jahr hab ich einen Freund, der sich ein wenig™ mit Datenbanktechnik auskennt, über dieses Thema unterhalten, und er hat mir skizziert, wie er das Problem angehen würde. Seitdem weiß ich, dass das Thema mindestens eine Nummer zu groß für mich ist. Ich verstehe die Lösung (nehme ich jedenfalls an), wäre aber nie selbst darauf gekommen. 🤔

Leider habe ich ihn nicht zu einer Mitarbeit bei OSM bewegen können. 🙁

Um Deine Frage zu beantworten: nein, habe ich nicht. Dafür bin ich definitiv nicht schlau genug.

Gruß Wolf