... the user friendly GPS tool


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
(B)Router Integration in RC ?
#1
Hallo Christian,

ich habe mehrfach verucht einen Thema aufzumachen, welches sich mit einer möglichen Integration von BRouter in Routeconverter befasst. Leider wurden die Versuche mit einem Spawm-Hinweis abgewiesen. Deshalb nochmls ohne "Linkhinweise".
BRouter ist ein Programm unter Android, welches umfangreich konfigurierbar ist und "interessante " Routen und Alternativen erstellt. Zum Testen steht ein Webinterface mit einer primitiven Oberfläche bereit. Einfach mal Tante GOOGLE befragen und testen. Stichwort: "Android BRouter".
Im OSM Forum läuft ein Thread über den sicherlich auch noch Einfluss auf die Entwicklung genommen werden kann. Dort entwickelt derzeit ein User ein Webinterface mit ner komfortablen Oberfläche.

Warum die Anregung hier?
BRouter ist in Java geschrieben und hat als Ziel lokal zu laufen, was es unter Android in Verbindung mit Oruxmaps, OSMAnd, Locus.. auch tut. Es ist jedoch der Wunsch entstanden eine Routenplanung auf dem PC auf einem großen Bildschirm durchführen zu können.
Da Routconverter sehr viele Features für eine komfortable Obfläche standardmässig drin hat(Wegpungte,Editor etc....) und das beim Webinterface zuerst entwickelt werden muß meine Idee mal die Integration in RC vorzuschlagen. RC hat schon ALLES um den BRouter mit Parametern zu versorn, ausser der Konfiguration. Sicherlich könnte man da auch noch Einfluss auf das Interface nehmen. Der Autor von BRouter hat dem WebInterfaceEntwickler auch den kompletten Sourcecode zur Verfügung gestellt.

Oder ist da der Aufwand zu groß?
Interessant für den Routeconverter?



Mit freundlichen Grüssen
Achim
Grüsse Achim
Reply
#2
(22.06.2013, 11:10)womisa Wrote: ich habe mehrfach verucht einen Thema aufzumachen, welches sich mit einer möglichen Integration von BRouter in Routeconverter befasst. Leider wurden die Versuche mit einem Spawm-Hinweis abgewiesen. Deshalb nochmls ohne "Linkhinweise".

Die Linkhinweise sind

Ein primitives Testinterface gibts da:>> http://brensche.de/brouter/
Eine Dowload Zip Datei mit JARs im Beitrag 120 vom Autor: >> http://forum.openstreetmap.org/viewtopic...=19654&p=5

(22.06.2013, 11:10)womisa Wrote: BRouter ist in Java geschrieben und hat als Ziel lokal zu laufen, was es unter Android in Verbindung mit Oruxmaps, OSMAnd, Locus.. auch tut. Es ist jedoch der Wunsch entstanden eine Routenplanung auf dem PC auf einem großen Bildschirm durchführen zu können.
Da Routconverter sehr viele Features für eine komfortable Obfläche standardmässig drin hat(Wegpungte,Editor etc....) und das beim Webinterface zuerst entwickelt werden muß meine Idee mal die Integration in RC vorzuschlagen. RC hat schon ALLES um den BRouter mit Parametern zu versorn, ausser der Konfiguration. Sicherlich könnte man da auch noch Einfluss auf das Interface nehmen. Der Autor von BRouter hat dem WebInterfaceEntwickler auch den kompletten Sourcecode zur Verfügung gestellt.

Oder ist da der Aufwand zu groß?

Das kann ich schwer beurteilen, da ich nicht weiß, was deren Ziel ist. Sofern BRouter ein eigenes Dateiformat benutzt, wäre es sicher einfacher, dieses in RouteConverter zu unterstützen als all die Entwicklung für einen Routeplaner auf dem Desktop nochmal durchzuführen.

(22.06.2013, 11:10)womisa Wrote: Interessant für den Routeconverter?

Interessant für BRouter? Den Entwicklern dort steht es frei, den Sourcecode von RouteConverter zu nehmen und anzupassen.
--
Christian
Reply
#3
Hallo

BRouter ist eine Ein Mann Entwicklung (.."mein Router ist ein 1-Mann Hobbyprojekt..."). Aber liefert sehr gute Routing(alternativen) mit flexibler Konfigurationmöglichkeit. Der Autor hat wohl sein Schwergewicht auf ein Standolone Programm unter Android als primäres Ziel bzw. in Verbindung mit den dort vorhandenen Programmen (OSMAND, ORUXMAPS,LOCUS...)

Der Wunsch das auf einem PC (Desktop) wegen des großen Monitors zu nutzen war mehr oder weniger ein Wunsch der Anwender. Ich habe deshalb an RC gedacht......


MFG
Achim
Grüsse Achim
Reply
#4
(24.06.2013, 21:47)womisa Wrote: Ich habe deshalb an RC gedacht......

Und was genau? Ein BRouter-Clone für den Desktop?
--
Christian
Reply
#5
(25.06.2013, 09:39)routeconverter Wrote:
(24.06.2013, 21:47)womisa Wrote: Ich habe deshalb an RC gedacht......

Und was genau? Ein BRouter-Clone für den Desktop?


..nein! RC benutzt den lokalen BROUTER und versorgtden mit Parametern und stellt das Ergebnis dar. Wenn ich das richtig verstanden habe soll es eine Standolone Version von BRouter unter Windows bzw. JAVA.
- einmal als Programm Version (Lib?)
- einmal als Http Serverversion
zum Laufen gebracht werden. Das wäre unabhängig von RC.

Dies Versionen müssen mit Parameter versorgt werden. Das Versorgen mit Parametern, dabei habe ich an RC gedacht. Der derzeit Laufende Server (später lokal) kann dann etwa so aufgerufen werden:
http://h2096617.stratoserver.net/cgi-bin...trekking_0
und dann bekommt man einen gerouteten Track zurück. Einfach mal probieren.
Der Aufruf dürfte doch für RC ein klacks sein und die Trackanzeige auch.

Probleme ist glaube ich noch die Standoloneversion, aber das hat mit RC nichts zu tun....

Viele Grüsse
Achim
Grüsse Achim
Reply
#6
(25.06.2013, 13:41)womisa Wrote: RC benutzt den lokalen BROUTER und versorgtden mit Parametern und stellt das Ergebnis dar.

Wenn ich das richtig verstanden habe soll es eine Standolone Version von BRouter unter Windows bzw. JAVA.
- einmal als Programm Version (Lib?)
- einmal als Http Serverversion
zum Laufen gebracht werden. Das wäre unabhängig von RC.

BROUTER als Alternative zum Google Maps Routing zu verwenden hätte durchaus Charme.

(25.06.2013, 13:41)womisa Wrote: Der Aufruf dürfte doch für RC ein klacks sein und die Trackanzeige auch.

Wenn das auch Java ist könnte man die BRouter-API direkt aufrufen und könnte sich dem Umweg über HTTP sparen.

BROUTER benötigt auch eine Datenbasis fürs Routing, die ist ziemlich groß:
http://h2096617.stratoserver.net/brouter/segments2/

Und Sourcecode oder JARs gibts im Moment auch nicht, nur ein APK. Soll sich das ändern?
--
Christian
Reply
#7
(25.06.2013, 15:03)routeconverter Wrote: BROUTER als Alternative zum Google Maps Routing zu verwenden hätte durchaus Charme.

Das dachte ich mir auch. Nicht zu vergessen, dass die Bike/Wandern Routen "universeller und konfigurierbar sind und damit dem Googl Router überlegen ist. Deshalb der Gedanke an RC. Ich habe auch mal im OSM-Forum auf RC hingewiesen. Der Autor hat eben als Ziel das Ganze lokal ohne Netzwerk zu betreiben.....und das geht ja bei RC nicht da die Karten gezogen werden müssen.

(25.06.2013, 15:03)routeconverter Wrote: Wenn das auch Java ist könnte man die BRouter-API direkt aufrufen und könnte sich dem Umweg über HTTP sparen.

Im OSM läuft ein Thread wobei Anregungen/ Vorschläge dazu gemacht werden können. Der Webserver ist da ne Übergangslösung zum testen. Bei dem Download xxx.zip Beitrag #120 sind ausser den Class Files auch Sourcen wie man die Schnittstellen bedient. Da ist noch vieles im Fluss was den Aufruf angeht. Der BRouter selbs ist wohl stabil und ausgetestet.


(25.06.2013, 15:03)routeconverter Wrote: BROUTER benötigt auch eine Datenbasis fürs Routing, die ist ziemlich groß:
http://h2096617.stratoserver.net/brouter/segments2/

..von Nichts kommt Nichts. Man kann aber bei Platzmangel nur die Dateien für sein Routinggebiet haben.

(25.06.2013, 15:03)routeconverter Wrote: Und Sourcecode oder JARs gibts im Moment auch nicht, nur ein APK. Soll sich das ändern?

Das Haupziel ist eben Android. Der Autor möchte (glaube ich?) den SRC erst weitergeben wenn das GANZE rund ist. Ein USER, welcher ein WebInterface erstellen will hat via E-Mail jedoch schon den vollständigen SRC-Code erhalten.
Grüsse Achim
Reply
#8
(25.06.2013, 17:32)womisa Wrote: Der Autor hat eben als Ziel das Ganze lokal ohne Netzwerk zu betreiben.....und das geht ja bei RC nicht da die Karten gezogen werden müssen.

Jemand wollte schon einmal die Kartenanbindung vom Google Maps API lösen und aufs OpenLayers API zu portieren und dann einen Download-Mechanismus für die Kartenkacheln zu bauen. Als Vorbereitung dafür habe ich den Java-Code von RC von Google Maps API-Abhängigkeiten befreit, doch dabei ist es geblieben.
--
Christian
Reply
#9
(26.06.2013, 09:42)routeconverter Wrote: Jemand wollte schon einmal die Kartenanbindung vom Google Maps API lösen und aufs OpenLayers API zu portieren und dann einen Download-Mechanismus für die Kartenkacheln zu bauen. Als Vorbereitung dafür habe ich den Java-Code von RC von Google Maps API-Abhängigkeiten befreit, doch dabei ist es geblieben.

Der "Download-Mechanismus für die Kartenkacheln" ist in MOBAC perfekt implementiert. Falls RC die OSM-Tilestruktur oder ein anderes Ausgabeformat (zB. eine Sqlitedatenbank etc.) unterstützen würde, wäre das Downloadproblem perfekt gelöst. Übrigens ist MOBAC in Java geschrieben und die Source verfügbar. Ein Problem ist die Lizenzrechliche Seite zB. bei der Topokarte. Diese wurde darum von MOBAC entfernt.
Ein anderes großes Problem sind auf dem PC die Vektorkarten (Openandromap,Freizeitkarte...etc). Ich kenne kein Programm das diese auf dem PC rendert. Maperitive kann aus OSM Daten eine Karte rendern und als Tiles abspeichern, jedoch auf kleinere Regionen begrenzt (Speicherproblem).
Auf Android wird der BRouter vom Autor von Oruxmaps zur Zeit in Richtung "nahtlose" Integration in Oruxmaps weiterentwickelt (neuest Beta).
Grüsse Achim
Reply
#10
(26.06.2013, 11:12)womisa Wrote: Der "Download-Mechanismus für die Kartenkacheln" ist in MOBAC perfekt implementiert.

Perfekt wäre mir da nicht eingefallen. Die UI ist wenig intuitiv - und das obwohl ich ziemlich wußte, was ich da mache.

(26.06.2013, 11:12)womisa Wrote: Falls RC die OSM-Tilestruktur oder ein anderes Ausgabeformat (zB. eine Sqlitedatenbank etc.) unterstützen würde, wäre das Downloadproblem perfekt gelöst.

RouteConverter verwendet die Google Maps API, die mit ihren Tiles wahrscheinlich Vorbild für die OSM-Tilestruktur war - das ist nicht das Problem. Skeptisch bin ich bei der Datenbasis: beim Routing sind es nur 1 GB, die man vor dem Offline-Gehen herunterladen muß. Bei den Tiles kann es ein Vielfaches davon sein und die Nutzer müssen auch noch entscheiden, welche Gebiete sie in welchen Zoomleveln benötigen. Nach meiner Einschätzung ist das für die allermeisten Nutzer mit MOBAC eine unüberwindliche Hürde. Also müßte man Download-Pakete anbieten ("Norddeutschland") - die irre viel Bandbreite benötigen.
--
Christian
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)