OpenStreetMap

brogo's diary

Recent diary entries

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.

Ein Loblied auf FIXME

Posted by brogo on 3 April 2014 in German (Deutsch)

Die OSM-Notes sind eine gute Erfindung [1], damit Außenstehende schnell und unkompliziert Fehler melden oder Hinweise abgeben können.

Für interne Mappingnotizen finde ich sie aber für ungeeignet und sollten meiner Meinung nach, nicht für interne Meldungen genutzt werden. Ich benutze das gute, alte 'fixme'. Das hat folgende Gründe:

  • Die FIXMEs erscheinen direkt in jedem Editor, ohne daß man noch eine spezielle Ebene dazu schalten muß.
  • Wenn jeder interne Mappinghinweis die Notes verstopft, könnte für Externe der Eindruck entstehen, daß OSM entweder einfach zu viele "Fehler" enthält oder daß die Notes nicht abgearbeitet werden. Beides ist nicht wünschenswert.
  • Die FIXMEs lassen sich direkt mit jedem Renderer darstellen, ohne eine zweite Datenquelle nutzen zu müssen. So kann man sich schnell eine Karte basteln, in der die FIXMEs hervorgehoben sind und sie gezielt abarbeiten.
  • Jedes OSM-Tool kann auch FIXMEs verarbeiten.
  • Durch die Historie, läßt sich leicht derjenige ermitteln, der den FIXME eingetragen hat und man ihn wegen einer Rückfrage einfach anschreiben..
  • Da die FIXMEs beim normalen Editieren sichtbar sind, kann man nicht so leicht vergessen sie zu schliessen.

Daher kann ich die Nutzung von 'fixme' bzw. 'FIXME' nur dringend empfehlen. Doppeleintragungen sollten dringend vermieden werden.

[1] Auch wenn die "Erfindung" ja eigentlich durch die OpenStreetBugs gemacht wurde. Die Notes sind halt nur die Integration auf die Hauptseite.

10 Mappingtipps für Fortgeschrittene

Posted by brogo on 7 October 2013 in German (Deutsch)

oder: Wie ärgere ich meine Mitmapper

oder: Es gibt genügend Dumme, die hinter Dir aufräumen

1. Erfinde neue Tags

Mach Dir keine Mühe und sieh im Wiki oder auf Taginfo nach, wie etwas bisher gemappt wurde. Auch die Vorlagen in Deinem Editor kannst Du getrost ignorieren, die nutzen doch nur Anfänger. Nutze Deine Kreativität und schaffe was Neues. Gerne auch in Deiner Muttersprache.

2. Nutze etablierte Tags

Möchtest Du, daß etwas Bestimmtes in der Karte erscheint, dann sieh Dir an welche Tags wie gerendert werden. So kannst Du Dir die entsprechende Darstellung aussuchen. So wird z.B. ein Geschwindigkeitsblitzer schön dargestellt, wenn man 'tourism=attraction' dranhängt. Gern wird auch 'layer' benutzt um die Darstellung zu verändern, aber meistens bringt das nichts.

3. Benutze den Name-Tag

Wird etwas in der Mapnikkarte nicht dargestellt, schreibe es einfach in das Tag 'name' rein. Aktuell versucht Mapnik jeden 'name'-Eintrag zu rendern.

4. Ignoriere die Meldungen vom JOSM-Validator

Der JOSM-Validator wirft doch so viele Meldungen aus, die kann man doch nicht lesen; außerdem machst DU doch KEINE Fehler.

5. Benutze Multipolygone I

Flächen durch einen einfachen Weg darzustellen ist doch was für Loser. Benutze ausgiebig Multipolygone! Aus einem kleinen vier Punkte-Way kannst Du prima ein MP mit vier Outer-Ways basteln. Da blickt, außer Dir (?), bald keiner mehr durch.

6. Benutze Multipolygone II

Ist in Deiner Umgebung der Kartenhintergrund weiß? Dann trage einfach ein riesiges (100 km2 und mehr) Landuse-MP ein. Um guten Willen zu demonstrieren, kannst Du ja ruhig ein paar inner ways hinzufügen; aber nicht alle, das ist doch nur für Spießer. Mit etwas Glück wird das Ganze auch gerendert und bei Dir wird es schön bunt.

7. Benutze Multipolygone III

Fordere den Renderer heraus und trage die Tags nicht in das MP ein, sondern nur an die outer-ways; gerne auch unterschiedlich. Wozu haben wir denn so tolle Programme und teure Hardware?

8. Spare Nodes

Nodes zu sparen ist SEEHR wichtig. Im Februar 2013 gingen die 32-Bit-IDs für die Nodes zu Ende. Mit den neuen 64-Bit-IDs habe wir ja wohl doppelt so viele. Das wird doch schon bald wieder knapp. Also klebe möglichst viel an einen einzige Node. Der Klassiker sind highway und landuse, die sich gemeinsame Nodes teilen. Aber mach das doch auch mal Grenzen, dann traut sich keiner mehr, Deine Eintragungen zu verschieben. Falls sich jemand beschweren sollte, sage ihm, die Probleme kommen nur durch den Editor und wir mappen ja nicht für den Editor.

Bei den IDs habe ich wohl vertan. Wir haben doch noch etwas Luft. Denn mit jedem Bit verdoppelt sich ja die Anzahl. Also haben wir mit 32 zusätzlichen Bits 64 mal so viele IDs wie vorher. Aber bei dem rasanten Wachstum von OSM wird das sicherlich auch bald eng.

9. Spare Ways

Auch bei den Ways kannst Du sparen. Nutze doch einfach einen Weg für ein Linien- und Flächenobjekt gleichzeitig. So kannst Du prima an ein 'landuse' ein 'barrier' ranhängen. Das wird dann richtig lustig, wenn OSM mal einen Flächendatentyp bekommt.

10. Richte Dir eine Spielwiese ein

Wenn Du etwas austesten möchtest, mappe doch einfach irgendwo im Ozean, in der Wüste oder in den Polregionen. Die Welt ist so groß, da fällt es doch nicht auf, wenn Du Dir irgendwo eine kleine Fantasiewelt mappst.

P.S.

Die oben stehenden Tipps bitte nicht ernst nehmen. Das hier sind nicht nicht die typischen Anfängerfehler (wie z.B. unverbundene Wege). Alle Punkte habe ich schonbei langjährigen Mappern gesehen, die diese Fehler mehr oder weniger absichtlich gemacht haben. Das alles führt zu falschen oder schwer zu bearbeitenden Daten.

Older Entries | Newer Entries