OpenStreetMap

Redundanz bei OSM-Daten

Posted by brogo on 22 May 2014 in German (Deutsch)

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.

Comment from karussell on 22 May 2014 at 15:00

so is mir keine Routinganwendung bekannt, welches nicht nur maxspeed, sondern auch das richtungsbezogene maxspeed:forward und maxspeed:backward nutzt.

https://github.com/graphhopper/graphhopper/blob/master/core/src/main/java/com/graphhopper/routing/util/AbstractFlagEncoder.java#L314

Sorry da konnte ich nicht wiederstehen ;)

Hide this comment

Comment from kusmi on 22 May 2014 at 15:52

@karussell Wahrscheinlich (sogar sehr wahrscheinlich ;-) versteh ich den Code nicht ganz, aber Du nimmst dort immer den kleineren Wert von forward-speed und backward-speed, d.h. ich sehe dort jetzt nicht wie die Richtungsabhängigkeit reinkommt?

D.h. ich habe einen way mit - maxspeed: nicht definiert - forward-speed: 50 km/h - backward-speed: 30 km/h

die Routine getMaxSpeed() gibt in jedem Fall 30 km/h zurück, auch wenn in der anderen Richtung eigentlich 50 gefahren werden könnte.

Hide this comment

Comment from imagico on 22 May 2014 at 15:55

Das Vermeiden von Redundanzen dient nicht nur der Effizienzsteigerung. Das größte Problem ist vielmehr, dass Redundanzen meist zwangsläufig zu Widersprüchen führen, denn die verschiedenen Versionen der selben Information müssten permanent von irgendjemandem synchronisiert werden, was nicht passiert.

Bestes und beim Betrachten der Karte offensichtlichstes Beispiel finde ich immer die maritimen Grenzen (i.a. also die 12-Meilen-Zone), welche explizit gemappt wird, obwohl sie eigentlich eine berechnete Linie darstellt (berechenbar auf Grundlage der Basislinie, welche meist nicht durchgehend erfasst ist). In der Praxis führt dies dazu, dass die gemappte Grenze oft im Widerspruch zum Rest der Karte steht (sie müsste sich definitionsgemäß immer mindestens 12 Meilen vor der Küstenlinie befinden).

Der Grund, trotzdem diese Grenze zu erfassen ist klar, denn es ist ein praktischer und einfacher Weg, die Grenze eines Landes zu schließen und es ist gleichzeitig die Linie, die man in der Karte darstellen möchte. Der wesentlich sauberere Weg wäre hier jedoch, für alle Anwendungen, die dies benötigen, diese Grenze aus den anderen Informationen in der Datenbank zu berechnen. Zu fordern, dass solche Informationen aus Komfortgründen für den Auswerter in der Haupt-OSM-Datenbank liegen müssen (was die automatische Aktualisierung ja wirkungsvoll verhindert) halte ich für problematisch.

Hide this comment

Comment from cm8 on 22 May 2014 at 16:46

Die einfachste Lösung ist bei weitem nicht immer die beste. Ein krasses Beispiel: Überbevölkerung wäre am einfachsten dadurch zu lösen, indem man zum einen Menschen vernichtet und zum anderen die Fortpflanzung verbietet, bzw. verhindert. Gemessen an der Kreativität und dem Potential, das in jedem von uns steckt, ist aber ausnahmslos jedes Leben lebens- und schützenswert. Zudem hatten wir in der Geschichte schon Perioden, wo diese vermeintlich "einfachsten" Lösungen praktiziert wurden. Die besten waren es mit Sicherheit nicht.

Kurzum: Deine Abneigung gegen Freaks ist rein subjektiv und nicht rational zu begründen. Die Komplexität, die hinter OSM steht, macht das Projekt überhaupt möglich - mit einer Excel-Tabelle lassen sich auch geographische Daten "einfachst" erfassen. Die beste Lösung ist das aber mitnichten.

Es ist nicht verkehrt, wenn EDV-affine Leute ihre Meinung zum besten geben. Die beste Lösung entsteht, wenn sich beide Seiten einig werden. Genau dann ist die Lösung tragfähig und bringt den maximalen Nutzen für die größte Nutzerbasis.

Deine Beschwerde ist ein technisches Problem: Du schreibst, dass du Probleme hast "mal eben eine Abfrage zu schreiben". Hast Du dir schonmal overpass-turbo.eu angeschaut oder die umfangreichen Arbeiten zum Thema Overpass-API von Roland Olbricht? Das ist alles dokumentiert und erlernbar und wenn man es einmal verstanden hat, macht es auch mehr Sinn, als wenn man sich dem Thema "automatisiertes Auswerten" verschließt.

Die einfachste Lösung ist "Bleistift und Papier", aber es ist mit Sicherheit nicht die beste, schon gar nicht, wenn betrachtet wird, wieviel Anwendungsfälle mit der Datensammlung von OSM bedient werden können.

Gruß

Hide this comment

Comment from 4rch on 23 May 2014 at 10:07

Das Beispiel mit der 12-Meilen-Zone finde ich schlecht gewählt. Zum einen gibt es "gerade Basislinien" an Flussmündungen, Buchten usw. und die "archipelagic baselines", die die 12-Meilen-Zone verändern. Dann gibt es Vereinbarungen zwischen Staaten, die die 12-Meilen-Zone beeinflussen und es gibt Staaten die weniger oder mehr als 12 Meilen beanspruchen. Dann gibt es z.B. auch noch die umstrittene Seegrenze der Philippinen die komplett auf Koordinaten beruht. Um das Einzeichnen der 12-Meilen-Grenze kommt man also nicht drumrum, es gibt einfach zu viele Faktoren die diese beeinflussen und diese Faktoren sind auch nicht immer (so einfach) berechenbar.

Hide this comment

Comment from imagico on 23 May 2014 at 14:11

@4rch - ich sehe nicht, dass das Argument 'die Berechnung ist kompliziert' etwas an der Situation ändert, nämlich dass die redundante Erfassung von Informationen zwangsläufig zu Widersprüchen in den Daten führt.

Dass es auch im maritimen Bereich Grenzen gibt, die nicht durch Distanz von einer Basislinie definiert sind, sondern durch bilaterale Abkommen oder anderweitig definierte unilaterale Ansprüche ändert eigentlich auch nichts - solche explitzit definierten Grenzen sollten natürlich immer auch explizit erfasst werden und hier besteht keine Gefahr der Redundanz oder Widersprüchlichkeit - außer natürlich bei Konflikten zwischen verschiedenen Ansprüchen, was aber ein anderes Thema ist.

Indem man die redundante Erfassung als alternativlos deklariert (was brogo explizit nicht getan hat) macht man sich die Sache zu einfach. Man sollte sich immer klar machen, dass man sich durch eine solche Entscheidung auch große und im gewählten Beispiel eben auch sehr deutlich in der Karte sichtbare Nachteile einhandelt.

Kurz - redundante Erfassung von Informationen ist niemals zwingend notwendig und es gibt wie erläutert durch durchaus gute prinzipielle Gründe, so etwas zu vermeiden. Dass man dennoch zu dem Schluss kommen kann, Dinge trotz der Nachteile redundant zu erfassen, will ich dabei garnicht bestreiten.

Hide this comment

Comment from brogo on 26 May 2014 at 10:03

@cm8 Dein erstes Beispiel ist leider völlig daneben.

Ich weiß nicht wie Du dazu kommst, ich hätte etwas gegen Freaks? Der Begriff "Freak" ist für mich übrigens positiv besetzt. Für mich sind das Leute mit außergewöhnlichem Spezialwissen. Ich weiß auch daß die OSM-Community ein bunt gemischter Haufen ist. Jedes Mitglied hat einen anderen beruflichen/fachlichen Hintergrund und unterschiedliche Fähigkeiten. Und es es gut wenn jedes Mitglied seinen Beitrag leistet und sich einbringt. Ich sehe nur die Gefahr, daß OSM sich insgesamt zu verkompliziert. Das führt denn auch dazu daß sich nur wenige Leute Spezialthemen wie ÖPNV oder 3D widmen. Die breite Masse hält sich daraus. Wenn man dann aber einfache Themen verkompliziert z.B. das Eintragen von Adressen mittles associatedStreet-Relationen wird man hier auch nach und nach Mapper verlieren. Man kann sich natürlich hinstellen und sagen: "Das ist doch nur eine Frage des Editors". Aber fakt ist: Wir HABEN keinen Editor bei dem der Mapper einfach die Adresse einträgt, und eine bereits vorhandene associatedStreet-Relation ergänzt oder gegebenenfalls eine neue angelegt wird.

Auf der Seite der (potentiellen) Datennutzer gibt es auch keine Tools, die "mal eben" die entsprechenden Informationen zusammen sammeln.

Für mich gehört zu "Freiem Wissen", was ja OSM schaffen will, auch dazu, daß das Wissen von einer breiten Massen (mit einer gewissen Vorbildung) zur Verfügung steht und nicht so wie im Mittelalter, als die Bücher alle in Latein geschrieben waren, nur von einer kleinen Elite genutzt werden können.

Aufgabe: Ich suche ein Restaurant innerhalb einer bestimmten Boundingbox. Suche mir dazu die vollständige Anschrift raus (POI ist innerhalb eines Gebäudes, welches die Hausnummer trägt und Mitglied einer associatedStreet-Relation ist. Diese enthält nur den Straßennamen. Postleitzahl, Ortsname und Land sind über die umgebenden boundardy-Polygonen zu ermitteln.

Wer kriegt es hin? Die Wahl der Mittel ist frei.

Die Lösung sollte auf jeden Fall im Wiki dokumentiert werden.

Die Overpass-API kenne ich - Ein Tool welches OSM unheimlich nach vorne gebracht hat, nachdem die XAPI-Server jahrelang überlastet waren und nur Wenige ihre eigene Datenbank aufsetzen wollten/konnten. Und Overpass-Turbo hielt ich zunächst nur für Spielkram, ist aber klasse, daß man gleich die grafische Auswertung bekommt.

Hide this comment

Comment from mdk on 28 May 2014 at 17:53

@brogo: Bei der Komplexität von Adress-Abfrage darfst du die Adressinterpolationen nicht vergessen :-)

@imagico: Als Informatiker muss ich dir zustimmen: Redundanz deckt Fehler auf (oder meinst du, dass Daten ohne Redundanz immer korrekt sind?) Im Falle von OSM, wo die Daten eben gerade nicht 100% korrekt sind (unvollständig, veraltet, fehlerhaft erfasst, ...), sind diese Redundanzen in meinen Augen wertvoll. Dienste wie keep right!, OSMInspector und andere funktionieren nur dank dieser Redundanzen!

Hide this comment

Comment from Rudolf_H on 31 May 2014 at 20:44

@brogo: Ich verstehe dein Anliegen, stimme dir auch in Manchem zu, bloß - die Tücke steckt im Detail. Wie ein früherer österreichischer Bundeskanzler meinte: "Es ist alles recht kompliziert".

Es gibt einige Situationen, die lassen sich im Sinne deines "KISS" Anliegens gut lösen, wenn Redundanz gegeben ist, vor allem in diesen Fällen, wo Attribute zwangsläufig fuzzy, unscharf sind oder über die Zeit nicht stabil. Und ich selbst wende (unnötige) Abstraktionen (zB komplexe Multipolygone, Relationen/Master-Relationen) sehr restriktiv an.

Aber genau dann wieder trifft auch das genaue Gegenteil zu. Um als erstes Beispiel deines der Adressen aufzugreifen: In einigen Bundesländern Österreichs gab es (und wird es noch geben) Zusammenlegungen von Bezirken (etwa vergleichbar den DE-"Kreisen"). Tausende, eher zehntausende Objekte, etwa die, die mit vollen (redundanten) Adress-Details getaggt, sind schlagartig falsch (vor allem dort, wo noch üppig mit "is_in" getaggt wird). Oder, in Zeiten der Privatisierungen: Der Betreiber einer komplexen, räumlich stark ausgedehnten Objekt-Struktur ändert sich (etwa Stromleitungsnetz, Verkehrsnetz, und zig andere). Beispiel: Bahn Regio-Verkehr München-Rosenheim-Salzburg/Kufstein. Wie schön, wenn man nur die Relation mit dem Betreiber (und dessen Attribute nur dort) getaggt hat/hätte. Und welch ein Horror, wenn man für tausende kurze Stücke den operator retaggen muß. In diesen Fällen droht schlagartig ein sehr unattraktives OSM. Solche Fälle gibt es leider in Österreich (und bin überzeugt, auch in DE) sehr viele. Und das lässt sich nicht so einfach mit einem nächtlichen bot-Lauf korrigieren. Den muss auch erst jemand (sehr gut!) schreiben, ansonsten droht noch größeres Chaos (hatten wir hierzulande schon...)

Bei einer öffentlichen Veranstaltung mit OSM-Stand kürzlich in Wien habe ich mit vielen Menschen unterschiedlicher Involviertheit in OSM gesprochen. Die meisten (auch Gelegenheits-) BenutzerInnen meinten: Viel schlimmer als "nicht vorhanden" oder unscharf sind falsche/veraltete Angaben. Und diese entstehen nicht selten genau durch diese Redundanzen und "over-tagging", vor allem wenn Urheber nicht eine gewisse längerfristige Pflegebereitschaft für "ihre" Objekte zeigen. Dieses längerfristige commitment finde ich zB wesentlich wichtiger als forcierte "Simplizität". Ohne manche Komplexitäten, die zugegebenrmaßen eine gewisse Einarbeitungszeit und die Kenntnis im Umgang des Werkzeugkastens erfordern, gehts auch nicht.

Ich glaube nicht, dass in Zentraleuropa das Mappen bald in einer Sackgasse enden wird, da gibt es genügend Heterogenität beim Level der Beitragenden und "für jeden etwas" zu tun. Ein OSM Problem liegt eher in den vielen nicht so besiedelten Gegenden der Erde.

Hide this comment

Comment from chattiewoman on 21 June 2014 at 11:42

so is mir keine Routinganwendung bekannt, welches nicht nur maxspeed, sondern auch das richtungsbezogene maxspeed:forward und maxspeed:backward nutzt.

Der Mapfactor Navigator kann das ebenfalls (Android, Windows).

Hide this comment

Leave a comment

Parsed with Markdown

  • Headings

    # Heading
    ## Subheading

  • Unordered list

    * First item
    * Second item

  • Ordered list

    1. First item
    2. Second item

  • Link

    [Text](URL)
  • Image

    ![Alt text](URL)

Login to leave a comment