Posts by leupin

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.

    Eine Smartphonevariante macht ja eigentlich auch erst dann Sinn, wenn es Smartphones dazu gibt (oder zumindest die notwendigen SDK's dafür existieren) - allerdings sollte es ja dann nicht allzu schierig sein (sofern die Anforderungen an Speicher und Rechenleistung nicht zu hoch sind), eine Linux-Version auf ein Linux-Smartphone zu portieren.


    Hinsichtlich SDK würde es sowas ja, soviel ich weiss, für ALP geben, aber ALP scheint ja keine Hardwareanbieter für sein OS zu finden. Und bei Palm lässt ja ein Linux-Smartphone noch längere Zeit auf sich warten, so es denn überhaupt mal erscheinen sollte...


    Gruss


    Andreas

    ...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

    ...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

    Quote

    Die Überlegung mit den Kartensegmenten ist nicht blöd. Nur: warum sollte TomTom ein Kartensegment laden, welches garnicht auf der "direkten Strecke" liegt, wenn es doch auch Kartensegmente gibt, auf die den direkten Weg (quasi die Luftlinie) darstellen. Dann müsste TomTom doch erst einmal auf diese Segmente zurückgreifen.


    ...nicht unbedingt, das hängt davon ab, wie beim Erreichen des Randes eines Datensegments das nächste Segment gewählt wird - aber dazu müsste man mehr über den Routingalgorithmus von TomTom wissen...


    Quote

    Ich glaube nciht an die "Segmente" Theorie.


    Ich denke, da war mal etwas ähnliches wie bei dem Paderborner Zubringer.
    Wenn mein TT5 laufen würde, könnte ich das gleich dort mal checken


    Die Segment-Theorie ist auch nur eine der Möglichkeiten - um nochmals Digi-Map als Beispiel zu nehmen: dort gab es wenn ich mich richtig erinnere mal einen ähnlichen Effekt in der Umgebung von Köln, bei dem an sich völlig unmotiviert von der direkten Autobahnverbindung abgefahren und über einen Umweg zum Ziel gefahren wurde (zwar auch über eine Autobahn, aber über eine deutlich grössere Distanz...). Die Ursache wurde damals intensiv im Digi-Map-Forum diskutiert, eine Erklärung konnte aber damals auch nicht gefunden werden - auf jeden Fall wurden damals ähnliche Begründungen (Baustelle, abendliche Rushhour etc.) herumgereicht. In späteren Versionen war der Effekt aber dann nicht mehr vorhanden, also vielleicht doch ein Kartenfehler...


    Das ist natürlich bei TomTom durchaus ebenfalls möglich...


    MfG
    Andreas

    ...ich habe sowieso das Gefühl, dass die These mit der Baustelle nicht haltbar ist;
    gemäss meinen Erfahrungen (mit DigiMap) wurden dort solche nicht verständlichen Routen i.a. entweder durch Fehler im Kartenmaterial, durch Fehler bei den Gewichten für einzelne Strassensegmente (z.B. reicht u.U. ein Segment, welches fälschlicherweise ein sehr grosses Gewicht erhält) oder durch andere Begrenzungen des Routingalgorithmus verursacht (jedes Routingprogramm muss auf Grund des begrenzten RAM der verwendeten Geräte eine gewisse Selektion bei der Wahl der Kartendaten treffen und im allgemeinen einzelne Datensegmente sequentiell laden - dadurch ergibt sich immer eine gewisse Fehlerquelle...)
    Mit freundlichen Grüssen
    Andreas

    Hallo zusammen,
    im Rahmen meiner Projektstudien zu einem OpenSource-Navi (OpenGPScout) habe ich unter http://www.leupinfo.ch/phpBB2 auch ein neues Diskussionsforum aufgeschaltet.
    Dieses dient einerseits den Projektdiskussionen zu OpenGPScout, soll in einer zweiten Kategorie auch die Möglichkeit geben, Diskussionen zu anderen Navigationsthemen und - geräten zu führen, Fragen zu stellen, Informationen und Meinungen auszutauschen etc...
    MfG
    Andreas

    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

    Update vom 12.6.07: Obwohl ich anscheinend bei der Programmierung "allein auf weiter Flur" bin :oh-je: , habe ich mich entschlossen, mal ein bisschen rumzuwerkeln und bin aktuell dabei, den eigentlichen Routenberechnungsalgorithmus zu entwerfen...
    Gruss
    Andreas

    Folgendes habe ich unter http://www.macrumors.com gefunden:



    Mit freundlichen Grüßen
    Andreas

    ...dann schlag mal Legostein ein anderes Programm vor, das auf dem Zire72 läuft (insbesondere mit neuerem Kartenmaterial als Q4/2005 und Q2/2006)... :evil:


    Wichtig ist wie gesagt auf jeden Fall möglichst neues Kartenmaterial zu erwerben (auf E-Bay war beispielsweise eine Premium-Version 2006 vorhanden...


    Ausserdem ist nach meiner Rechnung Q2/2006 aktuell gerade mal ein Jahr alt
    :zwinkert:


    MfG
    Andreas

    ...das ist richtig - ich bin aber davon ausgegangen, dass diese Tatsache nun schon genügend bekannt sein sollte...
    Aber von daher nochmals: Kartenupdates für Digi-Map sind aktuell (und vermutlich auch zukünftig) nicht mehr möglich - von daher sollte man bei einem Kauf über E-Bay darauf achten, möglichst eine Version mit neuerem Kartenmaterial (Q4/2005 oder Q2/2006) zu erwerben - dies hat dann auch den Vorteil, dass die neuste Programmversion (2.75) mit dabei sein sollte oder dass man darauf updaten kann...
    Sorry, dass ich das nicht gleich erwähnt habe
    MfG
    Andreas

    Hallo
    wende Dich mit Deiner Frage am Besten direkt an info@hekosoft.de - ich möchte Dir da keine falsche Auskunft geben - an sich habe ich schon auch das Gefühl, dass es von der Backup-DVD-möglich sein sollte, das Kartenmaterial auf eine andere SD-Karte zu installieren (allenfalls geht es sogar, einfach eine 1:1-Kopie direkt von der einen SD-Karte auf die andere zu machen). Aber im Gegensatz zur Classic-Version kenne ich den Sicherungsmechanismus, welcher unerlaubtes Kopieren der Daten verhindern soll, bei der Premium-Version zu wenig, um hier gesicherte Aussagen machen zu können...
    Mit freundlichen Grüssen aus der Schweiz
    Andreas

    Für welchen Typ von Digi-Map (Classic oder Premium) interessierst Du Dich genau?
    Classic kannst Du auf eine beliebige externe Karte installieren, Premium kommt vorinstalliert auf einer Karte und ist somit vermutlich nicht einfach auf eine andere Karte kopierbar (ich kenne aber die Premium-Version nicht genauer...)
    Eine Classic-Version musst Du durch Hekosoft (dies sollte aktuell immer noch unter info@hekosoft.de machbar sein) auch Dich umregistrieren lassen. Es ist aber dabei wichtig, dass Du sowohl die Benutzerdaten des Verkäufers wie Deinen eigenen Hot-Sync-Namen und die Adresse angibst...


    Mit freundlichen Grüssen
    Andreas

    Hallo zusammen,
    für die Spezialisten, die es vielleicht interessieren könnte, habe ich mal den aktuellen Stand des Source-Codes (Header-Datei mit allerdings sehr rudimentären Fragmenten - primär einige Variablendefinitionen und Implementierungen von trigonometrischen Funktionen in Integer-Arithmetik) auf der OpenGPScout-Webseite aufgeschaltet.
    MfG
    Andreas