Ich finde es ja immer toll, wenn man hört, daß OSM bzw. darauf basierende Projekte finanziell unterstüzt werden. Ich habe da mal ein paar Zahlen rausgesucht:

• Wheelmap 825.000 €, Spende von Google, April 2016
• Mapbox 575.000 $, Spende von Knight Foundation, September 2012
• HOT Einnahmen 2011, 281.050 $
• HOT Einnahmen 2012, 428.225 $
• HOT Einnahmen 2013, 768.642 $
• HOT Einnahmen 2014, 732.994 $

Die Finanzen der OpenStreetMap-Foundation (OSMF), die ja die Hauptserver betreibt, sehen dagegen mickerig aus.

• OSMF Spendenaktion Juni 2016: 56.000 £
• OSMF Budget 2016: 57.000 £

Es ist schade, daß das Hauptprojekt so wenig Beachtung findet. Allerdings erhält die OSMF Sachleistungen, wie z.B. das freie Housing und Hosting.

Auch im Vergleich zu anderen Open-Source-Projekten sieht die OSMF ziemlich klein aus. Dazu muß man gar nicht die große Wikimedia nehmen. Die Open Knowledge Foundation Deutschland (OKF) weist zum Beispiel für 2014 Einnahmen von 415.000 € aus und beschäftigt 10 Teilzeitmitarbeiter.

Wenn ich sehe, wofür im öffentlichen Bereich überall Fördertöpfe bereitstehen und was damit alles gefördert wird (selbst der Umbau des Spielplatz “unseres” Kindergartens wurde mit einem 5-stelligen Betrag aus EU-Mitteln bezuschusst) , frage ich mich, warum die OSMF finanziell nicht viel besser aufgestellt ist? Was bringt es Mapbox, wenn das OSM-Projekt kaputt ist, wie will HOT weitermachen, wenn das Mutterprojekt nicht ordentlich weitergeführt wird?

Daten zu erfassen ist (relativ) einfach. Sie aktuell zu halten ist weitaus schwieriger.

Wenn man auf einer Karte etwas nicht sieht, weiß man, hier fehlt was. Dann kann man dort hinfahren und das Fehlende mappen. Wenn die Karte vollständig aussieht, merkt keiner so schnell, wenn was fehlt. Große Bauprojekte beobachten viele OSMler gespannt und sind auf eifrig dabei, sie zeitnah zu erfassen. Wenn irgendwo ein Einfamilienhaus abgerissen und neugebaut wird, merkt das nicht sofort ein Mapper, es sei denn er kommt dort regelmäßig vorbei. Wenn ein Restaurant schließt oder ein Briefkasten neue Leerungszeiten hat, ist das nicht auf die Schnelle zu erkennen und auch nicht mit OSM abzugleichen. Man muß schon direkt in die OSM-Rohdaten schauen und abgleichen.

Eine Auswertung [1] von Jan (User Lübeck) hat mich ein wenig erschreckt. Dort hat er alle Telefonzellen abgefragt. Und wenn man die Realität mit der Karte vergleicht, wird man feststellen, daß sehr viele Telefonzellen mittlerweile abgebaut sind, in OSM aber noch existieren. Deswegen haben wir uns vom Lübecker Stammtisch schon vor längerer Zeit das Tag ‘lastcheck’ in Benutzung, welches angibt, wann das Objekt zuletzt von einem Mapper überprüft wurde. Ich war anfänglich auch nicht begeistert und fand es nicht sinnvoll. Die oben genannte Auswertung zeigt aber sehr schön, wie sich die Aktualität eines OSM-Objektes so leicht visualisieren läßt. Alle grünen Punkte sind Telefonzellen, die im letzten Jahr überprüft wurden. Rote Punkte haben kein lastcheck. Die anderen Farben bedeuten, daß der POI in den anderen Jahren zuletzt gecheckt wurde.

Deshalb setze ich jetzt auch immer ‘lastcheck’ ein. lastcheck wird in Form YYYY-MM-DD gemappt. Also z.B. lastcheck=2015-08-20

Manche sagen, daß solche Metadaten nicht in die OSM-Datenbank gehören. Wohin dann? Es sind ja nicht nur Infos für mich, es sind Infos für jeden Mapper. Sollte man deswegen eine zweite Datenbank aufmachen? Ich denke nicht. Wir haben doch sowieso schon immer solche Metadaten drin. So hängt zum Beispiel an jedem Objekt der Username, die Uhrzeit und das Changeset. Seit eh und je benutzen wir ‘FIXME’ und ‘note’, um anderen Mappern Infos zu hinterlassen. lastcheck ist da nichts anderes.

Das Änderungsdatum eines Objektes ist da nicht unbedingt aussagekräftig. Das Objekt kann schon seit vielen Jahren korrekt gemappt worden sein und ist immer noch aktuell. Oder wenn ein Mapper einen veralteten POI etwas verschiebt, hat dieser nun ein aktuelles Änderungsdatum.

Gerade im Bereich der POIs findet sehr viel Veränderung statt. Da ist es schwer, diese aktuell zu halten. lastcheck gibt einem einen Hinweis, wo man vielleicht mal genauer hinsehen sollte. Denn damit OpenStreetMap attraktiv bleibt, brauchen wir aktuelle Daten von POIs.

[1] http://overpass-turbo.eu/s/9eR

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.

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.

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.