flattr

Wie im letzten Post schon anklang, bin ich jetzt Mitglied bei flattr.
Für die, die noch nichts davon gehört haben: flattr bietet die Möglichkeit, den Autoren bestimmter Beiträge im Netz ein bisschen Geld zukommen zu lassen, um sie in ihrer Arbeit zu unterstützen. Man kann damit Blog-Einträge „loben“, aber auch Musikstücke, Videos, Bilder oder beliebigen sonstigen Content.
Voraussetzung ist, dass der Autor flattr-Mitglied ist und neben dem Content einen flattr-Button platziert hat.
Um teilzunehmen, macht man sich einen flattr-Account und lädt via PayPal oder Moneybookers ein bisschen Geld hoch. Von diesem Betrag wird dann monatlich ein einstellbarer Betrag abgezogen (mindestens € 2,–).
Der wird am Ende des Monats auf alle verteilt, die man geflattrt hat. Bei einem Betrag von € 2,– und zehn Klicks auf verschiedene flattr-Buttons werden pro Button also 20 ct augeschüttet. Oder vielmehr 18 ct, weil flattr selbst 10 % behält.
Solange man Geld auf dem flattr-Konto hat, werden die monatlichen Beträge immer abgezogen. Klickt man einen Monat lang auf keinen flattr-Button, wird der monatliche Betrag gespendet – weg ist er auf jeden Fall.
Ist nicht mehr genug Geld für den monatlichen Betrag vorhanden, wird der vorhandene Rest genommen und verteilt. Sobald das Konto auf null gefallen ist, ist der Account inaktiv, und man kann weder Klicks verteilen noch Geld einnehmen.
Die Idee dahinter ist, dass im Netz nicht alles kostenlos sein muss und es eigentlich gut wäre, wenn man anderen freiwillig etwas geben könnte, wenn man ihre Arbeit mag. Das muss einfach und praktisch vonstatten gehen können.
Dass man nur Geld einnehmen kann, wenn man gleichzeitig auch Geld verteilt, ist ein weiterer guter Trick. Damit ist sichergestllt, dass auch Geld in Umlauf kommt und nicht jeder nur einnehmen will.
Derzeit ist flattr noch in der Beta-Phase, und man braucht eine Einladung, um mitmachen zu können. Als Mitglied kann ich andere einladen; wenn also jemand Lust bekommen hat, schreibe er mir einfach eine kurze E-Mail (siehe Kontakt-Link rechts), und ich werde eine Einladung veranlassen.

Wie im letzten Post schon anklang, bin ich jetzt Mitglied bei flattr.
Für die, die noch nichts davon gehört haben: flattr bietet die Möglichkeit, den Autoren bestimmter Beiträge im Netz ein bisschen Geld zukommen zu lassen, um sie in ihrer Arbeit zu unterstützen. Man kann damit Blog-Einträge „loben“, aber auch Musikstücke, Videos, Bilder oder beliebigen sonstigen Content.
Voraussetzung ist, dass der Autor flattr-Mitglied ist und neben dem Content einen flattr-Button platziert hat.
Um teilzunehmen, macht man sich einen flattr-Account und lädt via PayPal oder Moneybookers ein bisschen Geld hoch. Von diesem Betrag wird dann monatlich ein einstellbarer Betrag abgezogen (mindestens € 2,–).
Der wird am Ende des Monats auf alle verteilt, die man geflattrt hat. Bei einem Betrag von € 2,– und zehn Klicks auf verschiedene flattr-Buttons werden pro Button also 20 ct augeschüttet. Oder vielmehr 18 ct, weil flattr selbst 10 % behält.
Solange man Geld auf dem flattr-Konto hat, werden die monatlichen Beträge immer abgezogen. Klickt man einen Monat lang auf keinen flattr-Button, wird der monatliche Betrag gespendet – weg ist er auf jeden Fall.
Ist nicht mehr genug Geld für den monatlichen Betrag vorhanden, wird der vorhandene Rest genommen und verteilt. Sobald das Konto auf null gefallen ist, ist der Account inaktiv, und man kann weder Klicks verteilen noch Geld einnehmen.
Die Idee dahinter ist, dass im Netz nicht alles kostenlos sein muss und es eigentlich gut wäre, wenn man anderen freiwillig etwas geben könnte, wenn man ihre Arbeit mag. Das muss einfach und praktisch vonstatten gehen können.
Dass man nur Geld einnehmen kann, wenn man gleichzeitig auch Geld verteilt, ist ein weiterer guter Trick. Damit ist sichergestllt, dass auch Geld in Umlauf kommt und nicht jeder nur einnehmen will.
Derzeit ist flattr noch in der Beta-Phase, und man braucht eine Einladung, um mitmachen zu können. Als Mitglied kann ich andere einladen; wenn also jemand Lust bekommen hat, schreibe er mir einfach eine kurze E-Mail (siehe Kontakt-Link rechts), und ich werde eine Einladung veranlassen.

flattr

flattr plugin for blogger.com/blogspot.com (old version)

There is a new version of this plugin that uses the new API. Please look here.


As this post is intended for an international audience, I'll write it in English.
As I'm a memeber of flattr.com since a few days, I wanted to add a flattr button to my blog posts.
I found this solution on Nicolas Gramlich's blog (who copied most of the script from Mattias Bomelin), but it worked only on short blog entries. All others showed only a large "ER" which seems to be the flattr error message.
If Nicolas hasn't changed his Blogger template yet, you can see the behaviour if you click on the link above. (Looks good sometimes, shows error at other times.)
When I investigated the issue, I found out that the flattr decription as sent by the plugin was too long, and I was also told that it shouldn't contain newlines or unescaped ' chars. Update: This seems to have been a wrong information, at least if a div tag is used like in the script. The posts ended up with literal \n and \' in them, so I put the relevant lines in comments.
I tweaked everything a bit, and here's a solution to the problem:
Click this link to get a changed version of the plugin.
It will:

• Use the post itself as the flattr description just as the original plugin did, but …
• It will remove all HTML tags from the flattr description.
• It will replace newlines by \n. See update above.
• It will escape ' chars to \'. See update above.
• It will truncate the description to a maximum length of 980 chars. If possible, it will use a space as truncation point and add "…".
• It will respect other flattr limits and truncate the title to a maximum length of 80 chars and the tags to a maximum length of 230 chars in a similar manner. (I stayed a little away from the hard limits of 100 / 255 chars, respectively.)
• Update: flattr requires the title of a flattr thing to have at least five chars. So if you have a blog post called "Uh!" it won't be enough and you'll get an error in the flattr button. I couldn't think of a good possibility to fill missing chars without garbling the blog post title, so I just kept it the way it is (suggestions welcome). So this is a caveat: Always use post titles longer than 5 chars! ;-)

As you can see in this post, I added the flattr button to the bottom of the post, different from what Nicolas did. To achieve that, I placed it in the 'post-body entry-content' div. Here are a few lines from the Blogger template and the start of the plugin to illustrate where I put it:

<div class='post-body entry-content'>
   <data:post.body/>
   <div style='clear: both;'/> <!-- clear for photos floats -->
   <!-- flattr plugin starts here -->
   <div expr:id='&quot;flattr_summary_&quot; + data:post.id' style='display: none;'> 
   <data:post.body/> 
   </div>  …

Note that I put the <span> tags from Nicolas' version into comments to achieve a sensible placement. You'll have to reenable them if you want to use the plugin in the title as Nicolas did.
Also, I changed the language to de_DE as appropriate for my blog; you'll have to change that, too, if you're not writing in German.

If anybody knows how to change the content of the RSS and Atom feeds I'd appreciate a notice as I'd like to add a flattr button to the feeds, too.

So, happy flattring to all of you! Credits go to Nicolas and especially to Mattias who created the original work.

There is a new version of this plugin that uses the new API. Please look here.


As this post is intended for an international audience, I'll write it in English.
As I'm a memeber of flattr.com since a few days, I wanted to add a flattr button to my blog posts.
I found this solution on Nicolas Gramlich's blog (who copied most of the script from Mattias Bomelin), but it worked only on short blog entries. All others showed only a large "ER" which seems to be the flattr error message.
If Nicolas hasn't changed his Blogger template yet, you can see the behaviour if you click on the link above. (Looks good sometimes, shows error at other times.)
When I investigated the issue, I found out that the flattr decription as sent by the plugin was too long, and I was also told that it shouldn't contain newlines or unescaped ' chars. Update: This seems to have been a wrong information, at least if a div tag is used like in the script. The posts ended up with literal \n and \' in them, so I put the relevant lines in comments.
I tweaked everything a bit, and here's a solution to the problem:
Click this link to get a changed version of the plugin.
It will:

• Use the post itself as the flattr description just as the original plugin did, but …
• It will remove all HTML tags from the flattr description.
• It will replace newlines by \n. See update above.
• It will escape ' chars to \'. See update above.
• It will truncate the description to a maximum length of 980 chars. If possible, it will use a space as truncation point and add "…".
• It will respect other flattr limits and truncate the title to a maximum length of 80 chars and the tags to a maximum length of 230 chars in a similar manner. (I stayed a little away from the hard limits of 100 / 255 chars, respectively.)
• Update: flattr requires the title of a flattr thing to have at least five chars. So if you have a blog post called "Uh!" it won't be enough and you'll get an error in the flattr button. I couldn't think of a good possibility to fill missing chars without garbling the blog post title, so I just kept it the way it is (suggestions welcome). So this is a caveat: Always use post titles longer than 5 chars! ;-)

As you can see in this post, I added the flattr button to the bottom of the post, different from what Nicolas did. To achieve that, I placed it in the 'post-body entry-content' div. Here are a few lines from the Blogger template and the start of the plugin to illustrate where I put it:

<div class='post-body entry-content'>
   <data:post.body/>
   <div style='clear: both;'/> <!-- clear for photos floats -->
   <!-- flattr plugin starts here -->
   <div expr:id='&quot;flattr_summary_&quot; + data:post.id' style='display: none;'> 
   <data:post.body/> 
   </div>  …

Note that I put the <span> tags from Nicolas' version into comments to achieve a sensible placement. You'll have to reenable them if you want to use the plugin in the title as Nicolas did.
Also, I changed the language to de_DE as appropriate for my blog; you'll have to change that, too, if you're not writing in German.

If anybody knows how to change the content of the RSS and Atom feeds I'd appreciate a notice as I'd like to add a flattr button to the feeds, too.

So, happy flattring to all of you! Credits go to Nicolas and especially to Mattias who created the original work.

flattr plugin for blogger.com/blogspot.com (old version)

Navigation unter Android

Schon auf dem iPhone hatte ich überlegt, mein TomTom GO 720 durch das iPhone zu ersetzen. Letztlich konnte ich mich zu dem Schritt aber nicht durchringen, da das TomTom dank IQRoutes 2 meist ganz gute Routen liefert, die mit Navigtionssoftware ohne Geschwindigkeitsdatenbank kaum erreichbar ist. TomToms eigene Navigationsanwendung fürs iPhone konnte zunächst, gelinde gesagt, kaum begeistern.
Als die anderen Anbieter dann mit Geschwindigkeitsdatenbanken nachzogen und auch TomToms iPhone-App sich zu steigern begann, war ich schon auf der Suche nach einem besseren Ersatz für das iPhone und sah mich insofern nicht weiter um.
Jetzt geht unter Android das gleiche Spielchen los. Das Kriterium ist und bleibt: Entweder ich bekomme für relativ viel Geld eine Applikation, die es von Qualität der Routen her mit TomTom aufnehmen kann, oder ich bekomme für sehr wenig Geld (< € 10,–) etwas, was zumindest korrekte, wenn auch vielleicht nicht perfekte Routen bietet.
POI-Datenbanken nutze ich kaum, sie sind für mich also eher nicht von Interesse. Auch interessieren mich „Wo sind meine Freunde“-Dienste nicht, da ich weder ständig meine eigene Position veröffentlichen möchte, noch Freunde habe, die das tun würden. Außerdem gibt es dafür spezialisierte Dienste, die es vmtl. besser können, etwa Google Latitude oder Foursquare.
Hier ein Kurzüberblick zu den (teils auch noch nicht oder nicht mehr) erhältlichen Optionen.
Interessant finde ich wegen meines eigenen Routing-Projekts vor allem die Programme, die mit Openstreetmap-Daten arbeiten. Wie schon erwähnt sind diese Daten nur bedingt für Routing geeignet. Spannend, was mit guter Programmierung trotzdem herausgeholt werden kann.
In alphabetischer Reihenfolge:

• AndNav2: Routing auf OSM-Basis in Zusammenarbeit mit OpenRouteService.org. Nur Online-Routing, fürs Ausland also nicht geeignet. Schön klingen die Features zum Meiden bestimmter Bereiche und zum Darstellen aller vom aktuellen Ort aus in bestimmter Zeit erreichbaren Orte.
  Stand heute leider keine Berücksichtigung von Abbiegeverboten.
• CoPilot Live: Liegt wohl genau zwischendrin – weder richtig billig noch richtig teuer/gut. :-) Nutzt NavTeq-Kartenmaterial, damit also Profi-Routingmaterial, aber scheinbar ohne reale Geschwindigkeitsdaten für die Straßen. Das heißt: Vmtl. keine TomTom-Qualität, aber das Niveau normaler Navigationsgeräte der letzten Jahre. Verkehrsnachrichten sind als kostenpflichtiger Premium-Dienst verfügbar; einige weitere Goodies wie das verfolgen anderer CoPilot-User auf der Karte.
  Für diesen Qualitätslevel zu sehr günstigen Preisen zu haben.
• Google: Kostenlose Turn-by-Turn-Navigation mit Google Maps. Offboard-Lösung, nur mit Internetverbindung benutzbar. Wie auch im Online-Angebot von Google sind die Routen nicht immer optimal, aber für kostenlose Navigation ist das Angebot mehr als nur in Ordnung.
• MotoNav: Liegt auf Motorola Milestones als 60-Tage-Testversion bei. Es handelt sich um eine leicht veränderte Version der iGo-Navigationssoftware aus dem Hause NNG, die in Deutschland nur in vorinstallierter Version auf dem Milestone zu haben ist.
  Als OnBoard-Lösung verbraucht es während der Nutzung keinerlei Daten.
• Nav4All: Der Vollständigkeit halber: War bis Januar erhältlich/funktionstüchtig und soll ganz gut gewesen sein. Kostenlose Navigation mit Navteq-Kartenmaterial. Die Lizenz zur Nutzung des Kartenmaterials wurde von Navteq (hundertprozentige Nokia-Tochter) entzogen, kurz bevor Nokia seine eigene, kostenlose Navigationslösung präsentierte. Ein Schelm, wer Böses dabei denkt.
• Navigon Mobile Navigator: Sieht auf den ersten Blick nach dem derzeit komplettesten (und teuersten) Angebot für Android aus. Die MyRoutes-Funktion klingt sehr interessant: Da sollen die Routen nicht nur nach Tageszeit, sondern auch nach einem nach und nach von der Software erstellten Profil des Fahrers berechnet werden. Außerdem werden bis zu drei Alternativen vorgeschlagen. Klingt wirklich gut und geht sogar noch weiter als TomToms IQRoutes 2 – mal sehen, ob es auch etwas taugt. Allerdings scheinen keine Verkehrsinformationen verfügbar zu sein.
  Netterweise gibt es eine 30-Tage-Testversion.
• NavDroyd: OnBoard-Lösung, Karten werden also auf dem Gerät gespeichert. Umfangreiches, weltweites Kartenmaterial basierend auf OpenStreetmap steht zur Verfügung. Für kommerzielle Anwendung gibt es offenbar auch die Möglichkeit, bereits lizensiertes, kommerzielles Kartenmaterial z.B. von NavTeq zu nutzen. Für normale Endkunden gibt es diese Option aber nicht.
  Günstiger Preis (derzeit € 4,99) für eine OnBoard-Lösung, schöne Kartendarstellung.
  Wird momentan anscheinend fleißig weiterentwickelt, häufige Updates. Laut Website derzeit noch keine Berücksichtigung von Abbiegeverboten, die allerdings noch kommen soll.
• Navit: OSM-Karten im binären Format für Offline-Routing. Allgemeines Linux-Routing, das auch für Android verfügbar ist. Klingt als wäre es für den täglichen Einsatz und von der Konfiguration her noch nicht so einfach benutzbar wie andere Systeme. Dieses Urteil stammt aber ausschließlich von etwas Wiki-Studium, ich habe mir die tatsächliche Anwendung noch nicht angesehen.
• OsmAnd: Komplett kostenlose Open-Source-Navigation samt Helfer für OSM-Karteneditierer. Bislang noch eine 0.x-Version, sieht aber sehr vielversprechend aus, zumal die Karten OnBoard gespeichert werden können.
  Die Routenberechnung für die Navigation selbst läuft aber ausschließlich über Online-Anbieter, konkret werden bislang CloudMade (wie bei Skobbler) und YOURS unterstützt. Beide reißen mich von den generierten Routen her nicht zu Jubelstürmen hin, sind aber durchaus nutzbar.
  Einen Blick ist diese Lösung mit Sicherheit wert, vor allem für OSM-Enthusiasten.
• Skobbler: Navigation mit Extras, Community-Features speziell im Bereich POIs. Die Android-Version ist seit einiger Zeit offiziell erhältlich, bislang noch kostenlos.
  In der iPhone-Version mit Navteq-Kartenmaterial gab es Druck von Navigon, u.a. deshalb wurde vor Kurzem auf OSM-Kartenmaterial umgeschwenkt. Die Firma war ursprünglich eine Ausgründung von Navigon selbst; die Programmierer dürften sich also mit Routing auskennen. Genutzt wird allerdings CloudMade-Routing, das ich persönlich für nicht so wahnsinnig toll halte (zu autobahnfixiert, z. B.). Im Gegensatz zu vielen anderen OSM-basierenden Routinglösungen werden dort allerdings immerhin Abbiegeverbote berücksichtigt.
  Zumindest geplant ist nicht nur Online-Routing, sondern auch die Möglichkeit zum Abspeichern von Kartenbereichen, um sie ohne Internetverbindung nutzen zu können.
  Ein Rückkanal zu Openstreetmap.org ist vorhanden, um Kartenverbesserungen zu erleichtern.
  Wo Skobbler für Android preislich letztlich liegen wird, weiß ich nicht – angesichts der mittlerweile erwachsenen Konkurrenz durch kostenlose Google-Maps-Navigation ist fraglich, ob sich mehr als „werbefinanziert“ überhaupt wird durchsetzen lassen.
• Sygic Mobile Maps: TeleAtlas-Kartenmaterial. Soweit ich das bisher überblicke der einzige Anbieter, der kostenlos Verkehrsinformationen bietet (allerdings keine live gsammelten Infos anderer Nutzer, sondern TMC-artige Informationen von Polizei und Verkehrsüberwachung). Preislich auf dem Niveau des derzeit verbilligten Navigon-Systems (Europa-Karte € 60,–).
• Telmap Navigator: Offboard-Lösung (nur Online) mit Navteq-Datenmaterial, wird evtl. bald auf TeleAtlas umgestellt. ADAC-Verkehrsinformationen. (Ob die nur angezeigt oder zum Routing benutz werden, ist mir nicht ganz klar.) TelMap wird nicht an Endkunden verkauft, sondern nur über Handyhersteller und Provider angeboten. In Deutschland ausschließlich für O2-Kunden erhältlich (abgesehen von den Datenverbrauchskosten kostenlos).
• TomTom: Ein TomTom-Sprecher hatte Mitte letzten Jahres von einer TomTom-App für Android gesprochen. Seitdem scheint sich aber nichts mehr getan zu haben.
• Waze: Community-Projekt, bei dem eine eigene Karte erstellt wird, die direkt fürs Routing gedacht ist. Straßen werden aus GPS-Logs erzeugt und enthalten auch direkt Geschwindigkeitsinformationen. Live-Informationen von anderen Waze-Nutzern über Verkehrssituation und sonstige Hindernisse. Karten werden von den Usern editiert, Basiskartenmaterial ohne Straßennamen und Routinginformationen wie Einfahrtserlaubnis ist in Deutschland aber auch ohne User-Edits vorhanden.
  Offboard-Lösung.
  Einen ausführlichen Bericht zu waze findest Du hier.

Soweit die Übersicht. Gebt bescheid, falls ich etwas vergessen habe.

Letztes Update: 11. 8. 2010

Schon auf dem iPhone hatte ich überlegt, mein TomTom GO 720 durch das iPhone zu ersetzen. Letztlich konnte ich mich zu dem Schritt aber nicht durchringen, da das TomTom dank IQRoutes 2 meist ganz gute Routen liefert, die mit Navigtionssoftware ohne Geschwindigkeitsdatenbank kaum erreichbar ist. TomToms eigene Navigationsanwendung fürs iPhone konnte zunächst, gelinde gesagt, kaum begeistern.
Als die anderen Anbieter dann mit Geschwindigkeitsdatenbanken nachzogen und auch TomToms iPhone-App sich zu steigern begann, war ich schon auf der Suche nach einem besseren Ersatz für das iPhone und sah mich insofern nicht weiter um.
Jetzt geht unter Android das gleiche Spielchen los. Das Kriterium ist und bleibt: Entweder ich bekomme für relativ viel Geld eine Applikation, die es von Qualität der Routen her mit TomTom aufnehmen kann, oder ich bekomme für sehr wenig Geld (< € 10,–) etwas, was zumindest korrekte, wenn auch vielleicht nicht perfekte Routen bietet.
POI-Datenbanken nutze ich kaum, sie sind für mich also eher nicht von Interesse. Auch interessieren mich „Wo sind meine Freunde“-Dienste nicht, da ich weder ständig meine eigene Position veröffentlichen möchte, noch Freunde habe, die das tun würden. Außerdem gibt es dafür spezialisierte Dienste, die es vmtl. besser können, etwa Google Latitude oder Foursquare.
Hier ein Kurzüberblick zu den (teils auch noch nicht oder nicht mehr) erhältlichen Optionen.
Interessant finde ich wegen meines eigenen Routing-Projekts vor allem die Programme, die mit Openstreetmap-Daten arbeiten. Wie schon erwähnt sind diese Daten nur bedingt für Routing geeignet. Spannend, was mit guter Programmierung trotzdem herausgeholt werden kann.
In alphabetischer Reihenfolge:

• AndNav2: Routing auf OSM-Basis in Zusammenarbeit mit OpenRouteService.org. Nur Online-Routing, fürs Ausland also nicht geeignet. Schön klingen die Features zum Meiden bestimmter Bereiche und zum Darstellen aller vom aktuellen Ort aus in bestimmter Zeit erreichbaren Orte.
  Stand heute leider keine Berücksichtigung von Abbiegeverboten.
• CoPilot Live: Liegt wohl genau zwischendrin – weder richtig billig noch richtig teuer/gut. :-) Nutzt NavTeq-Kartenmaterial, damit also Profi-Routingmaterial, aber scheinbar ohne reale Geschwindigkeitsdaten für die Straßen. Das heißt: Vmtl. keine TomTom-Qualität, aber das Niveau normaler Navigationsgeräte der letzten Jahre. Verkehrsnachrichten sind als kostenpflichtiger Premium-Dienst verfügbar; einige weitere Goodies wie das verfolgen anderer CoPilot-User auf der Karte.
  Für diesen Qualitätslevel zu sehr günstigen Preisen zu haben.
• Google: Kostenlose Turn-by-Turn-Navigation mit Google Maps. Offboard-Lösung, nur mit Internetverbindung benutzbar. Wie auch im Online-Angebot von Google sind die Routen nicht immer optimal, aber für kostenlose Navigation ist das Angebot mehr als nur in Ordnung.
• MotoNav: Liegt auf Motorola Milestones als 60-Tage-Testversion bei. Es handelt sich um eine leicht veränderte Version der iGo-Navigationssoftware aus dem Hause NNG, die in Deutschland nur in vorinstallierter Version auf dem Milestone zu haben ist.
  Als OnBoard-Lösung verbraucht es während der Nutzung keinerlei Daten.
• Nav4All: Der Vollständigkeit halber: War bis Januar erhältlich/funktionstüchtig und soll ganz gut gewesen sein. Kostenlose Navigation mit Navteq-Kartenmaterial. Die Lizenz zur Nutzung des Kartenmaterials wurde von Navteq (hundertprozentige Nokia-Tochter) entzogen, kurz bevor Nokia seine eigene, kostenlose Navigationslösung präsentierte. Ein Schelm, wer Böses dabei denkt.
• Navigon Mobile Navigator: Sieht auf den ersten Blick nach dem derzeit komplettesten (und teuersten) Angebot für Android aus. Die MyRoutes-Funktion klingt sehr interessant: Da sollen die Routen nicht nur nach Tageszeit, sondern auch nach einem nach und nach von der Software erstellten Profil des Fahrers berechnet werden. Außerdem werden bis zu drei Alternativen vorgeschlagen. Klingt wirklich gut und geht sogar noch weiter als TomToms IQRoutes 2 – mal sehen, ob es auch etwas taugt. Allerdings scheinen keine Verkehrsinformationen verfügbar zu sein.
  Netterweise gibt es eine 30-Tage-Testversion.
• NavDroyd: OnBoard-Lösung, Karten werden also auf dem Gerät gespeichert. Umfangreiches, weltweites Kartenmaterial basierend auf OpenStreetmap steht zur Verfügung. Für kommerzielle Anwendung gibt es offenbar auch die Möglichkeit, bereits lizensiertes, kommerzielles Kartenmaterial z.B. von NavTeq zu nutzen. Für normale Endkunden gibt es diese Option aber nicht.
  Günstiger Preis (derzeit € 4,99) für eine OnBoard-Lösung, schöne Kartendarstellung.
  Wird momentan anscheinend fleißig weiterentwickelt, häufige Updates. Laut Website derzeit noch keine Berücksichtigung von Abbiegeverboten, die allerdings noch kommen soll.
• Navit: OSM-Karten im binären Format für Offline-Routing. Allgemeines Linux-Routing, das auch für Android verfügbar ist. Klingt als wäre es für den täglichen Einsatz und von der Konfiguration her noch nicht so einfach benutzbar wie andere Systeme. Dieses Urteil stammt aber ausschließlich von etwas Wiki-Studium, ich habe mir die tatsächliche Anwendung noch nicht angesehen.
• OsmAnd: Komplett kostenlose Open-Source-Navigation samt Helfer für OSM-Karteneditierer. Bislang noch eine 0.x-Version, sieht aber sehr vielversprechend aus, zumal die Karten OnBoard gespeichert werden können.
  Die Routenberechnung für die Navigation selbst läuft aber ausschließlich über Online-Anbieter, konkret werden bislang CloudMade (wie bei Skobbler) und YOURS unterstützt. Beide reißen mich von den generierten Routen her nicht zu Jubelstürmen hin, sind aber durchaus nutzbar.
  Einen Blick ist diese Lösung mit Sicherheit wert, vor allem für OSM-Enthusiasten.
• Skobbler: Navigation mit Extras, Community-Features speziell im Bereich POIs. Die Android-Version ist seit einiger Zeit offiziell erhältlich, bislang noch kostenlos.
  In der iPhone-Version mit Navteq-Kartenmaterial gab es Druck von Navigon, u.a. deshalb wurde vor Kurzem auf OSM-Kartenmaterial umgeschwenkt. Die Firma war ursprünglich eine Ausgründung von Navigon selbst; die Programmierer dürften sich also mit Routing auskennen. Genutzt wird allerdings CloudMade-Routing, das ich persönlich für nicht so wahnsinnig toll halte (zu autobahnfixiert, z. B.). Im Gegensatz zu vielen anderen OSM-basierenden Routinglösungen werden dort allerdings immerhin Abbiegeverbote berücksichtigt.
  Zumindest geplant ist nicht nur Online-Routing, sondern auch die Möglichkeit zum Abspeichern von Kartenbereichen, um sie ohne Internetverbindung nutzen zu können.
  Ein Rückkanal zu Openstreetmap.org ist vorhanden, um Kartenverbesserungen zu erleichtern.
  Wo Skobbler für Android preislich letztlich liegen wird, weiß ich nicht – angesichts der mittlerweile erwachsenen Konkurrenz durch kostenlose Google-Maps-Navigation ist fraglich, ob sich mehr als „werbefinanziert“ überhaupt wird durchsetzen lassen.
• Sygic Mobile Maps: TeleAtlas-Kartenmaterial. Soweit ich das bisher überblicke der einzige Anbieter, der kostenlos Verkehrsinformationen bietet (allerdings keine live gsammelten Infos anderer Nutzer, sondern TMC-artige Informationen von Polizei und Verkehrsüberwachung). Preislich auf dem Niveau des derzeit verbilligten Navigon-Systems (Europa-Karte € 60,–).
• Telmap Navigator: Offboard-Lösung (nur Online) mit Navteq-Datenmaterial, wird evtl. bald auf TeleAtlas umgestellt. ADAC-Verkehrsinformationen. (Ob die nur angezeigt oder zum Routing benutz werden, ist mir nicht ganz klar.) TelMap wird nicht an Endkunden verkauft, sondern nur über Handyhersteller und Provider angeboten. In Deutschland ausschließlich für O2-Kunden erhältlich (abgesehen von den Datenverbrauchskosten kostenlos).
• TomTom: Ein TomTom-Sprecher hatte Mitte letzten Jahres von einer TomTom-App für Android gesprochen. Seitdem scheint sich aber nichts mehr getan zu haben.
• Waze: Community-Projekt, bei dem eine eigene Karte erstellt wird, die direkt fürs Routing gedacht ist. Straßen werden aus GPS-Logs erzeugt und enthalten auch direkt Geschwindigkeitsinformationen. Live-Informationen von anderen Waze-Nutzern über Verkehrssituation und sonstige Hindernisse. Karten werden von den Usern editiert, Basiskartenmaterial ohne Straßennamen und Routinginformationen wie Einfahrtserlaubnis ist in Deutschland aber auch ohne User-Edits vorhanden.
  Offboard-Lösung.
  Einen ausführlichen Bericht zu waze findest Du hier.

Soweit die Übersicht. Gebt bescheid, falls ich etwas vergessen habe.

Letztes Update: 11. 8. 2010

Navigation unter Android

Routenplanung mit Openstreetmap-Daten: Nicht so toll

Einfach aus Interesse, wie man so etwas am besten macht, und aus der Erfahrung heraus, dass alle erhältlichen Routenplaner bei weitem nicht so konfigurierbar sind, wie ich das gerne hätte, hatte ich Mitte letzten Jahres ein Projekt gestartet, um mir meinen eigenen Routenplaner fürs iPhone zu schreiben.
Weit kam ich damals nicht, schon der Import der Openstreemap-Daten aus den riesigen XML-Dateien scheiterte an dafür ungeeigneten Funktionen von Mac OS X. Ich hätte mich mit bekanntermaßen unangenehmen und unübersichtlichen C-Libraries befassen müssen, und meine Unlust darauf stoppte letztlich das Projekt.
Jetzt sieht es ganz anders aus: Mein iPhone habe ich abgeschafft und mir dafür das Nexus One zugelegt; entsprechend ist das Entwicklungsziel nicht mehr Mac OS X / iPhone OS mit Objective C, sondern Java.
Tatsächlich bin ich mittlerweile schon relativ weit: Ich kann OSM-Dateien importieren und auf deren Basis Routen erstellen, allerdings bislang nur auf dem Desktop und ohne grafisches UI. Zu tun ist als nächstes auch noch eine komplette Überarbeitung der genutzten Datenbankschemata, um die Performance weiter zu verbessern.
Soweit, so gut. Oder auch nicht.
Mittlerweile ist mir nämlich klargeworden, dass Openstreetmap-Daten nur sehr schlecht zur Erstellung von Routen geeignet sind. Dass man die Verbindungen von Node zu Node in einer Routing-Datenbank anders darstellen muss, ist ohnehin klar, aber ein anderes Problem ist viel schwerwiegender:
Es ist unmöglich, sicher herauszufinden, ob sich ein Straßenabschnitt innerhalb einer Stadt befindet oder nicht. Die in der OSM-Datenbank abgelegten Straßen sind ausschließlich auf eine gute Kartendarstellung hin optimiert, Routing spielte dabei offensichtlich nicht die geringste Rolle.
Dementsprechend hat eine Landstraße, die durch einen Ort führt, inner- und außerorts immer den gleichen Straßentyp. Nur Straßen in reinen Wohngebieten sind eindeutig gekennzeichnet, auf allen größeren Straßen wird keine Unterscheidung zwischen Stadtgebiet und außerorts getroffen.
Auf einer Seite des Openstreemap-Wiki werden zu diesem Problem einige Vorschläge gemacht, die aber allesamt reichlich ungeeignet sind:

• Ways (Straßen/Wege/Linien) sind praktisch nie mit is_in getaggt.
• Places als areas für ganze Städte/Gemeinden habe ich auf der Karte in meinem Umkreis noch überhaupt nicht gesehen.
• boundary=administrative mit admin_level=8 gibt es hier auch so gut wie nicht. Außerdem haben diese Gebiete normalerweise nichts mit den Grenzen zu tun, ab denen für den Verkehr 50 km/h gilt.
• Einfach alle landuse-areas, die nicht farm, quarry, forest oder water sind, als Stadt zu betrachten, ist Unsinn. Landuse=residential hilft manchmal bei Dörfern, bei denen entsprechende Grenzen eingetragen sind, vor allem, wenn hier TMC-Daten verarbeitet wurden. Leider gibt es bei weitem nicht für alle Dörfer solche Areas, und vor allem in Städten hilft das auch wenig weiter. Hier sind Wohnegbiete von Industriegebieten, Einkaufszentren und anderem getrennt, und die Straßen, die zwischen den Gebieten verlaufen, sind häufig weder Teil des einen noch des anderen.
• Irgendwelche Radien um place-Nodes herum als Abschätzung zu benutzen ist vielleicht besser als nichts, aber immer noch eine letztlich ungeeignete Krücke. Straßendörfer mit wenigen Einwohnern können kilometerlang, aber nur 50m breit sein, Städte > 100.000 Einwohner haben im Ruhrgebiet völlig andere Ausdehnungen als in einem ländlichen Ballungsraum usw.
• Als eigene Idee hatte ich noch, Straßen ohne Namen einfach als außerorts zu behandeln. Leider musste ich feststellen, dass in vielen Fällen im Kartenmaterial auch für außerstädtische Gebiete Straßen mit Namen angelegt sind, so dass auch diese Heuristik bei weitem nicht korrekt genug ist.

Fazit: Soweit man keine real gemessenen Geschwindigkeitsdaten zur Verfügung hat, muss Routing mit Openstreetmap-Daten immer schlechter sein als mit Daten, die von vorneherein für Routing ausgelegt wurden.
Natürlich war mein Plan schon immer, reale Geschwindigkeitsdaten zu sammeln. Auch wenn solche nicht vorhanden sind, sollte mein Routenplaner aber halbwegs sinnvolle Daten ausspucken, was mit diesem Datenmaterial aber eher als Glücksfall zu betrachten wäre.
Ich werde mich jetzt einmal umsehen, was kommerzielles, für Routing besser geeignetes Datenmaterial so kostet. Wenn das bezahlbar ist (also mit kleinen Preisen anfängt und von der Anzahl der verkauften Lizenzen abhängig ist), könnte es eine Alternative sein.
Ansonsten kann ich mich nur so nahe an die Realität herantasten, wie es Openstreetmap eben erlaubt, und hoffen, dass möglichst bald möglichst viele echte Geschwindigkeitsdaten von Usern gesammelt werden.

Einfach aus Interesse, wie man so etwas am besten macht, und aus der Erfahrung heraus, dass alle erhältlichen Routenplaner bei weitem nicht so konfigurierbar sind, wie ich das gerne hätte, hatte ich Mitte letzten Jahres ein Projekt gestartet, um mir meinen eigenen Routenplaner fürs iPhone zu schreiben.
Weit kam ich damals nicht, schon der Import der Openstreemap-Daten aus den riesigen XML-Dateien scheiterte an dafür ungeeigneten Funktionen von Mac OS X. Ich hätte mich mit bekanntermaßen unangenehmen und unübersichtlichen C-Libraries befassen müssen, und meine Unlust darauf stoppte letztlich das Projekt.
Jetzt sieht es ganz anders aus: Mein iPhone habe ich abgeschafft und mir dafür das Nexus One zugelegt; entsprechend ist das Entwicklungsziel nicht mehr Mac OS X / iPhone OS mit Objective C, sondern Java.
Tatsächlich bin ich mittlerweile schon relativ weit: Ich kann OSM-Dateien importieren und auf deren Basis Routen erstellen, allerdings bislang nur auf dem Desktop und ohne grafisches UI. Zu tun ist als nächstes auch noch eine komplette Überarbeitung der genutzten Datenbankschemata, um die Performance weiter zu verbessern.
Soweit, so gut. Oder auch nicht.
Mittlerweile ist mir nämlich klargeworden, dass Openstreetmap-Daten nur sehr schlecht zur Erstellung von Routen geeignet sind. Dass man die Verbindungen von Node zu Node in einer Routing-Datenbank anders darstellen muss, ist ohnehin klar, aber ein anderes Problem ist viel schwerwiegender:
Es ist unmöglich, sicher herauszufinden, ob sich ein Straßenabschnitt innerhalb einer Stadt befindet oder nicht. Die in der OSM-Datenbank abgelegten Straßen sind ausschließlich auf eine gute Kartendarstellung hin optimiert, Routing spielte dabei offensichtlich nicht die geringste Rolle.
Dementsprechend hat eine Landstraße, die durch einen Ort führt, inner- und außerorts immer den gleichen Straßentyp. Nur Straßen in reinen Wohngebieten sind eindeutig gekennzeichnet, auf allen größeren Straßen wird keine Unterscheidung zwischen Stadtgebiet und außerorts getroffen.
Auf einer Seite des Openstreemap-Wiki werden zu diesem Problem einige Vorschläge gemacht, die aber allesamt reichlich ungeeignet sind:

• Ways (Straßen/Wege/Linien) sind praktisch nie mit is_in getaggt.
• Places als areas für ganze Städte/Gemeinden habe ich auf der Karte in meinem Umkreis noch überhaupt nicht gesehen.
• boundary=administrative mit admin_level=8 gibt es hier auch so gut wie nicht. Außerdem haben diese Gebiete normalerweise nichts mit den Grenzen zu tun, ab denen für den Verkehr 50 km/h gilt.
• Einfach alle landuse-areas, die nicht farm, quarry, forest oder water sind, als Stadt zu betrachten, ist Unsinn. Landuse=residential hilft manchmal bei Dörfern, bei denen entsprechende Grenzen eingetragen sind, vor allem, wenn hier TMC-Daten verarbeitet wurden. Leider gibt es bei weitem nicht für alle Dörfer solche Areas, und vor allem in Städten hilft das auch wenig weiter. Hier sind Wohnegbiete von Industriegebieten, Einkaufszentren und anderem getrennt, und die Straßen, die zwischen den Gebieten verlaufen, sind häufig weder Teil des einen noch des anderen.
• Irgendwelche Radien um place-Nodes herum als Abschätzung zu benutzen ist vielleicht besser als nichts, aber immer noch eine letztlich ungeeignete Krücke. Straßendörfer mit wenigen Einwohnern können kilometerlang, aber nur 50m breit sein, Städte > 100.000 Einwohner haben im Ruhrgebiet völlig andere Ausdehnungen als in einem ländlichen Ballungsraum usw.
• Als eigene Idee hatte ich noch, Straßen ohne Namen einfach als außerorts zu behandeln. Leider musste ich feststellen, dass in vielen Fällen im Kartenmaterial auch für außerstädtische Gebiete Straßen mit Namen angelegt sind, so dass auch diese Heuristik bei weitem nicht korrekt genug ist.

Fazit: Soweit man keine real gemessenen Geschwindigkeitsdaten zur Verfügung hat, muss Routing mit Openstreetmap-Daten immer schlechter sein als mit Daten, die von vorneherein für Routing ausgelegt wurden.
Natürlich war mein Plan schon immer, reale Geschwindigkeitsdaten zu sammeln. Auch wenn solche nicht vorhanden sind, sollte mein Routenplaner aber halbwegs sinnvolle Daten ausspucken, was mit diesem Datenmaterial aber eher als Glücksfall zu betrachten wäre.
Ich werde mich jetzt einmal umsehen, was kommerzielles, für Routing besser geeignetes Datenmaterial so kostet. Wenn das bezahlbar ist (also mit kleinen Preisen anfängt und von der Anzahl der verkauften Lizenzen abhängig ist), könnte es eine Alternative sein.
Ansonsten kann ich mich nur so nahe an die Realität herantasten, wie es Openstreetmap eben erlaubt, und hoffen, dass möglichst bald möglichst viele echte Geschwindigkeitsdaten von Usern gesammelt werden.

Routenplanung mit Openstreetmap-Daten: Nicht so toll