Machbarkeitsstudie: OpenSource Navi-System

Willkommen!

Wenn du im Nexave-Forum mitmachen möchtest, schreib an community@nexave.de. Wir haben die Registrierungsfunktion in unserem Diskussionsforum nämlich deaktiviert, weil sich praktisch nur noch Spammer und Werbebots registriert haben. Per E-Mail sind wir dir gern behilflich, einen Account anzulegen.

    Also, meine Programmiererzeit ist lange lange her, ich habe im Rahmen meines vergeblichen Studienversuchs die ganzen Informatik-Klassiker der frühen 90er durch (C, C++, Modula2, Lisp/Scheme) und würde für den Routenalgorithmus erstmal in meinen Erinnerungen kramen, vor allem der Name Dijkstra ist mir noch geläufig (das Problem des Handelsreisenden, im Prinzip die Kleinvariante einer Routenberechnung). Wie einen Satz weiter oben erwähnt, ist's lange lange her. Motivation ist vorhanden. Ich bin mir nur völlig im unklaren an welcher Stelle ich anfangen soll mir Gedanken zu machen.


    Zu allererst sollte das Projekt modularisiert werden, damit ersichtlich wird, was delegiert werden kann. Nach Linux-Vorbild halte ich die Idee, daß der Kreator dieser Idee (leupin) diesen Part übernimmt, für gut. Aufs Geradewohl drauflosprogrammieren halte ich für keine gute Idee... ;)


    motivierte Grüße


    codefish


    p.s. ich werde das ganz sicher nicht in Lisp oder Scheme programmieren!


    *grins*


    edit: http://de.wikipedia.org/wiki/Dijkstra-Algorithmus

    History: Vx(2001), IIIc(2001), m505(2002), Treo 680 (12/2006) ... Zodiac2 (04/2007) ... und danach?? Warten wir's ab :)

    2 Mal editiert, zuletzt von codefish ()

    Zitat

    Original von friesenschraube
    also ich könnt uech gern untersützten, kann bissle java programmieren, kann mir ja evtl. noch jemand mithelfen, dann läufts auch auf javafähigen handys, laptops und pdas auch


    die sprachausgabe/einagbe wäre auch wat nettes, owbei ich bei eingabe erstmal denk, wir sollten erst ne vernünftige sausgabe hinkriegen, also z.b. textotospeech für straßennamen


    Genau, friese, du programmierst jetzt das beste Naviprogramm der Welt, wie wärs? Ich bin gespannt!

    Da es noch keine eigene Mailingliste für dieses Projekt gibt, mißbrauche ich diesen Thread einfach, um Gedanken abzulassen.


    - Kartographie: soll da was Fremdes genommen werden oder soll auch das in Eigenregie passieren?


    Zu Eigenregie die Idee, daß auf jeden Fall Programmodule existieren müssen, die jedem User das halb- oder dreiviertelautomatische Datalogging ermöglichen (nur "dreiviertel" weil die Straßennamen und -typen auf jeden Fall manuell eingegeben oder korrigiert werden müssen, zumindest am Anfang). Die Wegpunkte könnten in einer Datenbank zusammengefaßt werden, die nach Vorbild der Musikdatenbank "freedb" gepflegt wird: jeder trägt ein, die Kartendaten werden als Mittelwert der gemeldeten Punkte berechnet und durch eine Automatik alle 24 Stunden aktualisiert.


    Das ganze muß vollautomatisch ablaufen. Niemand der freiwilligen Helfer (und jeder, der das System nutzt, wird automatisch Helfer) wird bereit sein, ständig Kartendaten zu pflegen.


    Dies als Gedanke. Ich habe noch keinen Kontakt zu irgendeinem reell existierenden Hersteller gehabt und weiß daher nicht, wie das in den aktuellen kommerziellen Produkten gelöst ist. Sollte aber schon 'ne eigene Idee sein, damit's keine Copyrightprobleme gibt.


    Mitdenkende Grüße


    codefish

    History: Vx(2001), IIIc(2001), m505(2002), Treo 680 (12/2006) ... Zodiac2 (04/2007) ... und danach?? Warten wir's ab :)

    Hallo zusammen,
    ...na, dann bin wohl ich daran, hier einige Antworten zu geben ... ;)


    Zuerst mal zur Mailingliste oder zur direkteren Kontaktaufnahme:
    ich bin aktuell dabei, die Webdomain leupinfo.ch von gospel.ch völlig abzukoppeln (momentan ist leupinfo rein eine Alias-Domain...) und beabsichtige, sobald dies abgeschlossen ist, ein eigenes phpBB-Forum zum Projekt auf leupinfo aufzuschalten, in dem gewisse Punkte relativ weit gestreut diskutiert werden können. Weiterhin will ich dann für angemeldete Entwickler für einen Teilbereich der Webseite einen ftp-Zugang einrichten, wo relativ einfach Programmteile etc. ausgetauscht werden können. Dannist es dann auch sinnvoll, Mailinglisten zu generieren...


    Aber bis jetzt war das ganze Projekt ja noch immer in der Phase der Machbarkeitsstudie, ;), aus der es jetzt dank dem doch steigenden Interesse doch herauszuwachsen scheint...


    Hinsichtlich Definition der verschiedenen Module: ich werde bei nächster Gelegenheit die Webseite anpassen und dort eine Übersicht der Module (aufgeteilt in drei Ebenen) geben, welche meiner Meinung nach entweder grundsätzlich für das Projekt notwendig sind, oder allenfalls auch mögliche Zusatzoptionen darstellen.
    Die drei Ebenen sehe ich wie folgt:
    Ebene 1: hier sind das/die Modul(e) angesiedelt, welche die Datenkonversion von existierenden Strassen-/Kartographiedaten (möglich sind da sowohl kommerzielle Anbieter wie Navteq oder Teleatlas, aber auch OpenSourceAnbieter wie OpenStreetMap) in ein für die OpenGPScout-Anwendung möglichst geeignetes Format ermöglichen.
    Ebene 2: hier sind alle plattform- und OS-unabhängigen Module für die Routenberechnung, die Suche nach Start- und Zieladressen und der Routenfolgealgorithmus angesiedelt.
    Ebene 3: diese Ebene umfasst die Module, welche Plattform- resp. OS-abhängig sind, beispielsweise das Kartendarstellungsmodul, die Interfaces zu GPS-Empfänger, Handy oder evt. TMC-Empfänger, die Eingabemodule für Start und Zielwahl, Berechnungsoptionen etc.


    Notwendig ist dann natürlich auch eine Definition der Interfaces zwischen den verschiedenen Modulen - aber wie gesagt, ich möchte das Ganze auf der Webseite dann entweder in Tabellenform oder graphisch noch ausführlicher und detaillierter darstellen.


    Aktuell bin ich mal davon ausgegangen, dass die ganze Programmierung primär unter C++ erfolgt, es sollte aber an sich auch kein Problem sein, diese Module dann je nach Bedarf z.B. in Java umzuschreiben, um primär Java-basierte Geräte zu unterstützen. (Interessant wäre in diesem Zusammenhang sicher auch, ob es auf irgend eine Weise gelingen würde, ein solches Programm auf einem iPhone zum Laufen zu bringen - dort wäre dann aber irgend eine AJAX-Programmierung angesagt...)


    Hinsichtlich Kartographie: hier existiert - wie oben angetönt - bereits ein OpenSource-Projekt, nämlich OpenStreetMap. Ich denke, hier sollte das Rad nicht doppelt erfunden werden und - sofern die dort vorhandenen Daten genügend sind - entweder auf die dort geleistete Arbeit zurückgegriffen werden oder aber alternativ oder parallel dazu die Möglichkeit geschaffen werden, kommerziell verfügbares Kartenmaterial einzusetzen (dafür wären, wie gesagt die Konversionsmodule in Ebene 1 gedacht - im Prinzip wäre es dort möglich, für verschiedenstes Ursprung-Kartenmaterial geeignete Routinen zu schreiben, wobei dann bei kommerziellem Material natürlich die Frage der Lizenzierung des Materials zu lösen wäre).


    Hinsichtlich Sprachausgabe: dieser Punkt ist sicher wichtig, hat aber (zumindest für mich) erst mal nicht oberste Priorität - ich denke, zuerst einmal muss überhaupt eine Version mit absoluten "Grundfunktionen" stabil laufen, anschliessend können dann flexibel weitere Module angekoppelt werden, sofern die Interfaces von Anfang an genügend offen gestaltet werden...


    Soviel im Augenblick - ich hoffe, dass ich möglichst bald die eigene Webseite geeignet umgestalten und ausbauen kann...


    Mit herzlichen Grüssen aus der Schweiz
    Andreas

    ...Ebene 2:


    Ich mache mir Gedanken über die Routenberechnung.


    Wenn das plattformunabhängig existieren soll, bleibt alleine beim Vergleich Palm->PC nur Java als Möglichkeit. Und da ergibt sich schon die Frage: auf welche Weise kann ich per Java auf die Kartendaten zugreifen?


    In C++ müßte die Bibliothek dann auf jeder Plattform passend kompiliert werden. Geht auch. Ist mir auch viel vertrauter. Ich kann noch kein Java.


    Eine der wichtigsten Fragen, die zunächst beantwortet werden muß, ist: in welchen Formaten liegt das Material der kommerziellen Karten vor? Ist eine Konvertierung in jedem Falle möglich? Müssen verschiedene Algorithmen der Berechnung implementiert werden (Dijkstra kann nicht mit negativen Kantengewichten umgehen, als Beispiel)?


    Der Import der Kartendaten stellt vermutlich die größte Herausforderung dar. Ich rechne mit massiven Performanceproblemen, wenn auf die falsche Weise auf die Daten zugegriffen wird. Beim Navigieren ein nicht zu unterschätzender Aspekt.


    nachdenkende Grüße


    codefish

    History: Vx(2001), IIIc(2001), m505(2002), Treo 680 (12/2006) ... Zodiac2 (04/2007) ... und danach?? Warten wir's ab :)

    also die Idee finde ich schon mal richtig klasse!!!
    ich wäre vor allem auch an einer Version für Windows CE/Windows Mobile interessiert.
    viel dazu beitragen werde ich allerdings auch nicht können da ich kaum programmier erfahrung habe
    ich würde mich aber auf jeden fall bereit erklären tester zu spielen sobald irgend was lauffähiges entstanden ist

    ...und hier noch der Link zum aktuellen SourceCode, der allerdings auch schon wieder auf Ende Juni zurückdatiert.
    Bereits funktional sollten die dort vorhandenen trigonometrischen Funktionen auf Integerbasis sein. Der CoreRoutingalgorithmus ist allerdings erst sehr fragmentarisch...


    Leider war der Zugang bis jetzt auf Grund von falsch gesetzten Benutzerrechten für das Verzeichnis nicht (mehr) möglich...


    Mit freundlichen Grüssen


    Andreas

    Thema: Plattformunabhängigkeit
    Ich weiß nicht, ob das so einfach möglich ist - aber meines Wissens kann man einen C++ Quelltext für zwei verschiedene Plattformen compilieren.
    Wenn man bedenkt, daß ohnehin Anpassungen für die jeweilige UI (1280x1024 eines PC sind schwer mit 320x240 eines PPC zu vergleichen) nötig sind, wäre es wohl auch wegen der Dateigröße und Laufzeitgeschwindigkeit praktikabel, das Projekt aufzusplitten.

    ...danke für den Hinweis. Das werde ich sicher machen, falls ich in nützlicher Frist überhaupt den "Core-Routingalgorithmus" hinkriege...
    Aktuell ziele ich aber damit eher auf existierende Programme für Linux (oder OS X) wie GPSDrive ab, die an sich die ganze GUI-Programmierung schon gelöst haben, denen aber noch ein eigentlicher Routingalgorithmus fehlt.
    Nach den letzten, nicht sehr positiv tönenden Meldungen seitens Palm weiss ich nicht so recht, ob sich da überhaupt noch Entwickler finden lassen, welche den Aufwand auf sich nehmen und hier grössere Anstrengungen reinstecken.
    MfG
    Andreas

    ...aus aktuellem Zeitmangel und wegen weiterer Unwägbarkeiten zum gegenwärtigen Zeitpunkt habe ich beschlossen, das OpenSource-Projekt OpenGPScout vorläufig mal auf Eis zu legen. Ich werde voraussichtlich so gegen Ende Jahr nochmals versuchen, die aktuelle Situation im Navibereich abzuklären und dann entscheiden, ob es sich lohnt, das Projekt weiter zu verfolgen oder endgültig zu abzuschliessen.


    Mit freundlichen Grüssen


    Andreas

    ...was ich auf jeden Fall noch vorhabe, ist meine bisher schon vorhandenen diesbezüglichen Ideen, Konzepte und mathematischen Modelle in einem "Yellow Paper" zusammenzustellen und auf meiner Website allen interessierten Entwicklern zur Verfügung zu stellen. Ich bin in diesem Zusammenhang auch noch in Diskussionen mit den Verantwortlichen bei GPSDrive (Linux) und RouteBuddy (Mac OS X) - für Palm OS habe ich bis anhin aber leider keinen möglichen Kooperationspartner gefunden. Ich rechne aber schon, dass ich für die Erstellung des "Yellow Paper" noch mindestens ein bis zwei Wochen benötige...
    Mit freundlichen Grüssen
    Andreas

    Hallo!


    Hatte mir vergangen auch mal Gedanken über ein OpenSource Navi gemacht.
    Mir geht es aber eigentlich mehr um das Kartenmaterial.


    Benutzer sollten in der Lage sein das Kartenmaterial auf einer Homepage oder so ähnlich selbst zu aktualisieren, damit andere Leute auch in den Genuss Brandaktueller Karten kommen.
    Wird aber bestimmt so nicht machbar sein.


    MfG, zero


    ######EDIT


    Hab gerade noch etwas beim Herumsuchen gefunden.
    http://www.openstreetmap.de/