QLandkarte + BRouter inkl. Navi-Funktion

  • Hi,
    ich nutze QlandkarteGT um Wanderungen zu planen. Hier wären Navigationshinweise wünschenswert. Leider sind die Navi-Hinweise der Routing-Server aus meiner Sicht für Wanderungen kaum zu gebrauchen und BRouter liefert keine Navi-Hinweise.


    Das wollte ich nun ändern.


    Hier ist eine erweiterte Version von BRouter 1.2 die Navigationshinweise generiert. Ich habe großen Respekt vor der Arbeit von Dr. Arndt Brenschede in Hinblick auf BRouter. Aus meiner Sicht ist der Code von BRouter jedoch in Bezug auf den Programmierstil das schlimmste, was mir in den letzten Jahren untergekommen ist. Ich habe mich daher entschlossen, die Navigationslogik nur so gering wie möglich an RBouter zu koppeln. Dies ist für die Performance sicherlich nicht förderlich, erleichterte mir jedoch die Arbeit ungemein.


    Die Navi-Logik ist in zwei Teile aufgeteilt. Die interne Logik ist in Java implementiert, die Erzeugung der Navi-Hinweise wurde in ein Script ausgelagert. Als Scripsprache habe ich SISC (Scheme) eingebunden. Dies ist für den einen oder andern ggf. recht kryptisch.


    Ich verwende OruxMaps zur Wander-Navigation. OruxMaps wertet Navi-Hinweise nur als Wegpunkte aus. QlandkarteGT speichert Navi-Hinweise als Routeninformation. Anbei ist ein kleines Java-Programm, dass das Speicherformat (.gpx) von QLandkarteGT für Orux-Maps inkl. Navi-Wegpunkte nutzbar macht.


    Was ihr nun hier findet ist:
    BRouter mit Navi-Funktion als Exe und Source.
    Eine sehr kleine Änderung an QlandkarteGT (derzeit nur Source), dass die Zusatzinformation von BRouter ausgewertet werden.
    Ein kleines Programm, dass QlandkarteGT-GPX-Daten so umbaut, dass OruxMaps auch Navi-Hinweise versteht (Exe und Source). Programm starten und Dateien in die GUI mit Drag-Drop fallen lassen.


    Ich habe derheit QLandkareGT mit MinGW inkl. debug-info gebaut. Dies will sicherlich keiner so haben. Wenn gewünscht, kann ich in den nächsten Tagen auch die Exe nachschieben.


    Der Code hat den Zweck in erster Linie für mich nützlich zu sein. Wenn andere ihn auch gebrauchen können, freut mich das.


    Viel Spaß damit,
    Ralf





    PS: Hier im Forum scheine ich keinen .cpp Dateien hochladen zu können. Die Datei ist daher auch gepackt.

  • Hallo Ralf,


    muss ich mal in einer ruhigen Minute ausprobieren.


    Wobei QLGT und BRouter derzeit für mich keine Zukunft haben. QLGT ist mehr oder weniger durch QMapShack ersetzt. Und BRouter ist als Java App In einer Nicht Java Umgebung nur als App, nicht als Bibliothek zu verwenden. Ein Versuch BRouter nach C++ zu portieren, habe ich nach Sichtung des Code sehr schnell aufgegeben.


    Ich setze aktuell auf Roution. Das ist ein C Programm, kann aber mit wenigen Zeilen Code in eine Bibliothek verwandelt werden. Der Autor von Routino ist der Sache zum Glück sehr aufgeschlossen und hat schon allerlei Änderungen durchgeführt, um den Code für die Verwendung in einer Bibliothek fit zu bekommen. Dadurch, dass es eine Bibliothek ist, kann man in QMapShack jetzt on-the-fly routen, d.h. die Route wird beim Zeichnen gleich angezeigt. Das ist beim Planen von Wanderungen wichtig, weil der schnellste oder kürzeste Weg ist nicht immer der schönste oder sinnvollste ist.


    Was die Route als GIS Objekt angeht, ist das alles noch sehr am Anfang. Insofern ein guter Zeitpunkt einzusteigen und Wünsche und Erfahrungen einzubringen. Routino liefert den Wegnamen, die Änderung in Grad und die Richtung in Grad. Daraus sollten sich Abbiegehinweise ableiten lassen. Ich muss noch abgleichen, in wie weit sich so ein Modell auch auf Ergebnisse von MapQuest anwenden lässt.


    Routen auf dem Pc hin oder her, Sinn macht das erst richtig wenn man die Route auch auf das Gerät 1:1 übertragen kann. Ob ich das für Garmin hinbekomme steht noch in den Sternen. Ich habe eine Idee, die aber noch auf ihre Erprobung wartet.


    Prinzipiell kann QMS Daten für jedes Gerät aufbereiten, bzw die Daten von einem Gerät lesen und in das interne Datenmodell umwandeln. Dazu muss ein Gerätefilter geschrieben werden. Für Garmin und TwoNav habe ich das schon gemacht. Für Android wäre das auch interessant.


    Ich könnte mir folgendes vorstellen: Angebunden werden die Androidgeräte über UDP/TCP. Ob das jetzt eine USB Gadget Schnittstelle oder WLan ist, ist dabei egal. Mit UDP werden die Geräte gefunden (pliug-n-play), mit TCP die Daten explizit ausgetauscht. Interessant wäre hier eine App auf dem Gerät, die den Datenaustausch mit QMS regelt und die Daten dann für die jeweilige Kartenapp (Orux, Locus, was auch immer) aufbereitet.


    Das wäre etwas Solides, das für jeden bedienbar ist und sich auch sehr einfach auf allen PC Betriebssystemen installieren lässt. Externe Skripten und ihre Interpreter sind für so was eher ein Kreuz.


    Das sind Ideen. Da ich Androidgeräte nicht als Ersatz für Outdoor GPS Geräte sehe, werden das von meiner Seite aus Ideen bleiben. Sprich hier muss jemand ran, den das interessiert und der das auch wirklich benützt. Bei der Einbindung in QMS helfe ich natürlich gerne mit Rat und Tat.


    Grüße


    Oliver

  • Hallo Oliver,
    mir war es erst einmal wichtig eine Lösung für meine Navi-Problematik zu haben. Dies ist nur weitgehend geschehen, auch wenn sicherlich noch an verschiedenen Stellen nachgeschraubt werden kann.


    Ich hatte den sehr oberflächlichen Eindruck, dass QMS noch lange nicht so weit ist, dass Routenberechnung integriert ist. Daher habe ich mich erst einmal auf QLGT gestüzt (Auslaufmodell oder nicht).


    Ich werde mir QMS nun einmal genauer ansehen und mal gucken, ob ich das eine oder andere im Code unterstützen kann.


    Gruß,
    Ralf

  • Ja, die Geschichte mit Routino funktioniert auch wirklich erst seit diesem Wochenende sauber. Und hat auch mehr im Planungstrack ihren Nutzen.


    Mein Problem mit Routen ist, dass ich sie so gut wie nie benütze. Folglich auch nicht weiß, was die Leute erwarten, die Routen verwenden. Im Auto gebe ich ein Ziel an und vertraue dem Navi. Zu Fuß gibt es maximal einen Track als Serviervorschlag, wenn überhaupt.


    Dementsprechend karg ist auch noch die Implementierung. Das was in GPX 1.1 definiert ist geht, alles weitere fehlt. Aber so muss es ja nicht bleiben.