Ein Grundprinzip bei Datenbanken ist es, Redundanz der Daten zu vermeiden, daß heißt das die jeweiligen Daten nur einmal erfasst sind und nur einmal gepflegt werden müssen.

Die Datensammlung von OSM ist ja im Grunde genommen auch auch nur eine Datenbank. Trotzdem gibt es viele redundante Daten.

Ich finde das auch gut so. Das macht das Erfassen und das Verarbeiten vielfach einfacher.

Welche Fälle von Redudanz gibt es?

• Angrenzende Flächen Nutzen zwar die gleichen Nodes, allerdings gibt es zwei übereinanderliegende Ways. Oft ist es am einfachsten die Fläche als Ganzes zu zeichnen, als z.B. für jede Seite einzelne Wege zu erfassen und mit diesen ein Multipolygon zu bilden. Diese Variante ist zwar zulässig, macht es aber dem “Auswerter” also, z.B. dem Renderprogramm schwerer mit dieser Fläche zu arbeiten, da dieser diese auch erst aus den einzelnen Teilen “zusammenbauen” muß. Auch ein weiteres Bearbeiten wird hier unnötig erschwert.

• Adressen enthalten zum Großteil redudante Daten. Im Grunde müßte eine Adresse nur das enthalten, was sie von anderen unterscheidet und das ist im Normalfall die Hausnummer. Die Straßenzuordnung könnte man z.B. eine ‘assosiatedStreet’-Relation angeben. Orts-, Landes- und Postleitzahl-Informationen kann man aus den umgebenden Gebietsrelationen ziehen. Ich bevorzuge aber die Variante, bei der ich gleich alle Informationen in der Adresse gespeichert werden.

• Geschwindigkeitsbegrenzungen: Viele Mapper sind der Meinung das ein maxspeed=50 innerorts an einem Way sei überflüssig, da man die Information, ob eine Straße innerorts oder außerorts liegt, auch über entsprechende Auswertung hearsubekäme und dann nur noch in einer (externen) Tabelle nachschlagen muß, welche Geschwindigkeit in diesem Bereich für dieses Land gilt.

Diese Anwendungsbeispiele sind auch schon oft diskutiert worden und beide Lager sehen sich stets im Recht. Die Fraktion der Kontra-Redundanz hat oft einen starken EDV-Hintergund. Für sie ist es auch kein Problem im Handumdrehen entsprechende Abfragen zu programmieren, die Ihnen das gewünschte Ergebnis liefern. Aber wir sollten daran denken, daß bei OSM auch das KISS-Prinzip gilt. Die einfachste Lösung ist die beste und nicht die komplizierteste Lösung.

Es gibt oft Anfragen z.B. im Forum oder per Mail von Leuten, die unsere Daten nutzen wollen. Leider scheitert es oft aun der Komplexität. Wenn man z.B. Adressen auswerten möchte stößt man auf viele Probleme. Natürlich haben wir (nicht alle!) Adressen in OSM. Es geht schon damit los, daß man alle drei Datentypen (Node, Way, Relation) auswerten muss. Dann kommen solche Sachen wie die associatedStreet-Relationen die man auf einem anderen Wege auswerten muß. Vielleicht muß man sich die Informationen Orts-, Postleitzahl- und Landesinformationen noch über eine spatiale Abfrage aus den entsprechenden Grenzpolygonen besorgen. - Klar ist das technisch alles möglich, aber es halt nicht einfach, es ist (unnötig) kompliziert und entsprechende Abfragen dauern auch viel länger, als wenn man mit dem Objekt gleich alle Adressinformationen geliefert bekommt.

Es wird immer gesagt, daß die Daten doch korrekt seien und halt “nur” die Auswertung entsprechend angepaßt werden muß. Es gibt aber genügend Beispiele wo es etablierte Taggingschemata gibt, die auch nicht so kompliziert sind, aber trotzdem in der Praxis kaum ausgewertet werden. Das folgende Beispiel hat zwar nicht mit Redundanz zu tun, aber soll nur zeigen wie schwierig es in der Praxis sein kann, getaggte Informationen zu nutzen; so is mir keine Routinganwendung bekannt, welches nicht nur maxspeed, sondern auch das richtungsbezogene maxspeed:forward und maxspeed:backward nutzt.

Wir müssen aufpassen, daß wir nicht nur für unsere Datenbank mappen, sondern brauchbare und nutzbare Daten haben. Und zwar so, daß nicht nur ein paar Freaks die Daten nutzen können, sondern auch jemand der nicht GIS-Datenbank und OSM-Experte ist. Ansonsten ist das Mappen eine Sackgasse.

Es gibt eigentlich keinen vernünftigen Grund, warum wir auf Datenredundanz verzichten sollten. Die OSM-Datenbank hat kein Kapazitätsproblem und ein solches ist auch nicht in Sichtweite und Fehler können sowohl bei redundanten als auch bei nichtredundanten Daten vorkommen.

=> Macht es den anderen so einfach wie möglich.