Die A5 ist zerstört!

[Netzwolf]

Nahmd,

@Und Teufels Anwalt hob an und

@derstefan

Somit sind die rohen OSM-Daten generell unzuverlässig und erfordern für den professionellen Einsatz ein groß angelegtes Post-Processing.

Cui bono?

Die Ergebnisse aus diesem fließen natürlich nicht zurück in die OSM, sondern jeder macht’s ein Stück weit schlechter oder besser oder gar nicht.

Das ist korrekt.

Wünschenswert ist die Qualitätssicherung auf API-Ebene. Fehler in Datenstrukturen (Relationen, Multipolygone usw.) muss die API zurückweisen bzw. an andere Mapper in diesem Gebiet weiterleiten.

Wünschenswert — für wen?

Ich sehe bei OSM eine arbeitsteilige Struktur:

1. Da sind die Fleißarbeiter, die Objekt nach Objekt zusammentragen und die Datenbank füllen, dabei aber auch immer wieder Dinge kaputtmachen.

2. Es gibt diejenigen (Deppen?), die den ganzen Müll — ähh sorry, Müll darf ich es ja nicht nennen — die Datenelemente suboptimaler Qualität in der Datenbank suchen und korrigieren. Die teils unnötige Arbeit erbringen, denn viele Fehler wären technisch verhinderbar oder automatisch korrigierbar. Die aber selbst keinen Zugriff auf einen sauberen Datenbestand haben, alldieweil sie nicht wissen, an welchem anderen Ende der Welt wieder Müll, — ähh, sorry — Daten nicht optimaler Qualität™ — uff! — eingestellt worden sind. Und ihre Zeit in das Fixen der Fehler stecken statt in das Nutzen der Daten. Die also (etwas übertrieben ausgedrückt) nichts von ihrer Reparatur-Arbeit haben, sich also zum Deppen machen für:

3. (natürlich rein hypothetisch) diejenigen, die aus den OSM-Rohdaten Daten von zwar nicht garantierter, aber deutlich höherer — kommerzieller? — Qualität gewinnen, indem sie (natürlich an den Haaren herbeigezogene Beispiele) im Kleinen statt auf aktuelle, aber defekte Versionen von Objekten auf zwar veraltete, aber korrekte Versionen zurückgreifen oder im Großen massive Änderungen erst mit Verzögerung übernehmen im Vertrauen darauf, dass Schädigungen von den “Deppen” aus 2. kurzfristig repariert werden. Und das Ganze ist stabil wegen:

4. denjenigen, die sich einer technischen Durchsetzung auch nur minimaler Qualitätskriterien wie geschlossenen Polynomringen widersetzen, sie verschleppen, oder schon die Idee ins Lächerliche ziehen.

Darauf schwieg er.

Möglicherweise ist der Grund für die fehlenden auch nur minimalen Sicherungen gegen defekte Daten die Angst vor den Folgekosten: die Fehler landen nicht mehr bei den “Deppen”, sondern direkt über das User-Interface der Editoren bei den Eingebern und könnten diese verschrecken oder Nacharbeiten am iD nötig machen. Oder ganz simpel ein Mangel an Mitarbeitern bei den Betreuern der API. Letztere Hypothese ließe sich im Experiment testen, indem ein wirklich PostGIS-Kundiger sich um eine erste Implementierung bewirbt und man dann die Reaktion analysiert.

Gruß Wolf

Und jetzt: Popcorn!