Osmand hat mit seiner neuesten Osmand-Version ein neues Feature eingeführt, welches bis zu stündliche Updates des Kartenmaterial einführt:

• http://osmand.net/osm_live.php#information
• http://osmand.net/blog

Ich habe mir gleich mal ein Abonnement zugelegt um die Sache zu testen:

Vor Auswahl des Abbonements kann man seine zu unterstützende Region auswählen, die fortan besonders von den Einnahmen profitiert. Neben den von Osmand bekannten Kartenregionen die auch zum Download bereitstehen ist zusätzlich noch die Region World möglich.

Der monatliche Preis beträgt 1,19€ (davon 19% MwSt.) und berechtigt zum stündlichen Update wohl beliebig vieler Regionen.

Es sind für jede Kartenregion stündliche, tägliche,wöchentliche oder gar keine automatische Updates möglich. Das initiale Update für Sachsen vom Datenstand Anfang März bis zum 25. März war stolze 102 MB groß (Originalgröße: 232MB, d.h. 44%) , bei Portugal waren es nur 11 MB (Originalgröße: 197MB, d.h. 6%). Die Datenmengen sind also schon recht groß, aber wohl auch von der Aktivität abhängig, wobei ich persönlich nicht glaube, dass 44% der sächsischen Daten wirklich angefasst wurden.

Meine gestrigen Änderungen in ÖPNV-Relationen, Gebäuden usw. waren eingezeichnet. Laut Website werden in der vorläufigen Beta-Versionen aber mit dem Live-Update noch keine Routeninformationen aktualisiert

Mapper können sich mit E-Mail und einer Bitcoin-Adresse einen Account bei Osmand registrieren, der zur Auszahlung auf ein Bitcoin-Konto berechtigt. Nach welchen Kriterien das Ranking und die Auszahlung dann konkret aussehen wird, wird man nach ein paar Probemonaten sehen, das kann ich jetzt noch nicht überblicken.

Die Sache mit den stündlichen Updates ist definitiv hochinteressant und bringt OSM auf ein ganz neues Level bei mobilen Navis und sollte vielleicht auch das Denken der Mapper ändern. Bisher war der Konsens dann doch eher, dass man kurzfristiges eher nicht eintragen sollte, mit Osmand ändert sich dies aber definitiv! Es wirkt auch mappingunterstützend, wenn man in Mapping-Sessions aktuelle Änderungen nach 1 Stunde auf seinem Smartphone sieht.

Bei den Bitcoin-Zahlungen sehe ich persönlich dann aber doch ein gewisses Missbrauchspotenzial, hier wird man die Entwicklung absehen müssen. Man sollte in nächster Zeit vielleicht auch ein wenig kritischer hinschauen. Entscheidend ist wohl die Anzahl an Changesets, das begünstigt natürlich kleine Changesets… .

Einführung

Daten eintragen ist das eine, was Apps daraus machen, das andere.

In letzter Zeit teste ich vermehrt mit Osmand und Magic Earth. Osmand wird monatlich aktualisiert, Magic Earth wohl so aller 2-3 Monate. Von daher hat man immer eine recht aktuelle Datenbasis.

Für mein Verständnis haben die Apps für den Normalo 2 Hauptfunktionen:

• POI-Suche
• Navigation

Die weiteren Funktionen sind für den Normalo teilweise uninteressant, dafür für den Mapper umso wichtiger.

Tags und Probleme in OSM

## POI Die POI-Suche nach Namen ist teilweise bisschen hakelig, da keine Fehler zugelassen werden, da kann aber OSM nichts dafür. Die allgemeine Suche nach POI funktioniert dafür gut. Interessant ist die Funktion in Magic Earth POI als Kontakt im Telefonbuch abzulegen. Es zeigt sich dann, wie wichtig es ist, dass bei einem POI alle Daten angeheftet sind, d.h. auch Adresse usw. an jedem POI heftet, damit es dann auch in den Kontakten landet. Bei beiden Apps kann man die Website des POI direkt aufrufen, ebenfalls sehr gelungen. Was nur bei Osmand funktioniert: Auswertung der Öffnungszeiten, Aufruf weiterer Kontaktmöglichkeiten (twitter, facebook usw.) - alles in allem auch sehr komfortabel, wenn man unterwegs ist (muss dann natürlich eingetragen sein). ## Navigation im Simulationsmodus Osmand und Magic Earth bieten beide einen Simulationsmodus für die Navigation. So kann man sich in Ruhe anschauen, was die Apps aus den Daten machen.

Aufgefallen ist mir folgendes:

• turn:lanes bei kleineren Kreuzungen sind kein Problem
• bei größeren Kreuzungen mit eigenen Fahrspuren pro Fahrbahnrichtung gibts immer mal Probleme beim Anzeigen der Spuren auf welchen man sich bewegen soll. Die Apps verhalten sich auch nicht gleich, ein einheitliches Muster fürs Tagging scheint schwer zu etablieren
• Die Ansagen “geradeaus”, “rechts” und “links” werden bei Hauptstraßen oft mal falsch angesagt. Der Fehler liegt hier in den Daten bei OSM selbst. Aus dem Luftbild werden Hauptstraßen an Kreuzungen rund gemalt. Ob man Kreuzungen rund malt, sollte aber nicht vom Luftbild entschieden werden, sondern der Ausschilderung folgen.Zeigt die Ausschilderung eine abbiegende Hauptstraße, sollte diese Kreuzungsgeometrie auch in OSM zu sehen sein; zeigt die Ausschildung keine abbiegende Hauptstraße, kann und sollte man die Hauptstraße ruhig rund zeichnen
• Die Routenvorschläge sind immer eine Sache für sich: ob hier etwas richtig oder falsch ist, kann jeder für sich beurteilen. Aber man bekommt ein Gefühl, was letztlich aus den Daten gemacht wird. Eine vollständige Datenbasis (Klassifizierungen, maxspeed, smoothness usw.) sollte in der Zielregion natürlich schon vorhanden sein.

Navigation im Feldmodus

Im realen Feld sollte man die Navigation natürlich auch testen. Ich bevorzuge hier ganz klar Osmand. Das einzige was bei Magic Earth interessant ist, ist die bessere Performance bei Langstrecke und die Abbiegehinweise. Bei Osmand kann man sehr gut die eingetragene Höchstgeschwindigkeit kontrollieren. Notizen kann man über Text und Audio aufnehmen, wobei das als Fahrer trotzdem schwierig ist. Beifahrer zu sein ist schon besser.

Sonstige Funktionen

Osmand bietet viele weitere Funktionen an die zur Qualitätssischerung für mich geeignet sind:

• Straßenbeleuchtung (lit=yes/no)
• surface
• smoothness
• access-Beschränkungen foot/bicycle

Wer in Osmand dazu ein Beispiel sehen will, der kann sich einmal die Stadt Wurzen anschauen, ich habe diese mit diesen Tags unter Zuhilfenahme von Osmand für die Hauptstraßen weitgehend komplettiert. Lässt sich auch wunderbar sammeln, wenn man unterwegs ist und auf dem Handy sofort sieht, was noch alles fehlt.

Probleme protokollieren

Wenn ich draußen unterwegs bin, schreibe ich mir bei Problemen immer einen Favoriten an die jeweilige Stelle und trage das später am PC ein. Osmand bietet noch Foto, Audio oder Video, auch nicht schlecht.

Andere Apps

EB Dirigo habe ich ebenfalls mal angeguckt. Man kann auch dort simulieren, aber leider kann man den Anfangspunkt nicht wählen, wodurch man immer ein FakeGPS braucht. Für mich nicht praktikabel, von daher verzichte ich darauf. Auch sonst sehe ich der App nichts besonderes, eher ein kleiner Funktionsumfang.

Gibt es noch andere gute Apps, die sich zur Qualitätskontrolle eignen?

Einleitung

Zuletzt habe ich in OSM markante POI mit verschiedenen Social-Media-Tags ergänzt. Dass diese sinnvoll sein können, zeigen Apps wie Osmand und Magic Earth die z.B. Telefonnummer, Website auswerten und Osmand auch andere Tags wie contact:facebook auswertet und innerhalb der App verlinkt. Im mobilen Einsatz ist es sehr bequem, wenn diese Tags gesetzt sind, da viele Handys appbasiert am effektivsten arbeiten.

Nun ist es ja bekanntlich so, dass viele Geschäfte inzwischen nur noch eine Facebook-Website besitzen, also kommt man um facebook ohnehin nicht umhin. Andere Tags wie twitter, youtube oder alle sonstigen wie vimeo, pinterest oder instagram habe ich gleich mitgesetzt. ## Status quo Während ich in Magic Earth nach POI wie “Flughafen Dresden” suchte, sah ich, dass dieser nur absolut stiefmütterliche Tags besitzt, nicht einmal eine postalische Adresse. Auch andere Gebäude haben durch das Taggen der Nummer auf den Eingang nicht einmal eine postalische Adresse. Die Datenqualität in OSM kann nur als dürftig beschrieben werden.

Klar kann sich nun der OSM-Mapper hinsetzen, aber das kann ja nicht Sinn der Sache sein tausende POI händisch nach Updates zu untersuchen. Bei unserem Konkurrenten google ist es z.B. so, dass jeder User die Fehler in den Daten melden kann. Bei OSM ist das nur über openstreetbugs möglich. Aber sein wir ehrlich: openstreetbugs ist nur für Leute gedacht, die überhaupt verstanden haben was OSM ist, nicht für App-Benutzer, die vielleicht gar nicht wissen, was OSM ist. Bereits das Beispiel MapDust von skobbler zeigte, wie die Nutzer mit unsinnigen Fehlermeldungen das System fluten können. # Anforderungen Was braucht OSM also? Unter höchstmöglicher Produktivität stelle ich mir das folgendermaßen vor: OSM erstellt eine Bug-API die alle Apps nutzen können. Der User kann dann in der App jegliche Tags, z.B. das Feld “Website” oder “contact:facebook” usw. als fehlerhaft melden. Dann hat er verschiedene Meldegründe:

• Wert überprüfen: “Website lässt sich nicht öffnen” (würde den Grund dafür optional lassen, gibt OSM aber Möglichkeit nachzugucken, ob etwas noch stimmt)
• Wert ändern: Seite umgezogen -> Eingabe der neuen Seite
• Wert hinzufügen: Eingabe der Seite
• Wert löschen: Website existiert nicht mehr (z.B. geschlossen) –> im Endeffekt hat der Nutzer so die Möglichkeit, jeden Tag als “überprüfen”, “hinzufügen”, “löschen” oder “ändern” zu markieren und dazu einen neuen Wert sowie Kommentar zu hinterlassen.

Zusätzlich muss der App-Lieferant zusätzlich 3 Tags zu jeder Fehlermeldung protokollieren:

• Den App-Lieferant (da schlecht designte Apps u.U. uns mit Bugs überfluten, wo sich die Benutzer über die App auslassen o.ä.)
• Die App muss uns eine anonyme unique User-ID liefern, damit wir die Validität der Datenlieferanten einschätzen können und Spammer blocken können
• Die ID des zu bearbeitenden Objekts (Relation, Way, Node)

Bearbeitung durch Mapper

Nun sind diese Daten im OSM-Bug-System. Sie sollten aber nicht nur einfach dargestellt werden, wie das bei MapDust oder openstreetbugs der Fall ist, sondern aufgrund der zu erwartenden hohen Fehlerzahlen, muss die Verarbeitung verbessert werden. Da der Datenlieferant uns die Daten bereits auf das konkrete bezogene Objekt und die zu ändernden Daten bringt, wird es für den versierten OSM-Mapper einfach, indem er in einer Web-Oberfläche entscheidet: Im Grunde hat der OSM-Mapper 4 Möglichkeiten:

• Bug-Mängelmeldung übernehmen: Nach einem Klick auf “übernehmen” werden die vorgeschlagenen Änderungen instant in die Datenbank gebracht (vorher hat der Mapper noch Möglichkeit, selbst kleine Änderungen an Tags vorzunehmen (z.B. Websiteangabe normieren))
• Bug-Mängemeldung ablehnen: Die Bug-Meldung wird geschlossen, es werden keine Änderungen vorgenommen (optional Kommentar)
• Bug-Mängelmeldung selbst übernehmen: der Mapper öffnet selbst einen Editor und ändert das Objekt, danach ist der Bug geschlossen (wenn komplizierter Sachverhalt)
• Bug-Mängelmeldung benötigt lokales Wissen/Vor-Ort Besichtigung: Der Bug ist nicht geschlossen, aber er wurde bereits durch einen Mapper erfolgreich anfangsgeprüft. (So können wir gewähren, dass VorOrt-Bugs die lange rumliegen können, unser System nicht verstopfen und wir neue Bugs trotzdem filtern können)

Schluss

Das ist mein Vorschlag, er würde OSM extrem in der Breite verbreiten und anschließend eine effektive Abarbeitung ermöglichen sowie sogar Spezial-Apps eine Möglichkeit geben, bestimmte Dinge flächendeckend durch User einzutragen lassen. Durch die Kennzeichnung des App-Lieferanten könnten Spezial Mapper (z.B. Eisenbahninfrastrukturmapper) durch Filterung sich extra dieser Bugs annehmen. Sicher muss man an der einen oder anderen Stelle noch etwas verfeinern, aber das wäre das Grundprinzip.