Bernds Blog

Gestern habe ich den ersten wirkliche Praxiseinsatz meines neuen eTrex Legend als Auto-Navi mit OpenStreetMap-Daten hinter mich gebracht.

Zuerstmal: Nach Chemnitz an sich hätte ich natürlich auch ohne Navi gefunden, das ist jetzt nicht so wahnsinnig schwierig. Am Ortseingang Chemnitz fiel uns aber (spontan) auf, dass wir ja noch was essen müssen. Da wir grade an einem amerikanischen Fast-Food-Restaurant vorbei gefahren sind, brauchte es kein Navi um das zu finden. Allerdings haben wir dann eine Tankstelle gesucht, eine spezielle Kette sogar, da wir noch einen Tank-Gutschein dabei hatten. Das hat das Navi mit Bravour gemacht.
Von irgendwo in einem Industriegebiet in der Chemnitzer Vorstand dann das Hörsaalgebäude der TU zu finden ist dann wirklich etwas bei dem sich ein Navi als extrem praktisch erweisen kann.

Mein persönliches Fazit:
Es ist gewöhnungsbedürftig, ein Navi ohne Sprachausgabe zu haben. Das Gerät schaltet das Licht in der Standardeinstellung zu schnell wieder ab, so dass man z.B. nicht mehr bequem lesen kann, wie lange es noch bis zum Abbiegen ist. Die Beleuchtungsdauer kann man einstellen (auf Kosten der Batterien). Für die Auto-Navigation an einemtrüben Tag wäre es vermutlich sinnvoll, das Gerät mit dauerhafter, gedimmter Beleuchtung (evtl. mit externer Stromversorgung) zu betreiben. Ist Einstellungssache.

Dennoch kommen die Ansagen rechtzeitig.

Bei der Fahrt fiel auf, dass das Navi in Autobahnkreuzen viel zu wenig redet. Es wurde teilweise nur angemerkt, dass man jetzt nach rechts auf die andere Autobahn abfahren soll. In einem normalen Kleeblatt-Kreuz ist das zu wenig, da man mindestens zweimal rechts abbiegen muss.
Die Lösung des Problems liegt in den Daten, denn bisher arbeitete der Konverter mkgmap mit den selben Straßentypen für Autobahn und Autobahn-Rampen. Die Rampen haben im Garmin-Format aber einen separaten Typ, mit dem die Ansagen gleich viel brauchbarer werden. Die passende Änderung im mkgmap-Default-Style kam mit mkgmap-r975 am Mittwoch. Eine Trockenübung der selben Route mit neu erzeugtem Kartenmaterial zeigt, dass die Anweisungen jetzt korrekt ablaufen und verständlicher formuliert sind (z.B. "rechts abfahren" anstelle von "rechts halten").

Die Entwicklung bei mkgmap ist eine wahre Freude und ich bin mir sicher, dass auch die Adress-Suche bald funktionieren wird.

Nach meinen ersten Gehversuchen mit eigenen OSM-Karte auf meinem neuen Garmin-Navi wollte ich unbedingt auch Höhenlinien verfügbar haben. Die Höhenlinien werden üblicherweise aus den SRTM-Daten der NASA gewonnen. Es gibt auch Software, die diese Daten nach OSM konvertiert, aber das ist leider eine Windows-Software, die bei mir folglich nicht läuft.

Zudem ist es etwas unpraktisch, wenn sich jeder die Rohdaten runterladen muss un die dann selbst konvertiert. Ich habe daher auf der OSM-Mailingliste nach jemandem gefragt, der einen entsprechenden Bereich konvertiert und das Ergebnis dann bei dem besten Provider der Welt auf den Mirror-Server gelegt:
http://mirror.schokokeks.org/OpenStreetMap/SRTM/

Dort befinden sich (im entsprechenden Unterverzeichnis) die Daten in 10-Höhenmeter-Auflösung oder in 25-Höhenmeter-Auflösung.

Dank und Ehre gebührt Stefan Dettenhofer, der die Dateien erzeugt hat und im Original anbietet, wenn auch nur über eine Kabel-Deutschland-Flatrate.
Bei ihm gibt es aber eine schöne Übersicht über die verfügbaren Kacheln.

UPDATE (2011-01-09): Ich meine mich zu erinnern dass ich neulich gelesen habe dass es jetzt mehrere Anbieter von SRTM für OSM gibt. Ich habe die Dateien vom oben genannten Mirror entfernt.

Da ich seit langem bei OSM aktiv bin, hatte es mich immer wieder gestört, dass ich kein mobiles Gerät habe, auf dem ich diese Karten nutzen kann.

Momentan gibt es leider keinen voll befriedigenden Weg, OSM-Karte auf einem mobilen Gerät zu betreiben und umfassend zu benutzen.
Die dafür programmierten Anwendungen sind einfach noch nicht so weit, dass man sich damit in fremden Gefilden navigieren lassen könnte und die Hersteller proprietärer Navigationssysteme halten ihr Dateiformat aus verständlichen Gründen unter Verschluss.

Vor Kurzem wurde Googles »MapMaker« vorgestellt. Damit möchte Google auch Karten von den Regionen, in denen entweder TeleAtlas keine akzeptablen Karten besitzt oder Google diese nicht kaufen wollte. Anders formuliert: Die Regionen, die bei Google-Maps momentan noch weiß sind.

Googles »MapMaker« ist dabei ein Prototyp einer vollständig von der Community erstellten, kommerziellen »Web 2.0«-Karte und damit auch ein Versuchsballon wie so etwas von der Allgemeinheit angenommen wird.

Seit Google-Mitarbeiter mit ihren StreetView-Fahrzeugen durch die Gegend gondeln ist es völlig naheliegend, dass die da auch GPS-Tracks sammeln. Zusammen mit den hochauflösenden Bildern lässt sich damit bequem von zu Hause aus ne verdammt detaillierte Karte erstellen. Momentan kombiniert Google diese beiden Verfahren nicht und lässt den Community-Karten-Editor nur auf spezielle, bisher unerfasste Regionen los. Aber es ist IMHO klar, dass der Punkt kommen wird, an dem Google keine Karten für die Industrieländer mehr von TeleAtlas kauft sondern selbst, vermutlich im Community-style, erstellt.
Das jetzt ist meiner Ansicht nach nur ein Testlauf ob das denn funktioniert.

Ich seh's kommen, dass Google-Karten bald unter Vorlage von StreetView-Daten von der Community gepflegt werden können. Wie Communities so sind, muss aber eine kritische Masse bereits eingetragen sein damit das ganze funktioniert.

Was bedeutet das jetzt für OpenStreetMap?

Gegen diese Google-Community kommt man meiner Meinung nach an, wenn man schneller alles wichtige drin habt. Denn Google kann nicht auf den bisherigen TeleAtlas-Karten operieren und diese von der Community verbessern lassen sondern fängt bei Null an. Oder hat intern schon angefangen, würde ich mal vermuten.

Was mich aber viel mehr stutzig macht, ist die rechtliche Lage der Google-Karten. Google lässt die Benutzer aufgrund von Sat- und Luftbildern eine Karte erstellen. Ich setze mal voraus, Google möchte uneingeschränkte Verwertungsrechte an den erstellten Karten, also z.B. auch Weiterveräußerungsrecht. Die Luftbilder, die ich so im Netz finde, enthalten in Ihren Bedingungen meist Klauseln, dass man kein Recht hat, abgeleitete Werke vollwertig und uneingeschränkt zu nutzen.

Auf der OSM-Mailingliste wurde vor kurzem schon die These aufgestellt, dass auf Basis eines Luftbilds erstellte Vektorkarten vermutlich genügend Schöpfungshöhe zugesprochen werden kann, so dass diese nicht mehr als direktes abgeleitetes Werk gelten. Das ist in Bezug auf Googles »MapMaker« die einzige Erklärung, wie ich mir das rechtlich Vorstellen kann.
Wenn das so wäre, würde das ganz neue Möglichkeiten für OpenStreetMap erschließen. Leider wird es schwer möglich sein, hier eine definitive Antwort zu erhalten.

Gestern wurde das regelmäßig stattfindende Treffen der LUG Backnang schon im Vorfeld in ein OpenStreetMap-Treffen umdeklariert. Das war eine gute Gelegenheit um das Thema OpenStreetMap, das bei der LUG in jüngerer Zeit sowieso einen hohen Stellenwert hat, mit einem Anlass zu verbinden, die anderen Mapper aus der näheren Umgebung mal kennen zu lernen.

Leider war Hanno kurzfristig verhindert und auch Fabian konnte leider erst später da sein. Letztendlich waren wir IIRC 9 Leute und es entwickelten sich wirklich nette (manchmal vielleicht zu tiefgründige) Gespräche.

Auch wenn ich zugegebener maßen nicht jeden der Anwesenden einschätzen konnte, so ist mein Eindruck, dass mindestens 2 sehr interessierte Neueinsteiger da waren, die bisher noch keine Erfahrungen mit dem OSM-Projekt haben. Zudem einer, den wir noch praktisch überzeugen müssen, dass das auch ohne Redaktion funktioniert. ;-)

Es bleibt fürs nächste Treffen festzuhalten: Wir brauchen Strom und Netz. Da ich als einziger "der Orgas" meinen Laptop nicht zum mappen benutze und erst kurzfristig erfahren habe, dass ich der einzige bin, der zu Beginn da ist, war meine Softwareausstattung mies und ich konnte nicht zeigen was ich zeigen wollte. Zum Glück habe ich noch einen Track auf der Fahrt zum Hirsch aufgezeichnet, mit dem ich dann so ganz grob zeigen konnte, was man da macht.

Auf jeden Fall würde ich das Treffen gerne wiederholen, insbesondere dann mit Netz-Anschluss, da ich erwarte, dass beim nächsten Mal praktische Fragen von den Interessierten kommen, die man dann hoffentlich gleich live bearbeiten kann. Eine Ubuntu-Installation steht auch auf der Tagesordnung, auch da bietet sich ein Raum mit Strom und Netz an.
Außerde würde sich dann der Potlatch-Nutzer nicht so diskriminiert fühlen, weil ich JOSM zeigen konnte und er Potlatch nicht. ;-))

Hanno schrieb vor ein paar Tagen einen Artikel zum Thema Geotagging.

Hier noch kurz die Variante für spiessige Doku-Leser:

Man muss nicht erst die Bilder mit einem mehr oder weniger akkuraten Geotag versehen sondern kann auch JOSM diese Aufgabe on-the-fly erledigen lassen. Das geht so:

GPX-Track von der Platte öffnen (mit heruntergeladenen GPS-Punkten geht das nicht!). Dann im Kontextmenü (rechtsklick) dieses Tracks den Punkt »Bilder öffnen« wählen. Dort dann alle Bilddateien auswählen und öffnen. Durch Unterschiede bei den gespeicherten Zeitzonen oder Uhrzeit-Differenzen passt jetzt nicht wirklich alles zusammen.

Dann kann man jedoch beim Layer mit den Bildern den Punkt »Uhrzeit synchronisieren« auswählen. Dort öffnet man ein beliebiges Bild, von dem man genau weiß, welcher Uhrzeit das auf dem GPX-Track entspricht. Tipp: Display mit GPS-Zeitangabe fotografieren!
Die entsprechende Uhrzeit trägt man dort ein. Zeitzonen-Abweichung wird bei den meisten wohl »+1« sein, denn GPX-tracks werden normal mit UTC gespeichert, Fotos dagegen mit lokaler Zeit.

Wenn man ein Foto an einem markanten Punkt hat, kann man auch dieses benutzen und die Zeit so lange verschieben bis sich das Foto am richtigen Ort befindet.


Diese GPS-Bilder-Zuordnung ist dann natürlich nicht persistent, das kann man als Vor- oder Nachteil werten. Aber im Endeffekt geht es schneller und bequemer als vorher noch mehr oder weniger genau die GPS-Koordinaten einfügen zu lassen.

Diesen Tipp habe ich mir übrigens nicht selbst überlegt, der steht genau so in offiziellen Doku von JOSM.

Wie vor einer Weile schon einmal schrieb, hat mein Handy (oder obexftp, keine Ahnung wer schuld ist) leider besondere Anforderungen, wie man Dateien für den OBEx-transfer spezifizieren muss.

Da ich ein Freund der Konsole bin und daher meine GPX-tracks immer mittels obexftp auf meinen Rechner kopiere, ist das doch etwas lästig.

Aber jetzt gibt es Abhilfe. ;-)

Um mir diese Aufgabe zu erleichtern, habe ich ein kleines Python-Programm erstellt, das zuerst obexftp aufruft um ein Verzeichnis-Listing zu erhalten und dann alle Dateien mittels obexftp -G herunterläd (-G bedeutet, Dateien werden auf dem Handy gelöscht).

Zur Verwendung muss zuerst das Python-Modul »ElementTree« installiert werden. Danach müssen die Bluetooth-Hardware-Adresse des Gegenüber und der OBEX-Datei-Pfad im Script eingetragen werden.

Download: obexget
Lizenz: GPL >= 3

Nachdem heute die (meiner Recherche nach) letzten fehlenden Straßen innerhalb des Murrhardter Kerngebiets erfasst wurden, würde ich voller Stolz sagen, kann das Gebiet der Murrhardter Kernstadt als vollständig erfasst gelten.

Murrhardt bei OpenStreetMap

Natürlich bedeutet das nicht, dass es nichts mehr zu tun gibt, diese aussage betrifft lediglich die per Auto befahrbaren Straßen bzw. die Straßen, die einen Namen tragen. Es gibt noch ein paar Fußwege, Gewässer und allerhand Kleinigkeiten, die noch nicht enthalten sind.

Viele Teilorte fehlen natürlich ebenfalls noch. Im OSM-Wiki haben wir eine Seite, auf der wir die Vollständigkeit der Teilorte dokumentieren.

Seit einiger Zeit habe ich ein Nokia 6230i und kann das auch per Bluetooth nutzen. Seit wenigen Tagen merke ich, dass gammu mit der Konfigurationsdatei die ich hier geklaut habe elendig langsam funktioniert. Jede Aktion dauert erstmal 2 Minuten für den Verbindungsaufbau.

Anhand der Gammu-Doku habe ich jetzt gesehen, dass mittlerweile offenbar ganz andere Namen für die selben Optionen eingeführt wurden. Nach einigen ausprobieren kam ich auf folgende Konfiguration:

[gammu]
model=6230i
port=00:17:E3:8E:FA:BC
connection=bluerfphonet
synchronizetime=no
use_locking=no
startinfo=no

Ergebnis: Der Verbindungsaufbau dauert jetzt ca. 3-4 Sekunden. nicht vollkommen perfekt aber erträglich.

Für die besserwissenden Hacker: Das Einschalten von use_locking erzeugt als User einen »permission denied«-Fehler. Das Einschalten von synchronizetime verstellt jedes mal die Uhr, da es nur Stunden und Minuten synchronisiert, nicht aber die Sekunden. Sekunden werden immer auf Null gesetzt. Nein, ich habe den Bug nicht reported.

Diese Woche erschien die neue Version der Handy-Java-Software »Mobile Trail Explorer«, Version 1.8.

Mit dieser Software und einem Bluetooth-GPS-Empfänger ist es möglich, GPS-Tracks aufzuzeichnen. Das größte manko der Vorversion war, dass die Software gelegentlich beim Speichern abstürzte (die berüchtigte "OutOfMemoryException") und damit der komplette Track weg war. man durfte also nicht vergessen, nach spätestens 500 Trackpoints zu speichern, da sonst die Datenmenge zu groß wurde.

Nicht so mit der neuen Version!!

Jetzt gibt es die Option "GPX-Stream". Dabei wird sofort begonnen, die Datei zu schreiben. Die Software schreibt Punkt für Punkt in die Datei und hält nicht einfach alles im Speicher. Dadurch gibt es keine Wartezeit und kein Speicherproblem nach Abschluß der Aufzeichnung.

Kurzanleitung:

• Menü
• Manage Trails
• Option
• New GPX stream
• Dann kommt die Frage des Telefons ob auf die Speicherkarte geschrieben werden darf
• Danach noch »Start/Stop recording«
• Nach Abschluß der Aufzeichnung (»Start/Stiop recording«) kommt der üblicher Speichern-Dialog, mit der zusätzlichen Option am Ende »Close GPX Stream«
• Der Name der resultierenden Datei beginnt mit »stream_«

Besonders erwähnenswert:
Wenn das Programm abstürzt oder versehentlich beendet wird, geht nichts verloren! Beim nächsten Start fragt das Programm ob der alte GPX-Stream fortgesetzt werden soll. tut man das nicht (»Forget about it«), hat man aber auch trotzdem noch eine Datei, bei der man nur das XML manuell schließen muss, die Punkte sind dennoch alle drin.

Noch nicht getestet habe ich, ob in diesem GPX-Stream auch die Waypoints drin sind.

Nach diesem ersten Eindruck der neuen Version: Prädikat »Absolut empfehlenswert!«

Ja, die wesentlichste Neuerung war, dass das Program OSM-Tiles als Hintergrund anzeigen kann und damit die eigene Route live visualisieren kann. Aber ohne vernünftige Daten-Flatrate und ohne schnellere Verbindung ist das für mich etwas sinnlos. Ich freu mich einfach über die neue GPX-Stream-Funktion.