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 _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de