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

… See full entry

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.

… See full entry

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

… See full entry