Re: [Talk-de] Entwicklung MoNav
Man muss nicht im Kommentar schreiben was die Quellkode tut, sondern warum sie es so tut. Jo 2011/11/7 Christoph Eckert : > Moin, > >> Ich stimme Dir zu, dass Kommentare in Quellcode durchaus sinnvoll sind. Ich >> mache das in der Regel so, dass ich dann Kommentare in den Code schreibe, >> wenn einem anderen beim lesen nicht gleich klar werden kann was ich mir >> dabei gedacht haben könnte. Das ist natürlich subjektiv, aber ich denke >> wenn man selber der MEinung ist oh, das versteht ein fremder nicht, dann >> schadet ein Kommentar im Code ganz bestimmt nicht. > > +1 > > Das sind dann die Kommentare, die wahrgenommen werden und die ungemein helfen. > Viele Kommentare, die ich lese, sind aber schlicht nur Füllmaterial. > > -- > Beste Grüße, > Best regards, > > ce > > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entwicklung MoNav
Moin, > Ich stimme Dir zu, dass Kommentare in Quellcode durchaus sinnvoll sind. Ich > mache das in der Regel so, dass ich dann Kommentare in den Code schreibe, > wenn einem anderen beim lesen nicht gleich klar werden kann was ich mir > dabei gedacht haben könnte. Das ist natürlich subjektiv, aber ich denke > wenn man selber der MEinung ist oh, das versteht ein fremder nicht, dann > schadet ein Kommentar im Code ganz bestimmt nicht. +1 Das sind dann die Kommentare, die wahrgenommen werden und die ungemein helfen. Viele Kommentare, die ich lese, sind aber schlicht nur Füllmaterial. -- Beste Grüße, Best regards, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entwicklung MoNav
Nochmal ein paar Gedanken aus dem Marble-Off: Wir bieten in Marble ja auch einen recht ausgeklügelten Navi-Modus an. Es gibt in Marble derzeit noch keinen echten OpenGL 3D-View aber wir arbeiten in die Richtung und werden wahrscheinlich in den nächsten Monaten schon so etwas anbieten können. In Marble verwenden wir für unseren Navi-Mode ein Plugin-System, das es erlaubt beliebige Routing Backends parallel abzufragen. Routing Backends können dabei Offline Lösungen oder Online Lösungen sein. Marble unterstützt bei Offline Lösungen derzeit Gosmore, Routino und das Monav Backend. Als Online Lösung werden z.B. OpenRouteService und Yours unterstützt. Wenn die Plugins auf die Suche antworten, wird das beste Ergebnis ausgewählt. Damit sind wir nicht an den Erfolg einer einzelnen Navi-Backend-Lösung gebunden und können dem Nutzer eine Mischung aus schnellen Offline-Ergebnissen und aktuellen Web-Ergebnissen bieten. Daneben unterstützen wir natürlich auch Dinge wie Drag and Drop, alternative Routen, Turn-By-Turn Instructions, Routenneuberechnung, internationalisierte Sprachausgabe http://edu.kde.org/marble/speakers.php und vieles mehr. Wer genaueres zu diesen Themen wissen möchte, kann sich gerne Dennis' Blog anschauen: http://nienhueser.de/blog/ Gerade hat Niko Sams auch ein schönes Blog dazu geschrieben, wie wir beginnen Höhendaten mit einzubeziehen. http://nikosams.blogspot.com/2011/10/marble-elevation-profile-for-route.html Da Marble auch gleichzeitig eine reine Qt-Bibliothek ist, lässt sich die gesamte Marble-Funktionalität auch in eigenen Programmen verwenden. Ist Marble damit ein echtes Navi? Das hängt sicherlich davon ab, was man erwartet. Die Marble-Applikation versteht sich ja vom Grundansatz her quasi als schweizer Taschenmesser für Kartendarstellung. Davon profitieren wir natürlich auch in puncto Entwicklungsmodell, denn damit fällt für den Navi-Mode immer wieder automatisch Funktionalität ab, die eigentlich für einen ganz anderen Use-Case von Marble gestrickt wurde. Das gleiche gilt auch in puncto Plattform: Leute, die eigentlich Marble für den Desktop verbessern wollen (Windows, Mac, Linux), verbessern oft automatisch auch unsere Nokia N900 bzw. Nokia N950 / N9 Version gleichzeitig mit. Das gleiche gilt natürlich auch über den Code hinaus: da wir organisatorisch ins KDE-Projekt eingebettet sind, profitieren wir - und damit auch unser Navi- Modus - von dem KDE Übersetzungsteam, der "angeschlossenen" Doku-Abteilung und dem KDE Marketing. All diese Peripherie aus Leuten, die vielleicht gar nicht unbedingt ein direktes Interesse an der Navi-Funktionalität besitzen, hilft dabei eine Software zum vollständigen Produkt zu machen. Das müsste sich ein eigenständiges Navi-Projekt selbst "erarbeiten" und dafür Leute begeistern. Das ist sicherlich möglich - aber ein langer steiniger Weg. Viele Grüße, Torsten On Sunday, 23. October 2011 23:11:52 Christoph Eckert wrote: > 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. > - 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
Re: [Talk-de] Entwicklung MoNav
hannes wrote: >> 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. >> > Ich meine so etwas: > "OSM fragmentiert Straßen. Diese Funktion versucht sie wieder zusammen > zu setzen." > Klar, das geht auch mit: void defragstreet (map *m) > Die Frage ist doch könnte ein Neuer hier auf eine falsche Fährte > gelangen? (Schlechtes Beispiel, es ist tatsächlich klar wenn man OSM > Daten kennt.) Ich stimme Dir zu, dass Kommentare in Quellcode durchaus sinnvoll sind. Ich mache das in der Regel so, dass ich dann Kommentare in den Code schreibe, wenn einem anderen beim lesen nicht gleich klar werden kann was ich mir dabei gedacht haben könnte. Das ist natürlich subjektiv, aber ich denke wenn man selber der MEinung ist oh, das versteht ein fremder nicht, dann schadet ein Kommentar im Code ganz bestimmt nicht. Gruss Sven -- "Every time you use Google, you're using a Linux machine" (Chris DiBona, a programs manager for Google) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entwicklung MoNav
Am 23.10.2011 23:11, schrieb Christoph Eckert: 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. Sehe ich auch so aber der Einstieg sollte leicht sein, damit sich der Interessierte Entwickler möglichst festliest. Zu MoNav gibt es eine Diplomarbeit, damit sollte das Thema erledigt sein. Ich werde sie demnächst lesen. 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. Ich meine so etwas: "OSM fragmentiert Straßen. Diese Funktion versucht sie wieder zusammen zu setzen." Klar, das geht auch mit: void defragstreet (map *m) Die Frage ist doch könnte ein Neuer hier auf eine falsche Fährte gelangen? (Schlechtes Beispiel, es ist tatsächlich klar wenn man OSM Daten kennt.) Lesbarer Code ist bei MoNav der Fall, stimmt 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. Es mir geht nicht ums schaffen, sondern ums Programmierer fangen. (Ich hab nichts dagegen gefangen zu werden und hoffe dass noch viele in die Falle gehen.) *** 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. Ich glaube so beginnt man ein Projekt, eine echte Herausforderung - erst einmal richtig gute Arbeit machen und dann mehr Leute hinzugewinnen die beim Programmieren helfen. Ich glaube sich in ein Team einzuordnen hat braucht eine andere Motivation. Und wenn man nun versucht die Leute mit überschaubaren Aufgaben zu ködern? 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. Ich bin nicht dafür ein neues Projekt anzufangen und suche auch keine Mitstreiter, bin eher einer. Hannes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entwicklung MoNav
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 Endanwendertauglich
