[Talk-de] Entwicklung MoNav
Christoph Eckert
ce at christeck.de
So Okt 23 21:11:52 UTC 2011
Moin Jungs,
auch wenn es schon fast zwei Jahre her ist, dass ich hier auf der Liste
gepostet habe, möchte ich das Thema mal aufgreifen.
> Weiter oben im alten Thema wurde das Problem mit den hohen
> Einstiegshürden aufgezeigt, das sehe ich genau so. Die Einarbeitungszeit
> um sich in die Gedanken eines anderen einzuarbeiten ist einfach zu lang.
Der Code von MoNav ist außerordentlich leserlich, und der Maintainer
beantwortet alle Fragen auf der Mailingliste äußerst präzise.
> Es ist doch schade, da macht sich jemand an die Arbeit und schreibt
> z.B. ein Navi, da geht dann mehr Zeit rein als gedacht und die Arbeit
> wird eingestellt.
Die Arbeit an MoNav ist nicht eingestellt. Es gibt aber recht wenig
Entwickler, und wenn die Monate lang ihre Freizeit investiert haben, möchten
die vielleicht auch mal Pause machen dürfen. Zudem reift in mir die
Erkenntnis, dass zwei Leute in ihrer Freizeit ein Projekt wie MoNav nicht
alleine stemmen können.
> *** in möglichst viele abgeschlossene Module aufgetrennt sein, mit
> dokumentierter Schnittstelle. Geht das überhaupt? Na, wenn nicht, das
> Umdokumentieren nicht vergessen.
MoNav ist äußerst modular aufgebaut. Die beste Doku, die ein Programmierer
schreiben kann, ist lesbarer Code. Vergiss Doku oder Kommentare im Code, die
nicht zum Code passen.
> *** für Neulinge dokumentiert sein. Ich meine grundsätzliche Dinge
> sollten erklärt werden.
Die Doku muss jemand auch irgendwann schreiben, und vor allem muss sie
hinterher auch synchron gehalten werden. Wenn ich mich entscheiden muss, ob
ich lieber Doku oder lesbaren Code schreibe, entscheide ich mich für den Code.
Lesbarer Code ist bei MoNav der Fall, dafür wirst Du doku oder Kommentare
weitestgehend vergeblich suchen. Man guckt also in den Code, fängt an kleinere
Bugs zu fixen, dann kleinere Features einzubauen, und irgendwann hat man
kapiert, wie das Ding tickt, und kann an die großen Brocken gehen. Wer das
nicht schafft, wird es auch mit Doku nicht schaffen.
> *** die alten Mitarbeiter im Projekt sollten für Neulinge Arbeiten
> definieren, beschreiben und die Einstiegspunkte aufzeigen.
> Das dient alles dazu einem Interessierten den Einstieg zu erleichtern
> und zu motivieren dabei zu bleiben.
Auf Sourceforge gibt es solche "Stellenausschreibungen". Die führen mitnichten
dazu, dass sich Leute begeistert zur Mitarbeit melden. Die Motivation zur
Mitarbeit kommt nämlich nicht von einer Stellenausschreibung, sondern davon,
dass Leute in ihrer Freizeit eine Herausforderung suchen, die sie anspricht.
> Kann das funktionieren? Keine Ahnung! Aber ich würde es so versuchen.
Als einer, der es versucht hat, empfehle ich, Deine Freizeit lieber woanders
zu investieren :) .
> Wie ist es, wollen wir versuchen ein Navi herzustellen? Hat jemand Lust
> mitzumachen?
Du wirst erstens nicht allzu viele MItstreiter finden, und zweitens wirst Du
nur ein weiteres Projekt aufmachen, dass dann irgendwann genauso tot ist wie
viele andere.
> Wie wollen wir starten? Fangen wir von vorne an und arbeiten Teile von
> monav oder gosmore ein oder bauen wir auf monav auf oder...
Ich habe im Laufe der Zeit an vielen Routern 'rumgebastelt (Gosmore, Routino,
Navit, MoNav, …). MoNav erschien mir letztendlich am vielversprechendsten,
weshalb ich im letzten Winter etliche Monate an Arbeit investiert habe. Es
gibt verschiedene Builds, Installer und vorberechnetes Kartenmaterial, so dass
möglichst viele Leute damit 'rumspielen können. Unter anderem habe ich einen
Windowsinstaller gebaut, obwohl ich Windows gar nicht nutze. Auf der
Mailingliste schlagen inzwischen auch Leute auf. Die fragen dann aber
bevorzugt, ob es nicht Unterstützung und Installer für Plattform X geben
könnte. Wir brauchen aber Leute, die nicht danach fragen, sondern es machen.
Hier ein paar Infos zu MoNav:
* Läuft auf jeder Plattform, die Qt4 und QtMobility unterstützt. Auf Android
kriegt man es wohl irgendwie zum Laufen, aber es ist Gebastel. Auf Windows
Phone wird es nie laufen, weil man dort keinen nativen Code laufen lassen
kann.
* Die Suche und das Routing auf dem N900 sind überragend schnell. So will man
es haben. Sprich die Kernfunktionalitäten sind gelöst. Eigentlich braucht es
jetzt "nur noch" Leute, die das ganze zu einer endanwendertauglichen
Applikation machen. Das motiviert aber Entwickler üblicherweise nicht, denn
die suchen nach Herausforderungen, nicht nach Fleißarbeit.
* Die OSM-Daten eigenen sich nicht für eine Routingsoftware. Wir wissen nicht,
zu welcher Stadt eine Straße nun wirklich gehört, wir wissen nicht, welche
Straßen innerstädtisch und welche außerorts verlaufen, wir haben keine
Hausnummern und keine Postleitzahlen. Unsere Straßen sind komplett
zerhäckselt, weshalb man potentiell viel zu viele Weghinweise erhält.
Der zweite Punkt ist nicht wirklich superschlimm, der erste aber auf jeden
Fall, und die beiden vorletzten ließen sich theoretisch verschmerzen, stehen
aber einer Endanwendertauglichkeit im Wege. Richtig schlimm ist der letze
Punkt, weil man den Präprozessor extrem aufbohren müsste, um zerhackte Straßen
wieder zusammenzusetzen - und das wird immer ein Gemurkse bleiben.
* Die ToDo-Listen des Maintainers und meiner Wenigkeit sind ellenlang. Ich
liste einfach mal ein paar Dinge auf:
- MoNav aktualisiert im Moment die Route jedes Mal, wenn eine neue GPS-
Position anlandet (derzeit einmal pro Sekunde). Dadurch werden auch die
Abbiegehinweise am Bildschirm einmal pro Sekunde aktualisiert, was nicht
weiter auffällt. Für die Sprachausgabe ist das aber unbrauchbar, sprich da
"müsste mal jemand" (man nennt sowas das Partnerschaftspassiv) etwas mehr
Intelligenz einbauen.
- MoNav müsste lernen, wo man sich auf der Route befindet. Kann es derzeit
nicht, weil es ob der Geschwindigkeit die Route permanent neu berechnen kann.
- MoNav müsste lernen, nicht nur selbst berechnete Routen zu nutzen, sondern
auch eingeladene, die man sich aus dem Web gezogen hat.
- Für Radrouting möchte man SRTM-Daten mit einrechnen. Da ist schon was
angefangen, aber der aktuelle Status ist mir nicht klar.
- Sprachausgabe. Das ist eines der wichtigsten Features überhaupt. Ich habe
aber bewusst nicht damit angefangen, denn das ist ein Monstertask. Die
Audioausgabe an sich ist Dank Qt sehr einfach. Aber es hinzubekommen, dass im
rechten Moment die Abbiegehinweise kommen, erfordert sehr viel Feinarbeit, die
wenig spannend ist. Abbiegehinweise auf der Landstraße sind natürlich trivial.
Spannend wird es im Stadtverkehr, in Kreiseln und so weiter.
Es gibt noch weitere Wunschfeatures, aber solange wir kein vernünftiges
Routing haben, brauchen wir uns eigentlich nicht weiter unterhalten.
IMO ist die Sache ganz einfach. Wenn Routing auf Mobilgeräten für uns wirklich
wichtig wäre, dann hätten sich schon zahllose Leute auf MoNav (oder Navit
etc.) gestürzt und es gebaut. Es ist also nicht wichtig, und somit werden alle
Offline-Routingprojekte in wenigen Jahren eingeschlafen sein, weil wir dann alle
überall permanent online sind und sowas über Webservices machen - und das
werden voraussichtlich kommerzielle sein.
--
Beste Grüße,
Best regards,
ce
Mehr Informationen über die Mailingliste Talk-de