BRouter: offline Fahrrad-Routing für Android

Dann habe ich gleich mal eine Frage: Was bedeutet diese Fehlermeldung.

Was noch schön wäre, wenn man Zwischenziele setzen könnte.

Hast Du den Favoriten vielleicht To statt to genannt? Ist mir zu Anfang auch passiert.

Ich habe inzwischen mal getestet, wie gut die Routen aus 15-20 km Entfernung zum Terminal 1 von FRA sind.
Das Fahrrad ist ja dafür nicht gerade das gängige Verkehrsmittel, es müssen Autobahnen, Bahnlinien und der Main irgendwo vernünftig überquert werden. Anstiege spielen dabei so gut wie keine Rolle, wenn man in der Nähe des Mains startet.

Es ist damit in erster Linie ein Test der Qualität des Routers und der Fahrrad-relevanten Tags im Umkreis des Flughafens.

Das Ergebnis war wirklich beeindruckend, auch die in der Online-Version möglichen 3 Alternativen machten absolut Sinn.

Herausragendes Merkmal des Router's ist, dass man den Kostenfaktor abhängig von den Tags quasi selbst programmieren kann und Anstiege auf Wunsch mit berücksichtigt werden.

Wer kein OSMAND hat, kann auch die Onlineversion benutzen, der GPX-Track mit Höhenangaben lässt sich herunterladen und mit einem beliebigen Tool darstellen.

Gruß Schiki

GUFSZ wrote:

Dann habe ich gleich mal eine Frage: Was bedeutet diese "to-position not mapped" Fehlermeldung.

Es bedeuted, er hat die Startposition zwar aus der OsmAnd-Favoriten-Datei lesen können, aber keinen "closest distance node" dazu gefunden innerhalb seines Suchquadrats (ca 6*6 km).

Grund kann entweder sein, dass es (unwahrscheinlich) wirklich keinen gibt, oder (wahrscheinlich), dass für das Gebiet kein Routing-Data file (rd5) hinterlegt ist. Die Files tragen immer die Süd-West-Ecke des 5 Grad*5 Grad Quadrats im Namen, also braucht man z.B. für 8 Grad Ost / 48 Grad Nord die Datei E5_N45.rd5

Was noch schön wäre, wenn man Zwischenziele setzen könnte.

Ich weiss :-) Ich will aber diese Hilfskonstruktion mit der Parameterübergave über die Favoriten-Datei nicht weiter aufbohren und arbeote stattdessen an einer besseren Integration, bei der man den internen Router von OsmAnd durch einen externen ersetzen kann, den aber genauso bedienen.

abrensch wrote:

Es gibt aber auch eine Online-Version, die einfacher zu verdauen ist und auch schon viel Freude macht.

Die Routen sind in der Tat top.

Mit einem guten Userinterface könnte es einer der besten OSM-Rad-Router werden.

Chris

Finde die Routen auch interessant, allerdings wird ähnlich wie bei Navit vor surface="cobblestone" nicht zurückgeschreckt.

Pepito wrote:

Finde die Routen auch interessant, allerdings wird ähnlich wie bei Navit vor surface="cobblestone" nicht zurückgeschreckt.

schiki wrote:

Herausragendes Merkmal des Router's ist, dass man den Kostenfaktor abhängig von den Tags quasi selbst programmieren kann und Anstiege auf Wunsch mit berücksichtigt werden.

Nach diesem Satz ist es wie auch bei Navit allein deine Schuld! Es hat jeder andere Präferenzen und Vorstellungen. Daher ist es schön einen Standardprest zu haben, welcher möglichste vielen hilft (Mehrzahl der Beiträge klingen sehr zu frieden) und für den Rest eine Möglichkeit zur Anpassung bieten. Du kannst ja auch damit etwas spielen und dann deine Parameter hier vorstellen. Vielleicht sind sie in der Tat noch besser.

Pepito wrote:

Finde die Routen auch interessant, allerdings wird ähnlich wie bei Navit vor surface="cobblestone" nicht zurückgeschreckt.

Radfahrer oder Weichei? 😉 *duckundweg*

Ich finde den Router auch nicht schlecht. Die Routenvorschläge sind in Ordnung, obwohl ich ein Seitenstraßenundwirtschaftswegeradfahrer bin. 🙂

Schick finde ich v.a. die Einbeziehung der Höhe, und überhaupt den Router nicht nur für Radfahrer, sondern auch für Fußgänger sehr interessant. Nach so etwas war ich eine Weile auf der Suche, und hier scheint es mal gut zu funktionieren. Bisschen schade vielleicht, dass es (nach der Tabelle im Wiki) nicht open source ist, aber vielleicht ändert sich das ja nochmal?

Wie genau ist das mit der Steigung denn realisiert, ließen sich damit auch Profile wie "vermeide Steigungen > 7 %" oder ähnliches realisieren oder geht das mit dem Datenmodell nicht?

g0ldfish wrote:

Bisschen schade vielleicht, dass es (nach der Tabelle im Wiki) nicht open source ist, aber vielleicht ändert sich das ja nochmal?

Ja vielleicht. Es ist ein Hobbyprojekt. Im Moment will ich's einfach nur gut hinkriegen bevor im Sommer die Radler wach werden, danach will ich's irgendwie vom Tisch kriegen. Im Moment bekomme ich tollen Feedback, auch über Fehler, und da ist noch was zu tun am Router selbst.

Wie genau ist das mit der Steigung denn realisiert, ließen sich damit auch Profile wie "vermeide Steigungen > 7 %" oder ähnliches realisieren oder geht das mit dem Datenmodell nicht?

Es geht mit den Daten nicht. Die SRTM Daten haben ein 90-Meter Raster, was z.B. in engen Flusstälern zu erheblichen Gitterfehlern führt, ausserdem hat der Radar nicht immer den Boden gemessen sondern auch Dächer und Baumwipfel. Deswegen verwendet der Router ein 10-Meter hohes "Hysterese-Band", das diese Effekte rausfiltert. Das führt aber dazu, dass die Kosten aus der Steigung nicht lokal zugeordenet werden können, sodass man nicht wirklich lokal die Steigung bewerten kann (Nebenbei führt so eine "nicht-Lokalität" in der Kostenfunkion auch dazu, dass Dijkstra's Algorithmus eigentlich nicht funktioniert, aber das ist ein anderes Kapitel)

Ich habe mich beim Test des brouters mal etwas näher mit dem Thema Routing basierend auf OSM-Daten, im besonderen beim Fahrrad-Routing, beschäftigt. Aufgefallen ist mir dabei folgendes:
Laut deutschem Wiki gilt in Deutschland für einen footway ohne weitere Tags implizit bicycle=no. Ob das praxisgerecht ist, kann man lange diskutieren, meist sind es nur kurze Wege, wo man auch absteigen könnte, wenn man sehr gesetzestreu ist. Die einzigen von mir gefundenen Router, die solche Wege wirklich ausschließen, sind der brouter und openrouteservice.org. OsmAnd Local, Yours und Cloudmade routen bedenkenlos über solche Wege. Vielleicht sollte man für das Fahrrad-Routing das implizite bicycle=no auf auf foot=designated beschränken, bei weitem nicht jeder Weg highway=footway hat das entsprechende blaue Schild.

Gruß aus Rheinhessen Schiki

schiki wrote:

footway ohne weitere Tags ... Die einzigen von mir gefundenen Router, die solche Wege wirklich ausschließen, sind der brouter und openrouteservice.org.

Ausschluss war garnicht mein Gedanke. Mein Hauptaugenmerk war, nicht im Matsch versinken zu wollen. Und da habe ich gelernt, dass man sich auf track/path/footway ohne weitere Tags nicht verlassen kann. Trotzdem gilt im trekking-Profil Kostenfaktor 5, das ist noch kein Ausschluss. Anbei der Ausschnitt aus dem Skript - die allerletzte Zahl ist diese 5. Aber beachte: z.B. highway=footway surface=paved bekommt die 1. Aber praktisch ist mir noch kein Fall vorgekommen, wo ich dadurch ein blaues Fussgängerschild misachten musste.

#
# tracks and track-like ways are rated mainly be tracktype/grade
# But note that if no tracktype is given (mainly for road/path/footway)
# it can be o.k. if there's any other hint for quality
#
switch or highway=track or highway=road or highway=path highway=footway
switch tracktype=grade1 switch probablyGood 1.0 1.3
switch tracktype=grade2 switch probablyGood 1.1 2.0
switch tracktype=grade3 switch probablyGood 1.5 3.0
switch tracktype=grade4 switch probablyGood 2.0 5.0
switch tracktype=grade5 switch probablyGood 3.0 5.0
switch probablyGood 1.0 5.0

schiki wrote:

Ich habe mich beim Test des brouters mal etwas näher mit dem Thema Routing basierend auf OSM-Daten, im besonderen beim Fahrrad-Routing, beschäftigt. Aufgefallen ist mir dabei folgendes:
Laut deutschem Wiki gilt in Deutschland für einen footway ohne weitere Tags implizit bicycle=no. Ob das praxisgerecht ist, kann man lange diskutieren, meist sind es nur kurze Wege, wo man auch absteigen könnte, wenn man sehr gesetzestreu ist. Die einzigen von mir gefundenen Router, die solche Wege wirklich ausschließen, sind der brouter und openrouteservice.org. OsmAnd Local, Yours und Cloudmade routen bedenkenlos über solche Wege. Vielleicht sollte man für das Fahrrad-Routing das implizite bicycle=no auf auf foot=designated beschränken, bei weitem nicht jeder Weg highway=footway hat das entsprechende blaue Schild.

Gruß aus Rheinhessen Schiki

naja, sagen wir, weil sie falsch getaggt sind ignorieren wir auch die richtig getaggten oder sagen wir, sie sind falsch getaggt, lasst uns das korrigieren?

Zwischenfrage zum Thema: Hier in der Gegend gibt es mindestens eine Brücke über den Küstenkanal, die von beiden Seiten bis zur Brücke einen kombinierten Rad- und Fußweg aufweist (getrennt von der Straße gemappt), der aber auf der Brücke (also für < 20m) nur für Fußgänger erlaubt ist (weil eng). Das ist hier http://www.openstreetmap.org/browse/way/40691688 noch falsch getaggt, aber ich bin mir nicht sicher, ob ich, wenn ich das korrigiere, nicht das Fahrradrouting "kaputt" mache. Trotzdem ändern?

Nach meiner Ansicht sollte der Weg als footway getaggt werden, wenn das blaue Schild vorhanden ist. Falls nicht, dann eher path.
Zusätzlich noch bicycle=dismount setzen - siehe http://wiki.openstreetmap.org/wiki/Bicycle. Ein besserer Fahrradrouter sollte damit umgehen können.
Beim BRouter kann man dismount im Profil verwenden und er berücksichtigt auch noch, dass der Weg Teil einer Radroute ist.

HeBri wrote:

Zwischenfrage zum Thema: Hier in der Gegend gibt es mindestens eine Brücke über den Küstenkanal, die von beiden Seiten bis zur Brücke einen kombinierten Rad- und Fußweg aufweist (getrennt von der Straße gemappt), der aber auf der Brücke (also für < 20m) nur für Fußgänger erlaubt ist (weil eng). Das ist hier http://www.openstreetmap.org/browse/way/40691688 noch falsch getaggt, aber ich bin mir nicht sicher, ob ich, wenn ich das korrigiere, nicht das Fahrradrouting "kaputt" mache. Trotzdem ändern?

Rein nach StVo gibt es zwei Dinge, die ein Radfahrer in der geschilderten Situation machen darf:
- Auf die Straße wechseln
- Absteigen und damit zum Fußgänger werden.

Ich würde (soweit es in der Realität möglich ist) den Fahrradweg an die Straße anbinden und das Wegstück über der Brücke als Fußweg erfassen. Laut Bing sieht es so aus, als wäre das möglich.

Ob ein Radfahrer das beachtet oder nicht, liegt in der Verantwortung des Einzelnen. Vor allem von Süden nach Norden ist der Aufwand mit zweimal Queren der Fahrbahn durchaus hoch. Am falschen Routing aufgrund fehlerhafter/unvollständiger OSM-Daten liegt es dann jedoch nicht mehr.

Edbert (EvanE)

Ich bin schon oft dort vorbeigefahren. Einen Radfahrer auf der Straße habe ich dort noch nie gesehen. Zuviel Verkehr. Zu gefährlich.

HeBri wrote:

Ich bin schon oft dort vorbeigefahren. Einen Radfahrer auf der Straße habe ich dort noch nie gesehen. Zuviel Verkehr. Zu gefährlich.

Das wundert mich nach dem Anschein des Luftbildes nicht wirklich.
Ausgeschilderte Regelungen und gelebte Praxis sind halt manchmal zwei sehr verschiedene Dinge.

Dennoch sollten wir es in den OSM-Daten so eintragen, wie es beschildert ist. Auf dem kurzen übersichtlichen Stück kann jeder Radfahrer selber entscheiden, ob er/sie die Regeln befolgt oder es vorzieht nicht die Straße zu benutzen.

Edbert (EvanE)

Was herauskommt, wenn ein (Fahrrad)-Router primär nur mit den impliziten restrictions arbeitet, kann man in dem Beispiel aus Wiesbaden für openrouteservice sehen.
Zwei kurze Fußwege, die breit genug zum Fahrradfahren sind, keinerlei Beschilderung haben und entsprechend nur mit hiqhway=footway getagged sind, werden zugunsten eines großen Umwegs über stark befahrene Hauptdurchgangsstraßen nicht gewählt. BRouter und OsmAnd-Local dagegen routen beide direkt über die Fußwege.

schiki wrote:

Was herauskommt, wenn ein (Fahrrad)-Router primär nur mit den impliziten restrictions arbeitet, kann man in dem Beispiel aus Wiesbaden für openrouteservice sehen.
Zwei kurze Fußwege, die breit genug zum Fahrradfahren sind, keinerlei Beschilderung haben und entsprechend nur mit hiqhway=footway getagged sind, werden zugunsten eines großen Umwegs über stark befahrene Hauptdurchgangsstraßen nicht gewählt. BRouter und OsmAnd-Local dagegen routen beide direkt über die Fußwege. http://schki.eu/osm/Bildchen.jpg

DU willst also ernsthaft vorschlagen, dass Fahrrad-Router die Verkehrsregeln missachten sollen.
Nun ja seien wir nicht so bescheiden, warum sollen Fahrrad-Router nicht auch über Treppen routen. Ist doch meist viel kürzer?

Ausnahmen von den Verkehrsregeln mag ein einzelner Radfahrer in seiner eigenen Verantwortung ja mal machen. Ein Router sollte so etwas jedoch wirklich nicht von sich aus vorschlagen.

Edbert (EvanE)

Um bei dem Beispiel oben von schiki zu bleiben: Ich denke, dass der "Fuss"-weg hier falsch getaggt ist. Wenn der Fußweg "keinerlei Beschilderung" hat, warum ist es dann ein Fußweg? Bei einem Fußweg parallel zur Straße (Sidewalk) ist es eindeutig, wenn kein Schild da steht. Aber ein (Fuß-)weg ohne Straße ist nicht zwangsläufig ein reiner Fußweg, oder?

PS: Wieso steht eigentlich in dem Bild ein Straßenname auf dem Kopf? Da ist doch ein kleiner Bug im Renderer... 😄

schiki wrote:

Was herauskommt, wenn ein (Fahrrad)-Router primär nur mit den impliziten restrictions arbeitet, kann man in dem Beispiel aus Wiesbaden für openrouteservice sehen.
Zwei kurze Fußwege, die breit genug zum Fahrradfahren sind, keinerlei Beschilderung haben und entsprechend nur mit hiqhway=footway getagged sind, werden zugunsten eines großen Umwegs über stark befahrene Hauptdurchgangsstraßen nicht gewählt.

Dann ist footway aber eindeutig falsch.
Möchtest Du auch durch Fussgängerzonen und über Waldwege geroutet werden?

Gegen einen Schalter im Router (strikt / fuzzy - Routing) ist ja nichts einzuwenden aber standardmäßig sollte
er sich schon ein wenig an die Regeln halten.

chris66 wrote:

Möchtest Du auch durch Fussgängerzonen und über Waldwege geroutet werden?

Gegen einen Schalter im Router (strikt / fuzzy - Routing) ist ja nichts einzuwenden aber standardmäßig sollte
er sich schon ein wenig an die Regeln halten.

ja schon. Mit Kostenfaktor 5 durch eine Fussgängerzone zu routen heisst ja nichts anderes als dass
es sich auch lohnt, wenn man da 5 mal langsamer (=20/5 = 4 kmh) unterwegs ist, sprich absteigen.

Gleiches gilt für Einbahnstrassen.

Gruss, Arndt

abrensch wrote:

chris66 wrote:

Möchtest Du auch durch Fussgängerzonen und über Waldwege geroutet werden?

Gegen einen Schalter im Router (strikt / fuzzy - Routing) ist ja nichts einzuwenden aber standardmäßig sollte
er sich schon ein wenig an die Regeln halten.

ja schon. Mit Kostenfaktor 5 durch eine Fussgängerzone zu routen heisst ja nichts anderes als dass
es sich auch lohnt, wenn man da 5 mal langsamer (=20/5 = 4 kmh) unterwegs ist, sprich absteigen.

Gleiches gilt für Einbahnstrassen.

Hallo Arndt

Das soll dann bitte auch entsprechend hervorgehoben und als Alternative zum StVO-gerechten Routing eingezeichnet sein.
Mit einer Hervorhebung + Alternative könnte man Rad-Routing auch über Treppen zulassen. Mit einem Kostenfaktor von ca. 10 (entsprechend 2 km/h) würde das in etwa passen.

Edbert (EvanE)

Wieso routet mich der router über den Weg http://www.openstreetmap.org/browse/way/85416982
Tut OsmAnd im offline modus auch... (schon gemeldet als http://code.google.com/p/osmand/issues/detail?id=1380)
Als OsmAnd Plugin wäre dein Router super :-)

EvanE wrote:

Mit einer Hervorhebung + Alternative könnte man Rad-Routing auch über Treppen zulassen. Mit einem Kostenfaktor von ca. 10 (entsprechend 2 km/h) würde das in etwa passen.

Wenn man so etwas einbaut sollte dies deutlich hervorgehoben werden bzw. schon gleich am Anfang drauf hinweisen das es solche Teilstücke gibt. Wenn man mit Gepäck und/oder Anhänger unterwegs ist dann sind Treppen auch nicht mit 2km/h zu bewältigen.

Wieso routet mich der router über den Weg

Welchen Router Du auch immer meinst. Wenn er über access=no routet ist er defekt.

Hallo Holger,

Access=no genauso wie vehicle=no wird zur Zeit vom BRouter nicht ausgewertet, siehe auch https://groups.google.com/forum/#!topic … Z3HK64AMgA

Gruß Schiki

badger123 wrote:

EvanE wrote:

Mit einer Hervorhebung + Alternative könnte man Rad-Routing auch über Treppen zulassen. Mit einem Kostenfaktor von ca. 10 (entsprechend 2 km/h) würde das in etwa passen.

Wenn man so etwas einbaut sollte dies deutlich hervorgehoben werden bzw. schon gleich am Anfang drauf hinweisen das es solche Teilstücke gibt. Wenn man mit Gepäck und/oder Anhänger unterwegs ist dann sind Treppen auch nicht mit 2km/h zu bewältigen.

Ich schrieb nicht umsonst "als Alternative". Jeder kann dann selbst entscheiden, ob das für ihn/sie machbar ist. Die 'alte Oma' wird diese 'Alternative' ggfs. auch nicht nutzen wollen.

Darüber hinaus sollten solche rechtlich oder physisch problematischen Stellen per Einstellung von Vermeidungen ausgeschlossen werden können.

Edbert (EvanE)

Nahmd,

EvanE wrote:

Darüber hinaus sollten solche rechtlich oder physisch problematischen Stellen per Einstellung von Vermeidungen ausgeschlossen werden können.

.oO( zum Beispiel sac_scale=demanding_mountain_hiking )

Gruß Wolf

chris66 wrote:

Welchen Router Du auch immer meinst. Wenn er über access=no routet ist er defekt.

Ganz so einfach ist es nicht. access=no definiert ja nur den default-acess, der dann von bicycle=... oder foot=... wieder überschrieben werden kann.

schiki wrote:

Access=no genauso wie vehicle=no wird zur Zeit vom BRouter nicht ausgewertet, siehe auch https://groups.google.com/forum/#!topic … Z3HK64AMgA

Ich habe jetzt zwei Anpassungen gemacht (in allen Profilen ausser "shortest):

1) zum Problem access=no und HolgerJeromin's Beispiel in Hilden

switch and access=unknown
and or bicycle= bicycle=no
or highway=track or highway=road or highway=path or highway=footway highway=service
100000

Tatsächlich ist access=no nicht in der atuellen lookup.dat, also musste ich access=unknown benutzen (=alles, was nicht leer ist und und in lookup.dat aufgeführt). Durch jedes "bicycle" tag ausser "no" wird es wieder aufgehoben. Ausserdem musste ich den Filter auf den highway-typ ergaenzen, sonst hatte ich beispiele in meiner Testsuite mit highway=residential, access=designated, die auch den Ausschluss getriggert haben.

Das in der google-group genannte Beispiel an der Kaiserbrücke in Mainz lässt sich damit aber nicht erschlagen, weil hier nur die access=no und barrier=gate tags an den Nodes stehen und nicht am way, und node-tags kann brouter noch nicht.

2) zum Problem cycleway=opposite*

Habe ich ergaenzt in der oneway-berechnung als:

switch or cycleway=opposite cycleway=opposite_lane 0

(=keine oneway-strafe für diese beiden werte) cycleway=opposite_track fehlt leider auch in lookups.dat, aber so viele sind das nicht.

Sobald ich die Beschränkung für die Menge von Tags in den routing-data-files nicht mehr habe, kann man das sicher noch besser machen.

EvanE wrote:

Mit einer Hervorhebung + Alternative könnte man Rad-Routing auch über Treppen zulassen. Mit einem
Kostenfaktor von ca. 10 (entsprechend 2 km/h) würde das in etwa passen.

Steht drin im trekking-profil, allerdings mit Kostenfaktor=40. Mit 10 hat er mir persönlich zu viele Treppen gefunden.

Gruss, Arndt

abrensch wrote:

EvanE wrote:

Mit einer Hervorhebung + Alternative könnte man Rad-Routing auch über Treppen zulassen. Mit einem
Kostenfaktor von ca. 10 (entsprechend 2 km/h) würde das in etwa passen.

Steht drin im trekking-profil, allerdings mit Kostenfaktor=40. Mit 10 hat er mir persönlich zu viele Treppen gefunden.

Hallo Arndt

Sehr schön, kommt mir aber sehr viel vor. Muss man aber vielleicht vom Typ des Radfahrers abhängig machen. Ein MTBler käme wahrscheinlich mit Kostenfaktor=20 klar. Beim Rennrad weiß ich es nicht so genau. Einerseits wollen die schnell sein und ihr Rad ist eher leicht, anderseits steigen die ungern ab.

Wie sieht es mit einem Profil für Räder mit Anhänger aus? Das hat auf meinen Treppenvorschlag hin jemand als Einwand gebracht. Anhänger unterliegen ja besondere Einschränkungen / Notwendigkeiten (Mindestbreite, Gewicht, sperrig, ...).

Um klar zu machen, um was es mir geht, hier ein Beispiel einer Eisenbahnbrücke mit Radweg über die Sieg.
Ohne Beachtung der Treppe ergibt das folgende hübsche Route. Da die vorgeschlagene Route vor Ort nicht direkt erkennbar ist, nehmen viele, die zum Weg entlang der Sieg wollen, halt die Treppe.

Edbert (EvanE)

Mal ne Zwischenfrage zu meinem besseren Verständnis: "Kostenfaktor=1" heisst bei Euch "man kann da mit 20 km/h fahren"? Welchem key bei OSM entspricht das?
Grüße, Max

maxbe wrote:

Mal ne Zwischenfrage zu meinem besseren Verständnis: "Kostenfaktor=1" heisst bei Euch "man kann da mit 20 km/h fahren"? Welchem key bei OSM entspricht das?

Hallo Max

Ich denke man kann mit der einem eigenen Geschwindigkeit fahren ohne weitere Beschränkungen. Das kann in deinem Fall 10 / 15 / 20 / 25 / 30 oder 35 km/h sein. Ein besonderes Tag braucht es dafür wohl kaum.

Die Menschen und ihre Fahrräder sind verschieden, was zu sehr unterschiedlichen Durchschnittswerten auf gerader, ebener Strecke führt. Oder wie sagte ein Bekannter, der täglich 12 km zur Arbeit und wieder zurück fährt:
30 km/h ist doch gemütliches Einrollen (auf einem Rennrad in der Gruppe).
Ich selbst bin froh, wenn ich (allein) auf ebener Strecke mit meinem Rad zwischen 20 und 25 km/h schaffe.

Der Kostenfaktor dient vor allem dazu, Wege mit Eigenschaften, die man vermeiden möchte, mit einem Malus bei der Berechnung der Route zu belegen. Daneben fließt der Kostenfaktor wahrscheinlich in die Berechnung der Zeit für die Route ein. Und ja, es wäre schön, zu wissen, wie das im konkreten Fall des Brouter gehandhabt wird.

Nur meine Vermutungen
Edbert (EvanE)

EvanE wrote:

abrensch wrote:

Steht drin im trekking-profil, allerdings mit Kostenfaktor=40. Mit 10 hat er mir persönlich zu viele Treppen gefunden.

Sehr schön, kommt mir aber sehr viel vor. ... Beispiel einer Eisenbahnbrücke mit Radweg über die Sieg.
Ohne Beachtung der Treppe ergibt das folgende ... hübsche Route

Mit Faktor 40 für Treppen macht BRouter auch den langen Looping, bis 30 hätte er die Treppe genommen. Man kann sowas in der Online Version selber ausprobieren, indem man über den Upload-Button ein modifiziertes Profil hochlädt (was dann als "custom" in der Auswahlbox steht)

EvanE wrote:

Wie sieht es mit einem Profil für Räder mit Anhänger aus? Das hat auf meinen Treppenvorschlag hin jemand als Einwand gebracht. Anhänger unterliegen ja besondere Einschränkungen / Notwendigkeiten (Mindestbreite, Gewicht, sperrig, ...).

Ich hatte den Fall noch nicht, aber ich würde, ausgehend from trekking-profil, Fusswege und Treppen konsequenter vermeiden.

EvanE wrote:

Der Kostenfaktor dient vor allem dazu, Wege mit Eigenschaften, die man vermeiden möchte, mit einem Malus bei der Berechnung der Route zu belegen. Daneben fließt der Kostenfaktor wahrscheinlich in die Berechnung der Zeit für die Route ein. Und ja, es wäre schön, zu wissen, wie das im konkreten Fall des Brouter gehandhabt wird.

Ja genau, nur dass BRouter keine Zeiten ausrechnet.

Der Router sucht den Weg mit den geringsten "Kosten", was aber ein rein abstraktes Konzept ist. Die Kosten werden zwar in Metern gezählt, meinen aber was anderes als die Länge der Route.

Der Hauptteil der Kostenfunktion ist dieser entfernungsabhängige Teil, also immer Wegstrecke mal Kostenfaktor, und das über alle Wegstücke aufsummiert. Es gibt aber noch zwei andere Teile in der Kostenfunktion, dass eine sind die Winkelkosten ("turncost") und das andere die Höhenkosten ("elevationcost").

Gerade am Beispiel der "turncost" wird deutlich, dass das Konzept tatsächlich abstrakt ist. Er rechnet für eine 90-Grad Ecke Zusatzkosten von 90m. Das wäre aus der Sicht einer Zeitbetrachtung ja viel zu viel (man braucht keine 16 Sekunden zusätzlich, um um eine Ecke zu fahren). Man muss das eher als Filter verstehen, der verwinkelte Wege vermeidet, weil in verwinkelten Wegen mehr böse Überraschungen stecken als in geraden.

Der Kostenfaktor muss möglichst nahe bei 1 sein für die Art von Wegen, die man sucht, weil sonst durch die Art der Berechnungsmethode das "Suchgebiet" zu gross wird und die Berchnung dann zu lange dauert. Und er darf nicht kleiner als 1 sein, weil sonst die Berechnung nicht mehr funktioniert.

abrensch wrote:

EvanE wrote:

Sehr schön, kommt mir aber sehr viel vor. ... Beispiel einer Eisenbahnbrücke mit Radweg über die Sieg.
Ohne Beachtung der Treppe ergibt das folgende ... hübsche Route

Mit Faktor 40 für Treppen macht BRouter auch den langen Looping, bis 30 hätte er die Treppe genommen. Man kann sowas in der Online Version selber ausprobieren, indem man über den Upload-Button ein modifiziertes Profil hochlädt (was dann als "custom" in der Auswahlbox steht)

Interessant, also durchaus so wie ich es erwartet hätte.
Schön dass man bei Brouter das im Detail sehr genau einstellen und auch probieren kann.

abrensch wrote:

EvanE wrote:

Der Kostenfaktor dient vor allem dazu, Wege mit Eigenschaften, die man vermeiden möchte, mit einem Malus bei der Berechnung der Route zu belegen. ... Und ja, es wäre schön, zu wissen, wie das im konkreten Fall des Brouter gehandhabt wird.

... Der Router sucht den Weg mit den geringsten "Kosten", was aber ein rein abstraktes Konzept ist. ...

Der Hauptteil der Kostenfunktion ist dieser entfernungsabhängige Teil, also immer Wegstrecke mal Kostenfaktor, und das über alle Wegstücke aufsummiert. Es gibt aber noch zwei andere Teile in der Kostenfunktion, dass eine sind die Winkelkosten ("turncost") und das andere die Höhenkosten ("elevationcost").

Gerade am Beispiel der "turncost" wird deutlich, dass das Konzept tatsächlich abstrakt ist. Er rechnet für eine 90-Grad Ecke Zusatzkosten von 90m. Das wäre aus der Sicht einer Zeitbetrachtung ja viel zu viel (man braucht keine 16 Sekunden zusätzlich, um um eine Ecke zu fahren). Man muss das eher als Filter verstehen, der verwinkelte Wege vermeidet, weil in verwinkelten Wegen mehr böse Überraschungen stecken als in geraden.

Kommt wie immer darauf an. Rechts abbiegen verursacht (bei uns) relativ wenig Kosten, man sollte allerdings auf den Querverkehr achten. Beim links abbiegen hingegen muss man ggfs. recht lange auf den Gegenverkehr warten. Solange man rechts/links abbiegen nicht unterscheidet, scheint mir das ein recht guter/brauchbarer Mittelwert zu sein.

In der Tat gibt es viele (mich eingeschlossen) die eher eine einfache (wenige Abbiegevorgänge), leicht zu merkende Route auswählen, wenn sie ohne Router selber planen, als die letzten Meter sparen zu wollen.

Wie sieht es mit Kreuzungen (gleichrangig, niederer / höher Rang, mit Ampel geregelt) aus. Werden die in der Kostenfunktion berücksichtigt? (Für Bahnübergänge und Fähren ergibt sich die gleiche Frage.)

Edbert (EvanE)

EvanE wrote:

Wie sieht es mit Kreuzungen (gleichrangig, niederer / höher Rang, mit Ampel geregelt) aus. Werden die in der Kostenfunktion berücksichtigt? (Für Bahnübergänge und Fähren ergibt sich die gleiche Frage.)

Schlecht :-)

Mit Ampeln ( highway = traffic_signals als node-tag ) hatte ich experimentiert, aber davon gibts einfach zu wenig in der Karte, schon garnicht an den Nodes von strassenbegleitenden Radwegen.

Über so eine Bewertung von Kreuzungen nach Richtung und Rang habe ich tatsächlich nachgedacht und so könnte man, auch mit vorhandenen Kartendaten, wohl auch tatsächlich bessere Wege finden, aber das war mir bisher zu schwierig.

Bahnübergänge kennt BRouter bisher nicht.

Über eine Fähre bin ich letzte Woche selbst gestolpert, stand plötzlich am Main an so einer kleinen Schönwetter-Ausflugsfähre, weil ich vergessen hatte, das "no ferries" Profil zu benutzen. Fähren waren deswegen schwierig, weil sich kein Kostenfaktor finden liess, der für diese kleinen Main-Fähren genauso funktioniert wie für die Bodenseefähren. Deswegen habe ich die Berechnung von Fähren jetzt nochmal geändert: sie bekommen jetzt einmalige Zusatzkosten von 10km, unabhängig von der tatsächlichen Wegstrecke der Fähre, und dann noch Kostenfaktor 5 für die Wegstrecke. Damit werden die kleinen Main-Fähren nicht mehr gefunden (weil die nächste Brücke ja nie weit ist), die Rhein-Fähren aber doch.

Gruss, Arndt

Hallo Arndt,

war das zufällig diese Fähre? http://www.openstreetmap.org/?lat=50.05 … 11&zoom=16
Hatte ich auch schon in einer vom Brouter berechneten Route drin, fährt aber nur an Ausflugstagen.

Mit den beschriebenen Modifikationen ist der BRouter sicher noch ein gutes Stück besser geworden, ich werde ihn mir in den nächsten Tagen auf mir bekannten Terrain nochmal anschauen, aber nur theoretisch - momentan zu kalt und zu viel Schnee.

So etwas ähnliches mit unterschiedlichen Profilen gibt es jetzt auch für Bergwander in den Alpen, allerdings auf ein bestimmtes Gebiet beschränkt und nicht als App für das Smartphone: http://geo.dianacht.de/topo/ - von Netzwolf entdeckt.
Für Wanderer im Gelände ist glaube ich die Berechnung deutlich einfacher, es müssen nicht so viele unterschiedliche Tags berücksichtigt werden.

Gruß Schiki

schiki wrote:

Für Wanderer im Gelände ist glaube ich die Berechnung deutlich einfacher, es müssen nicht so viele unterschiedliche Tags berücksichtigt werden.

Jo, das ist kein Kunststück im Vergleich zu Arndts Fahrradrouting. Da stecken ein paar Verbotsregeln, paar Strassenklassen, Wanderwegrelationen, sac_scale und Höhenmeter drin. Fussgänger haben ja selten Einbahnstrassen, dürfen überall abbiegen und die Zielgruppe kann auch Treppen steigen. Das mit den Strafpunkten fürs Abbiegen finde ich als Idee gut, dann läuft man nicht im zickzack durch die Häuserblocks. Aber das ist auch eher in Städten interessant ist als im freien Gelände.

Grüße, Max

maxbe wrote:

... Fussgänger haben ja selten Einbahnstrassen, dürfen überall abbiegen und die Zielgruppe kann auch Treppen steigen. Das mit den Strafpunkten fürs Abbiegen finde ich als Idee gut, dann läuft man nicht im zickzack durch die Häuserblocks. Aber das ist auch eher in Städten interessant ist als im freien Gelände.

Hallo Max

Neben dem "zickzack durch die Häuserblocks" gibt es noch den Fall kurze, steile Zick-Zack Strecke gegen eine längere, weiter geschwungene, weniger steile Strecke einen Berg hinauf. Da können die Präferenzen durchaus unterschiedlich liegen. Auch beim Fußgängerrouting kann ein Malus fürs Abbiegen also sinnvoll sein. Über die Größe des Malus müsste man dann gegebenenfalls mal nachdenken.

Edbert (EvanE)

abrensch wrote:

EvanE wrote:

Wie sieht es mit Kreuzungen (...) aus. Werden die in der Kostenfunktion berücksichtigt? (Für Bahnübergänge und Fähren ergibt sich die gleiche Frage.)

...
Mit Ampeln ( highway = traffic_signals als node-tag ) hatte ich experimentiert, aber davon gibts einfach zu wenig in der Karte, schon garnicht an den Nodes von strassenbegleitenden Radwegen.

Über so eine Bewertung von Kreuzungen nach Richtung und Rang habe ich tatsächlich nachgedacht und so könnte man, auch mit vorhandenen Kartendaten, wohl auch tatsächlich bessere Wege finden, aber das war mir bisher zu schwierig.

Hallo Arndt

Jede Kreuzung (ob Ampel oder nicht) ist ja immer auch ein Gefahrenpunkt, erfordert besondere Aufmerksamkeit und ggfs. eine Reduzierung der Geschwindigkeit. Von daher wäre ein genereller Malus (kleiner als beim Abbiegen) sinnvoll.

Kreuzungen mit Ampeln erkennt man bei separat eingetragenem Radweg an einem Knoten mit highway=crossing + crossing=traffic_signals. Zumindest wenn das richtig eingetragen ist.

abrensch wrote:

Bahnübergänge kennt BRouter bisher nicht.

Schade, sie bedeuten ja oft Wartezeit.
Bahnübergänge sind leicht am Knoten mit railway=(level_)crossing zu erkennen.
Den Malus würde ich größer (2-5x) als beim Abbiegen sehen.

abrensch wrote:

Über eine Fähre bin ich letzte Woche selbst gestolpert, ... Fähren waren deswegen schwierig, weil sich kein Kostenfaktor finden liess, der für diese kleinen Main-Fähren genauso funktioniert wie für die Bodenseefähren. Deswegen habe ich die Berechnung von Fähren jetzt nochmal geändert: sie bekommen jetzt einmalige Zusatzkosten von 10km, ..., und dann noch Kostenfaktor 5 für die Wegstrecke. Damit werden die kleinen Main-Fähren nicht mehr gefunden (weil die nächste Brücke ja nie weit ist), die Rhein-Fähren aber doch.

Das scheint mir ein guter Ansatz zu sein. Ob die 10km Malus optimal sind oder der Wert besser Richtung 5-8km verschoben werden sollte, muss die Erfahrung zeigen. Ein kurzer Online-Test ergab eine starke Präferenz gegen Fähren.

Edbert (EvanE)

Dann mal hier eine Fehlermeldung.

Ich musste meine anderen Favoriten in der Kategorie löschen, in der der Startpunkt und ENdpunkt stand. Davor hat sich brouter beschwert, dass es keinen Startpunkt gäbe und sich verabschiedet.

Ich habe da ein etwas komisches Routingergebnis mit dem Trekkingprofil bekommen.
Start und Zielpunkt: http://dl.dropbox.com/u/512261/Osmand/brouter.gpx
Ergebnis: http://dl.dropbox.com/u/512261/Osmand/b … omisch.gpx

Es ist die Brouterversion einen Tag bevor Du hier gepostet hast.

abrensch wrote:

Über eine Fähre bin ich letzte Woche selbst gestolpert, stand plötzlich am Main an so einer kleinen Schönwetter-Ausflugsfähre,

Die an der Eddersheimer Staustufe? Es wäre besser, die aus OSM zu streichen, so häufig wie sie nicht fährt.

Das mit den Kosten würde ich mal mit den Rheinfähren überprüfen. Interessant dabei ist diese Fähre. Sehr interessante Fährzeiten: http://www.guntersblum-tourismus.de/ind … &Itemid=97

GUFSZ wrote:

Die an der Eddersheimer Staustufe?

ja, glaub schon, sind aber noch 2km von der Fähre bis zur Staufufe. Jedenfalls die, die Schiki oben genannt hat.

Das mit den Kosten würde ich mal mit den Rheinfähren überprüfen. Interessant dabei ist diese Fähre...

Ja schwierig. Ist zwar eine Fähre auf eine Halbinsel, aber wie ich es sehe kommt man auf der anderen Seite über eine Brücke über den Altrhein, sodass das schon eine Langstecke schliessen könnte. Im Prinzip könnte ich die Fährzeiten auch auswerten, steht in beiden Fällen ja drin als "opening_hours" tag.

Der Routing-Fehler im anderen Post kann sein. In dieser Version (0.1) war ein Fehler drin mit einem internen Integer-Überlauf. Der ist behoben ab 0.3. Das mit dem Handling der OsmAnd-Favoriten verstehe ich selber nicht so ganz. Irgendwie sind das nur Backup-Files, die ich da lese, und ich lese auch schon 2 (favorites.gpx und favorites.gpx_bak oder so ähnlich), das ist bisschen Bastelei.

Gruss, Arndt

GUFSZ wrote:

Ich habe da ein etwas komisches Routingergebnis mit dem Trekkingprofil bekommen.
Start und Zielpunkt: http://dl.dropbox.com/u/512261/Osmand/brouter.gpx
Ergebnis: http://dl.dropbox.com/u/512261/Osmand/b … omisch.gpx

Es ist die Brouterversion einen Tag bevor Du hier gepostet hast.

Ich bekomme mit BRouter Version 0.5 die gleiche merkwürdige Schleife am Anfang, selbst wenn man das Ziel ziemlich in die Nähe legt. Der Rest der Route sieht aber m.E. gut aus.
Vielleicht könntest Du für dieses Problem einen neuen Thread in https://groups.google.com/forum/?fromgr … ikerouting eröffnen

Hat sich geklärt, den Verbindungsknoten 2115081565 gibt es erst seit 16 Jan, die Routingdaten sind aber schon von Anfang des Jahres.

https://dl.dropbox.com/u/512261/brouter … ch%202.gpx
Gleich am Anfang des Tracks gibt es eine sonderbare Sache. Der Schlenker in die "Alte Gasse" rein und dann wieder raus. Der erste Schlenker geht in die entgegengesetzte Richting der Linksabbiegerspur der Alten Gasse. Ich habe die Stelle in JOSM überprüft, dort ist Oneway richtig eingetragen.

Es stimmt irgendetwas nicht mit den Headerdaten der gpx-files nicht, die von Brouter kommen. Jedesmal wenn ich sie mit routeconverter.de öffne, lande ich in Afrika.

GUFSZ wrote:

Gleich am Anfang des Tracks gibt es eine sonderbare Sache. Der Schlenker in die "Alte Gasse" rein und dann wieder raus. Der erste Schlenker geht in die entgegengesetzte Richting der Linksabbiegerspur der Alten Gasse. Ich habe die Stelle in JOSM überprüft, dort ist Oneway richtig eingetragen.

Ja das ist aber so gedacht. Hier der Ausschnitt aus dem Profile dazu:

add switch and reversedirection=yes oneway=yes
switch or cycleway=opposite cycleway=opposite_lane 0
switch or highway=primary highway=primary_link 50
switch or highway=secondary highway=secondary_link 30
switch or highway=tertiary highway=tertiary_link 20
4.0
0.0

Das heisst, auf der Bleichstrasse ("secondary") ist der falsche oneway "ziemlich verboten"
(kostenfaktor 30+), in der Alten Gasse ("redidential") aber nur mit Kostenfaktor 4+
(=du kannst schieben). Und damit ist's die billigste Lösung, weil ein Weg ohne
oneway-verletzung wäre viel weiter.

Es stimmt irgendetwas nicht mit den Headerdaten der gpx-files nicht, die von Brouter kommen. Jedesmal wenn ich sie mit routeconverter.de öffne, lande ich in Afrika.

Da bin ich an anderer Stelle auch schon darauf aufmerksam gemacht worden. Ich "misbrauche" die gpx-Version für meine Version (hier 0.1) und das darf ich nicht. Wenn Du da eine "1.1" reinschreibst, geht es. Hab' ic als TODO auf meienr Liste.

Gruss, Arndt

abrensch wrote:

Ja das ist aber so gedacht. Hier der Ausschnitt aus dem Profile dazu:

add switch and reversedirection=yes oneway=yes
switch or cycleway=opposite cycleway=opposite_lane 0
switch or highway=primary highway=primary_link 50
switch or highway=secondary highway=secondary_link 30
switch or highway=tertiary highway=tertiary_link 20
4.0
0.0

Das heisst, auf der Bleichstrasse ("secondary") ist der falsche oneway "ziemlich verboten"
(kostenfaktor 30+), in der Alten Gasse ("redidential") aber nur mit Kostenfaktor 4+
(=du kannst schieben). Und damit ist's die billigste Lösung, weil ein Weg ohne
oneway-verletzung wäre viel weiter.

Da ich die Stelle kenne. Die Lösung bedeutet einmal über eine vierspurige Straße und dann noch einmal zurück. Einfach den Bürgersteig an der Bleichstr. entlang zur Peterstraße geschoben, wäre schlauer.

Schau dir mal https://dl.dropbox.com/u/512261/brouter … %20Weg.gpx im Satellitenbild an.

Da Du an anderer Stelle geschrieben hast, dass Du auch die Daten für eine stimmgeleitete Führung für diverse Apps bereitstellen willst...

Bei abgeschaltetem Bildschirm, wären die Abbiegepunkte zum Schieben falsch angesagt.

Käme so etwas in gewisser Häufung vor, gibt eine Stimmführung mit abgeschaltetem Display keinen Sinn mehr.

Letztendlich habe ich hier einen lustigen Einzelfall aufgegabelt oder nicht?

Hallo,

melde mich seit langem mal wieder mit einem Update: BRouter-0.6

Das ist ein wesentlicher Update gegenüber der vorherigen Version 0.5,
auch wenn die sichtbaren Änderungen nicht wirklich ein Showeffekt sind.

Aber durch die Erweiterung der Datenbasis auf jetzt 26 Way-Tags und
durch die Einbeziehung von Node-Tags sind die access- und die oneway
Regeln einfach deutlich präziser geworden.

Hier die Changes aus der Revision history, die jetzt ebenfalls Teil
der Web-Seite ist ( http://brensche.de/brouter )

- Extended data files (more way tags, added node tags)
- Extended profiles (global-, way-, node-context)
- more precise access + oneway rules
- more elevation parameters in profiles
- explicit configuration of base directory
- elevation=void within bridges or tunnels
- fixed gpx version header
- link counter in app animation

Die auffälligsten Änderungen an der Routen sind, dass es jetzt
(meistens..) richtig rum durch Kreisel geht und dass reine Fusswege
etwas stärker vermieden werden.

Das Datenformat hat sich geändert, d.h. bei einem Update müssen
auch die Routing-Data-Files und die Profile neu geladen werden.
Die aktuellen Daten sind jetzt mit Snapshot-Datum 4.3.2013. Damit der
Update einfacher ist, habe ich die Unterverzeichnisse umbeannt (profiles -> profiles2,
segments -> segments2 ) damit die alten und die neuen Daten ko-existieren
können.

Dadurch dass jetzt mehr Tags zur Verfügung sollte es jetzt auch möglich
sein, ein sinnvolles Profil für Wanderer zu erstellen, u.a. das "sac_scale" tag
ist mit in den Daten - ich hab' mich aber noch nicht daran probiert, bin kein
Wanderer...

Auch das Car-Routing ist jetzt deutlich brauchbarer geworden, aber weil
die Turn-Restrictions immer noch fehlen tue ich es auch nicht bewerben,
sondern man findet es nur versteckt als Profil "car-test".

viel Spass beim Radfahren und Wandern im Frühling (der hoffentlich bald wieder kommt...)

Gruss, Arndt

Hallo Arndt.

Habe Probleme bei der Installation deines Programmes. Bin allerdings auch nicht der PC Fachmann.

Habe OSMAND+ installiert. Das OSMAND Programm ist auf dem Systemspeicher des Defy+. Die Kartendaten usw sind im Ordner OSMAND auf der SD Karte. Den Pfad habe ich auch eingegeben.

Bekomme als Fehlermeldung immer: No coordinate source from a maptool found

Gruß Jürgen

derjürgen wrote:

Hallo Arndt.
Habe OSMAND+ installiert. Das OSMAND Programm ist auf dem Systemspeicher des Defy+. Die Kartendaten usw sind im Ordner OSMAND auf der SD Karte. Den Pfad habe ich auch eingegeben.

Bekomme als Fehlermeldung immer: No coordinate source from a maptool found

Hallo Jürgen,

an der Stelle sucht er die Favoriten-Datenbank von OsmAnd unter: {basdir}/osmand/favourites.gpx

wobei {basdir} das von Dir angegebene Basis-Verzeichnis ist, z.B. /mnt/sdcard Und das aktuell
gültige Basisverzeichnis müsste auch in der Fehlermeldung genannt sein.

Wenn er da nichts findet kann das zwei Gründe haben:

Entweder es gibt die Datei {basdir}/osmand/favourites.gpx nicht (vielleicht legt OsmAnd sie erst an, wenn man zum ersten Mal einen Favoriten speichert?) Oder das Basisverzeichnis ist falsch.

Im zweifel mit einem Datei-Browser nachsehen (z.B. Astro-Dateimanager, oder die SD-Karte in den PC stecken und von da nachsehen)

Wenn Du über die Hürde drüber bist, kommen noch weitere Prüfungen, es müssen noch verschiedene Dateien auf die SD-Karte kopiert werden:

{basdir}/brouter/profiles2/trekking.brf (und/oder andere Profile)
{basdir}/brouter/profiles2/lookups.dat (und/oder andere Profile)
{basdir}/brouter/segments2/E5_N50.rd5 (und/odere andere Routing-Datafiles)

und wenn er irgendwas nicht findet wird er wieder meckern..

viel Erfolg (und einfach fragen wenn unklar)

Gruss, Arndt

Hallo Arndt, super Arbeit! Ich bin total begeistert von Deinem Programm. Meinst Du, daß es in Zukunft auch Support für OruxMaps geben wird? Der 'from-to' Ansatz über lesezeichen müßte bei OruxMaps doch auch gehen. Da kann man easy Wegpunkte exportieren die der BRouter nur erkennen müßte. Es wäre super, dann das irgendwann kommt.
Ich gehe jetzt mal meine Fahrradreifen aufpumpen 😄.

vipanny wrote:

Meinst Du, daß es in Zukunft auch Support für OruxMaps geben wird? Der 'from-to' Ansatz über lesezeichen müßte bei OruxMaps doch auch gehen. Da kann man easy Wegpunkte exportieren die der BRouter nur erkennen müßte. Es wäre super, dann das irgendwann kommt.

Ich habe heute die Version 0.7 deployed mit

- Support für OruxMaps
- Support für Zwischenpunkte (via-points)
- Support für Sperrpunkte (nogo-points)

In der Google-Group, die von der Projektseite http://brensche.de/brouter aus erreichbar ist, habe ich das näher beschrieben (englisch).

Bin nicht so ganz zufrieden mit der OruxMaps-Anbindung, weil man da keine Wegpunkte ändern kann, und das macht es etwas unhandlich, aber es geht.

Gruss, Arndt

abrensch wrote:

- Support für Zwischenpunkte (via-points)

Vorsichtshalber in ReadMe.txt ist das noch nicht erläutert.

abrensch wrote:

vipanny wrote:

Meinst Du, daß es in Zukunft auch Support für OruxMaps geben wird? Der 'from-to' Ansatz über lesezeichen müßte bei OruxMaps doch auch gehen. Da kann man easy Wegpunkte exportieren die der BRouter nur erkennen müßte. Es wäre super, dann das irgendwann kommt.

Ich habe heute die Version 0.7 deployed mit

- Support für OruxMaps
- Support für Zwischenpunkte (via-points)
- Support für Sperrpunkte (nogo-points)

In der Google-Group, die von der Projektseite http://brensche.de/brouter aus erreichbar ist, habe ich das näher beschrieben (englisch).

Bin nicht so ganz zufrieden mit der OruxMaps-Anbindung, weil man da keine Wegpunkte ändern kann, und das macht es etwas unhandlich, aber es geht.

Gruss, Arndt

Toll! Danke! Ich wollte vorm Schlafen noch kurz hier vorbei schauen, und dann sowas 🙂. Funktioniert super mit OruxMaps! Merci beaucooouuuup 😄!

abrensch wrote:

Ich habe heute die Version 0.7 deployed mit

Ich habe Locus und Osmand gleichzeitig auf dem Handy. Starte ich BRouter, dann will dein Programm mit Locus arbeiten. Da ich im Locus keine Punkte definiert habe sondern in Osmand, arbeitet das Programm nicht.

Ich musste Locus deinstallieren, damit Brouter mit Osmand zusammenarbeiten kann.

Ich befürchte, wenn jemand Oruxmap und Osmand auf dem Handy hat, dass derjenige nicht mit Oruxmap arbeiten kann. Alphabetische Reihenfolge.

GUFSZ wrote:

Da ich im Locus keine Punkte definiert habe sondern in Osmand, arbeitet das Programm nicht .. Alphabetische Reihenfolge.

Nicht alphabetisch, sondern sortiert nach dem last-modified-timestamp der jeweiligen Wegpunkte-Datei, das sind:

{basedir}/osmand/favourites.gpx
{basedir}/oruxmaps/tracklogs/oruxmapstracks.db
{basedir}/Locus/data/database/waypoints.db

D.h. eigentlich sollte die Quelle genommen werden, die zuletzt geändert wurde
(allerdings unabhängig davon, ob wirklich die relevanten Wegpunkte geändert
wurden)

In meinen Tests hat das auch immer funktioniert.

Hast Du vielleicht wirklich Deine Wegpunkte in OsmMand früher schon gesetzt?
Oder irgendwann das Handy-Datum verstellt, so dass die Locus Datei
einen Zeitstempel in der Zukunft hatte?

Oder habe ich hier noch einen Bug. Werde aber nochmal drüber nachdenken,
wie ich das robuster machen kann.

Gruss, Arndt

Ich habe jetzt mal Locus wieder installiert.

Bevor ich Locus gestartet habe, blieb nach dem Start von Brouter der Bildschirm schwarz. Nach Start von Locus und dem Akzeptieren der Bedingungen moserte Brouter wieder, dass es im Locusordner nichts findet. Das nur zu Info

Nachdem ich in Osmand, meine ewig alten from und to Punkte ersetz habe, funktioniert es.

VolkerKutschka wrote:

Also ich hab mir jetzt mal alle nötigen Daten gezogen und in den Ordner brouter /segments2 und profiles2 kopiert.dann die APP installiert.fragt nach einem Pfad.aus der englischen Anleitung werd ich nicht schlau.kann mir mal jemand weiterhelfen?
Danke und lgg Volker.

Hi Volker,

ich antworte mal im "richtigen" Faden.

BRouter fragt nach dem Basisverzeichnis der SD-Card, also das Verzeichnis im Android-Dateisystem, relativ zu dem die Arbeitsverzeichnisse sowohl von brouter als auch osmand (, locus, oruxmaps) liegen.

Typisch ist das /mnt/sdcard oder /mnt/sdcard/external_sd oder so. Der Vorschlag, dem BRouter macht, sollte auch nicht ganz daneben sein.

Bei OsmAnd gibt es eine Menu-Option, um das Arbeitsverzeichnis einzustellen. BRouter braucht einfach das selbe.

Gruss, Arndt

abrensch wrote:

VolkerKutschka wrote:

Also ich hab mir jetzt mal alle nötigen Daten gezogen und in den Ordner brouter /segments2 und profiles2 kopiert.dann die APP installiert.fragt nach einem Pfad.aus der englischen Anleitung werd ich nicht schlau.kann mir mal jemand weiterhelfen?
Danke und lgg Volker.

Hi Volker,

ich antworte mal im "richtigen" Faden.

BRouter fragt nach dem Basisverzeichnis der SD-Card, also das Verzeichnis im Android-Dateisystem, relativ zu dem die Arbeitsverzeichnisse sowohl von brouter als auch osmand (, locus, oruxmaps) liegen.

Typisch ist das /mnt/sdcard oder /mnt/sdcard/external_sd oder so. Der Vorschlag, dem BRouter macht, sollte auch nicht ganz daneben sein.

Bei OsmAnd gibt es eine Menu-Option, um das Arbeitsverzeichnis einzustellen. BRouter braucht einfach das selbe.

Gruss, Arndt

Hi vielen Dank erstmal Arndt,
mal schauen ob ich das so hinbekomme.
Wie funktioniert das dann in Locus und Oruxmaps? Genauso mit den Punkten setzen "from" und "to"?
LG Volker

VolkerKutschka wrote:

Hi vielen Dank erstmal Arndt,
mal schauen ob ich das so hinbekomme.
Wie funktioniert das dann in Locus und Oruxmaps? Genauso mit den Punkten setzen "from" und "to"?
LG Volker

Hi Volker,

Ja, genauso mit "from" und "to" - klappt wunderbar 🙂.

GUFSZ wrote:

- Support für Zwischenpunkte (via-points)

Vorsichtshalber in ReadMe.txt ist das noch nicht erläutert.

Habe die readme.txt jetzt (für die Version 0.8) überarbeitet und das mit aufgenommen.

Wobei die spannendere Geschichte ja eigentlich die "nogo" Punkte sind, und die hatten in der Version 0.7 noch ein Problem (dokumentiere niemals eine schlechte Lösung, sondern verbessere sie...)

In 0.7 wurden nogo-Punkte genau wie die Wegpunkte auf "nicht Triviale Knoten" gemapped, also zur nächsten Abweigung, Kreuzung etc. Damit waren die nur beschränkt benutzbar, und ich brauchte z.B. 6 Sperrpunkte, um die Rheinbrücke bei Worms zu sperren... Jetzt (0.8) werden die geometrisch gemapped, wie man das auch erwartet, d.h. eine nogo-Area mit z.B. 20m Radius sperrt jeden Weg, der diese Scheibe berührt. Und der Radius ist konfigurierbar, sodass man z.B. mit einem "Wegpunkt" mit Namen "nogo40000 Schwarzwald" auch eine ganze Region sperren kann und nicht nur eine Brücke.

Und apropos geometrisches Mapping von Wegpunkten. Auch für die "from", "to" und "via" Punkte verwendet BRouter ja das simple Mapping auf den nächsten (Luftline!) nichttrivialen Knoten. Das ist bisher gut genug, und es hat sich auch noch keiner beschwert, aber:

- im Online Protokoll sehe ich immer wieder gescheiterte Routings, weil der Zielpunkt auf einer "Insel" liegt oder auf einem Privatparkplatz etc und die laufen dann ewig und der Benutzer weiss nicht, warum

- ich experimentiere mit dynamischer Neuberechnung, und da reicht das einfach nicht, weil hier ja das Maptool die Neuberechnung triggert und die aktuelle GPS-Position als Startpunkt vorgibt. Und dann ist das simple Mapping zum nächsten Knoten auch mal auf der anderen Seite der Bahnlinie und dann hat man ein Problem. Ich habe also auch für das Wegpunkt-Mapping jetzt ein "Line-Matching" implementiert was auch nur Wege findet, über die das Profil routen kann. Das habe ich aber bisher nur für die Online-Version enabled, für die Android-Version noch nicht, weil es noch ein bisschen langsam ist.

Die Version 0.8 ist auch notwendig geworden, weil bei der alten ja ab morgen (5.5.) schon ein Warnhinweis kommt wegen der Beta-Expiry, und die 0.8 läuft jetzt ein Jahr länger.

Super Arndt. Ganz hervorragende Arbeit.Ich bin jetzt schon etliche Radtouren gefahren mit Deinem Brouter. Die Wegvorschläge sind das beste was mir bisher im Bereich Radeln über den Weg gelaufen ist. Es macht richtig Spaß und mit den Berechnungen des "Save" Profiles kann ich ohne Bedenken mit meinem Sohn (sieben Jahre) losradeln. Heute 30km zusammen gefahren. Da passt einfach alles. Wenn es Dir jetzt noch gelingt Touren über 100 km berechnen zu können, dann wäre das der Oberhammer.
Ist aber kein "must have". Es gibt bei uns zuhause ganz excellente Radwege,z.B. den Mainradweg, der bei uns in Redwitz a.d.Rodach vorbeiführt bis hinunter nach Nbg und auch Richtung Schweinfurt-Würzburg. Da würde ich mir noch ein Profil von Dir wünschen das versucht so "Eben" wie möglich zu routen. Nun weiß ich eben auch das ich das "save" Profil selbst ändern kann, jedoch nicht ganz durch steige,sprich-hiermit Dich darum bitten möchte so ein Profil bereitzustellen. Evtl. wäre ein deutsches "how to modify" allererste Sahne. Übrigens, es funktioniert bei mir sowohl mit Oruxmaps,Osmand+ und Locus pro. Am liebsten ist mir dabei immer noch Osmand WG. des direkten Routings,sprich Sprachansagen und Abzweig Hinweisen und der direkten Poi Offline Anbindung und Suche.
Mittlerweile besteht mein Sohn immer drauf das Smartphone (HTC DesireX) an sein Rad zu schnallen.
Nochmals danke an Dich für Deine tolle Arbeit, das innovativste Produkt fürs Biken wie ich finde.
LG Volker

abrensch wrote:

Die Version 0.8 ist auch notwendig geworden, weil bei der alten ja ab morgen (5.5.) schon ein Warnhinweis kommt wegen der Beta-Expiry, und die 0.8 läuft jetzt ein Jahr länger.

Hey Arndt,

welche Rationale gibt es denn, die App überhaupt zu beschränken? Dass Du die App verlängert hast, ist schon mal super. Ich habe ein paar Leuten Dein Programm empfohlen und die hielten es für ungeeignet für den Sommer wg. der Expiry. Sie wollten sich einfach nicht in ein System eindenken, dass nicht mehr lange verfügbar ist.

Wäre es nicht möglich die Expiry ganz raus zu nehmen?

Viele Grüße und frohes Radeln 😄,

Vipanny

Hi Volker,

VolkerKutschka wrote:

Wenn es Dir jetzt noch gelingt Touren über 100 km berechnen zu können

Mit Zwischenpunkten kannst Du längere Touren rechnen, denn die Rechenzeit skaliert zwar quadratisch, aber das zählt bei Zwischenpunkten ja nur pro Abschnitt. Ich habe aber auch schon 250km Luftlinie am Stück gerechnet auf dem Handy, dauert halt nur sehr lange, aber geht.

Der Vorteil, wenn man eine solche Strecke "frei" rechnet statt mit Zwischenpunkten ist, dass das Suchgebiet grösser ist und man auf diese Weise natürlich Strecken finden kann, die man durch Zwischenpunkte ausgeshlossen hat.

Da würde ich mir noch ein Profil von Dir wünschen das versucht so "Eben" wie möglich zu routen.

Änder einfach die Zeile:

assign uphillcost 0

in

assign uphillcost 60

Dann hast Du die "Höhenstrafe" verdoppelt. Führt natürlich dazu, dass er dann auch mal im Maintal bleibt, obwohl jeder Ziel-Orientierte Radler die Abkürzung über den Hügel nehmen würde. Aber das ist wohl das, was Du willst.

Nun weiß ich eben auch das ich das "save" Profil selbst ändern kann, jedoch nicht ganz durch steige

Das safety-profil hat noch einen anderen Fehler: Ich benutze bisher das "cycleway" tag fast nicht (ausser für die umgekehrten Einbanhstrassen). Weil ich es auch nicht vermisse, denn hinter solchen an der Strasse getaggten Radwegen steckt oft die übliche Bordsteinkanten und Baumwurzel-Folter, und das bei Benutzungspflicht, sodass man diese Strecken nicht unbedingt suchen sollte. Vernünftige Radwege sind, zumindest in Deutschland, in OSM meist als eigener Weg eingetragen (highway=cycleway).

Für ein Safety-Profil für Kinder müsste man aber auch die "normalen" Radwege präferieren-

Danke für deine Mühe und Infos

abrensch wrote:

In 0.7 wurden nogo-Punkte genau wie die Wegpunkte auf "nicht Triviale Knoten" gemapped, also zur nächsten Abweigung, Kreuzung etc. Damit waren die nur beschränkt benutzbar, und ich brauchte z.B. 6 Sperrpunkte, um die Rheinbrücke bei Worms zu sperren... Jetzt (0.8) werden die geometrisch gemapped, wie man das auch erwartet, d.h. eine nogo-Area mit z.B. 20m Radius sperrt jeden Weg, der diese Scheibe berührt. Und der Radius ist konfigurierbar, sodass man z.B. mit einem "Wegpunkt" mit Namen "nogo40000 Schwarzwald" auch eine ganze Region sperren kann und nicht nur eine Brücke.

Die Syntax ist mir beim Durchlesen der Dokumentation und des Posts nicht klar geworden.

nogo40000␣Schwarzwald

Bedeutet das, der Schwarzwald wird komplett mit einem zusätzlichen Rand von 40km gesperrt. Oder ein Punkt der den Tag Schwarzwald hat wird in einem Radius von 40 km gesperrt.

Was kann muss ich einsetzen, wenn ich die Stadt Frankfurt am Main umfahren will.

Persönlich vermute ich auf Dauer das Problem, wenn man bestimmte Dinge umfahren will, die exakte Bezeichnung braucht. Woher bekommt man die.

Beim Schreiben merke ich, dass man vermutlich das OSM-Datenmodell verdammt gut kennen muss, um die richtige Eingabe zu machen.

Fazit: Grenzen und Möglichkeiten gehen aus der Dokumentation nicht hervor.

GUFSZ wrote:

Bedeutet das, der Schwarzwald wird komplett mit einem zusätzlichen Rand von 40km gesperrt. Oder ein Punkt der den Tag Schwarzwald hat wird in einem Radius von 40 km gesperrt.

Hi,

nein Missverständnis. Der Text "Schwarzwald" wird hier einfach ignoriert.

Nogo-Punkte sind ja beliebig viele erlaubt, also habe ich erlaubt, dass man den Nodenamen um was sprechendes ergaenzen kann, um sie wiederzuerkennen. Man bekommt ja einen Dialog ("Check nogo-selection") mit allen Wegpunkten, die mit "nogo" anfangen, und dann muss man ja wissen, was sie bedeuten.

Um Frankfurt zu umfahren, würde ich einen Wegpunkt "nogo5000 Mainhatten" auf den Hauptbahnhof setzen.

Das sperrt dann allerdings auch den Mainradweg.

vipanny wrote:

welche Rationale gibt es denn, die App überhaupt zu beschränken? Dass Du die App verlängert hast, ist schon mal super. Ich habe ein paar Leuten Dein Programm empfohlen und die hielten es für ungeeignet für den Sommer wg. der Expiry. Sie wollten sich einfach nicht in ein System eindenken, dass nicht mehr lange verfügbar ist.

Ich bin darauf angewiesen, Qualitäts-Feedback aus dem Beta-Test zu sammeln, um das Ding erstens fehlerfrei zu kriegen und die Funktionalität an die Erwartungshaltung der Benutzer anzupassen. Und funktioniert ja bisher auch ganz gut und bin ja schon ein ganzes Stück vorangekommen.

Nur: dafür muss ich von den neuen Fehlern erfahren und nicht von den längst behobenen aus älteren Versionen. Und dazu ist es wichtig, die Kontrolle zu behalten über die Versionen "im Feld". Alle machen das so, nur eben über automatische Updates oder ein serverseitig gesteuerten Update-Trigger.

Mir ist es aber wichtig, den "offline"-Charakter der App nicht anzutasten und Datenschutz-sensitive Benutzer nicht zu verschrecken indem da irgendwas "nach Hause telefoniert". Also geht das nur mit einem clientseitig gesteurten Expiry.

Wäre es nicht möglich die Expiry ganz raus zu nehmen?

Ja, schon, wenn's halbwegs fertig ist. Eigentlich wollte ich auch jetzt soweit sein, aber ich hab' noch zu viele Ideen im Kopf. Vielleicht sehe ich das ja falsch, aber fehlende Turn-Restrictions, das "schlampige" Wegpunkt-Mapping, die rein technische Beschränkung auf die Zahl der Osm-Tags etc das ist alles noch "zu beta".

Ähnliches Thema mit der deutschen Dokumentation. Würde definitiv die Nutzerzahlen pushen, aber auch eine Support-Last erzeugen, die die Weiterentwicklung bremst. Also im Moment keine Priorität.

Und es gibt natürlich den Wunschgedanken, irgendwann in Google-Play zu gehen mit einer "Killer-App", die nicht mehr nur paar hundert, sondern Hunderttausende Benutzer finden kann. Das wäre dann aber nicht mehr der nackte Offline Router, sondern eine integrierte Anwendung, und der Offline-Router in seiner jetzigen Form würde (werbe-)frei bleiben.

Gruss, Arndt

abrensch wrote:

vipanny wrote:

welche Rationale gibt es denn, die App überhaupt zu beschränken? Dass Du die App verlängert hast, ist schon mal super. Ich habe ein paar Leuten Dein Programm empfohlen und die hielten es für ungeeignet für den Sommer wg. der Expiry. Sie wollten sich einfach nicht in ein System eindenken, dass nicht mehr lange verfügbar ist.

Ich bin darauf angewiesen, Qualitäts-Feedback aus dem Beta-Test zu sammeln, um das Ding erstens fehlerfrei zu kriegen und die Funktionalität an die Erwartungshaltung der Benutzer anzupassen. Und funktioniert ja bisher auch ganz gut und bin ja schon ein ganzes Stück vorangekommen.

Nur: dafür muss ich von den neuen Fehlern erfahren und nicht von den längst behobenen aus älteren Versionen. Und dazu ist es wichtig, die Kontrolle zu behalten über die Versionen "im Feld". Alle machen das so, nur eben über automatische Updates oder ein serverseitig gesteuerten Update-Trigger.

Mir ist es aber wichtig, den "offline"-Charakter der App nicht anzutasten und Datenschutz-sensitive Benutzer nicht zu verschrecken indem da irgendwas "nach Hause telefoniert". Also geht das nur mit einem clientseitig gesteurten Expiry.

Wäre es nicht möglich die Expiry ganz raus zu nehmen?

Ja, schon, wenn's halbwegs fertig ist. Eigentlich wollte ich auch jetzt soweit sein, aber ich hab' noch zu viele Ideen im Kopf. Vielleicht sehe ich das ja falsch, aber fehlende Turn-Restrictions, das "schlampige" Wegpunkt-Mapping, die rein technische Beschränkung auf die Zahl der Osm-Tags etc das ist alles noch "zu beta".

Ähnliches Thema mit der deutschen Dokumentation. Würde definitiv die Nutzerzahlen pushen, aber auch eine Support-Last erzeugen, die die Weiterentwicklung bremst. Also im Moment keine Priorität.

Und es gibt natürlich den Wunschgedanken, irgendwann in Google-Play zu gehen mit einer "Killer-App", die nicht mehr nur paar hundert, sondern Hunderttausende Benutzer finden kann. Das wäre dann aber nicht mehr der nackte Offline Router, sondern eine integrierte Anwendung, und der Offline-Router in seiner jetzigen Form würde (werbe-)frei bleiben.

Gruss, Arndt

Hallo Arndt,

das hört sich alles sehr gut an! D.h. Du hast große Pläne mit der App und das freut mich sehr! Meine Befürchtung war, dass das Projekt irgendwann einschlafen könnte und dann wenig später auch die App nicht mehr funktionieren würde. In dem von Dir vorgesehenem Szenario bin ich gerne Beta Tester! Ich mag Radfahren und ich mag Radfahrer. Je mehr Menschen auf das Rad umsteigen und das Auto häufiger stehen lassen, desto besser für uns alle 😄. Wenn die Version in der bisherigen Art frei bleibt, ist das mehr als fair. Ich drücke die Daumen, dass eine Killer-App dabei rauskommt und trage gern dazu bei, dass die aktuelle Version noch besser wird 🙂.

Hi Arndt
Danke für den Tipp mit dem Kostenfaktor und den via-points.
Aber mal wieder zurück zur Sache, auch um Dir zu bestätigen, daß Du auf dem richtigen Weg bist. Ich finde das der Beta Status schon extremst vielversprechend ist.
Mich stört jetzt eigentlich nur noch eines konkret an Deinem Brouter---das direkte ansteuern der via-points.
Praktisch schaut es so aus, das ich z.B. von Redwitz nach München mit dem Fahrrad fahren möchte-also setze ich via-points-vollkommen logisch.
Allerdings will ich einfach nur sagen--hey Junge--fahre bitte über Bamberg(via) - aber bitte nicht direkt auf dem via-punkt(meist das geographische Zentrum wenn ich in Locus einfach Bamberg als Suchkriterium schnell auswähle) - sondern einfach praktisch Richtung Bamberg aber immer schön dem Profil entsprechend.
Ich denke Du weißt was ich meine--- eine Art ungefähre Richtungsangabe
praktisch1 würde ich dann vorschlagen so eine Art "via1-around2000(2km um den Punkt herum)" für die ungefähre Richtung.
praktisch2 würde ich dann für ein direktes ansteuern des via-punktes das "via1" so belassen.

Via bedeutet in dem Sinne für mich --- Hey klasse, genau in den Biergarten will ich reingehen als Zwischenziel
Via-around bedeutet für mich --- kein Alkohol am Steuer*grins* - aber fahr mal trotzdem in die Richtung des Biergartens.

Da bin ich ja mal gespannt auf Deine Killer-App , da bin ich voll dabei weil ich merke, daß Du genau weißt was Du tust und der Weg einfach passt.
Aber bitte keine Experimente mit Online-Kartenmaterial bzw. Online Verbindung während des Routings.
Wobei ich ganz ehrlich sagen muß, daß ich bereits mit dem jetzigen Zustand sehr zufrieden bin. Am besten ist es in Locus integrierbar, da ich einfach in Locus über die Bedienfelder eine App hinzufügen kann (Dein Brouter) ohne Locus klein schalten zu müssen.
Ein grafisches Interface hast Du Doch in Form von ORUX,OSMAND,LOCUS. > Punkte in der Karte antippen-benennen-Brouter starten > das finde ich sehr komfortabel.
Deine Punkte kann man ja auch schon an-abwählen.
Die App im jetzigen Zustand trifft den Tourenplaner doch eigentlich schon mitten ins Herz.
Ganz klar, ich kann aber Deinen Anreiz nach ner eigenständigen App voll verstehen-zumal Du irgendwann auch mal "Cash" dafür sehen willst.

In diesem Sinne weiter so und ich hoffe das ich mit den ein oder anderen Vorschlägen behilflich sein kann.
Ich programmiere selbst in C und Basic intern in der Firma für unser CAM-System und weiß um die ganze Problematik außen herum .... es hört sich immer so einfach an.....Ratschläge: mach mal dies und das...aber warum hast Du nicht?.............
LG Volker

P.S. : Routenberechnung von Redwitz nach München über via Points !!! "Darf ich dich küssen??" das passt-klasse.

@Arndt:

Kennst Du eigentlich OpenAndroMaps? Das sind großartige weltweite offline Radvektorkarten aus den Daten der OpenCylceMaps. Das Projekt wird von Christian umgesetzt - einem Radfahrer, der sich auch gerne für die Community einsetzt - und das mit Herzblut. Seine Karten sind unschlagbar gut! Eine Offline App mit Deinem Routing, seinen Karten und einem intuitiven Interface wäre die Erfüllung der kühnsten Träume aller Radfahr-Navigatoren 😉!

Ach: Den Punkt von Volker zu den "via1-around" kann ich voll unterstützen! Finde ich sehr sinnvoll und habe ich mir auch schon mal gewünscht.

So, mal meine 2 Cents zur Killer-App 🙂

Wenn Du wirklich die Killer-App willst, ist ja das wichtigste, den Need zu analysieren. Ich fasse hier mal meine Sicht zusammen:

Der Schwachpunkt aller Smartphones ist der Akkuverbrauch des Displays. Beim Energieverbrauch haben OutdoorGPS gegenüber Smartphones einfach das intelligentere Display. Also muß man mit dem Energieproblem umgehen. Hier mein bisheriger Ansatz:

Ich nutze aktuell Dein Routing zusammen mit den OpenAndroMaps in OruxMaps. Zusätzlich setze ich Wegpunkte an Stellen, an denen ich auf die Karte schauen sollte, weil ich nicht nur einfach geradeaus fahren kann. Wenn ich nicht zu faul bin, versehe ich die Wegpunkte mit Text, der dann über OruxMaps ausgesprochen wird, wenn ich an den Koordinaten ankomme. So sagt mir OruxMaps "halb links" und ich weiß Bescheid. Allerdings muss ich den Ansage-Text immer umständlich in den Wegpunkt schreiben (sehr nervig). Wenn ich faul bin, setze ich die Wegpunkte ohne Text (bei 100km braucht man 5-6min, um die ganze Strecke durchzugehen), lasse ich mich am WegPunkt nur akustisch alarmieren und schaue dann kurz auf die Karte. Vorteil im Vergleich zum OutdoorGPS: Ich muss nicht immer auf die Karte schauen. Und genau das will ich auf einer Radtour auch nicht - da will ich die Gegend genießen. Ach: Falls ich bei den Wegpunkten einen vergessen habe: OruxMaps meldet sich, wenn ich die Router mehr als 160m verlassen habe.

Wer jetzt sagt, man könne sich doch bei bestehender Route sehr gut von OSMand sprachlich navigieren lassen, der hat es wohl noch nicht getestet. Die App hört gar nicht auf zu labern. An entspanntes Radfahren ist so nicht mehr zu denken. Manchmal besser als nichts, aber überzeugt hat mich das nicht...

Wenn das Display eingeschaltet bleiben sollte, könnte man es nach 30sek immer automatisch auf eine geringere Helligkeitsstufe regeln. Ein Klick auf den Touchscreen müsste dann sofort für eine Erhöhung der Helligkeit sorgen. Das Gerät nach 30sek ganz abzuschalten ist in meinen Augen keine gute Lösung, weil man es häufig umständlich wieder einschalten muss (Schalter häufig oben oder an der Seite, nicht an der Front). Benutzt man das Handy in einer Handy-Radtasche mit durchsichtiger Folie (vor Wetter und ausreichend vor Stössen geschützt - auf meiner Sicht die einzige sinnvolle Transportlösung), bringt einem der Schalter an der Seite gar nichts - man kommt nicht dran. Ich nutze aktuelle in altes Handy mit Powerschalter an der Front, aber da es sehr lahm ist, ist es nur eine Verlegenheitslösung. Im Sommer nutze ich auch mal eine einfache Halterungen ohne Schutz, aber das mache ich immer ungern (Smartphone ist mir schon mal rausgefallen).

Wenn Deine finale App da eine Lösung hätte, wärst Du an der Killer-App nah dran 😉.

..man kann aber auch in Osmand den Ton ausschalten und nach den Pfeilen fahren, also was direktes Routing betrifft dann ganz klar Osmand, da es die Gpx-Daten am besten auswertet und informiert. Dafür hat Locus und Orux andere Vorteile-ich mag sie alle drei und entscheide immer kurzfristig. Wenn ich Tracks auf zeichne verwende ich aber meist Locus, da es auch automatisch Sprachanweisungen gibt während dem gpx-routing. Wenn ich mit dem Rennrad auf Speed unterwegs bin,dann nehme ich Oruxmaps, da es bei der Aufnahme Infos in Sprachform gibt über Durchschnittsgeschwindigkeit etc. und das Dasboard klasse ins Display integriert ist.
Zurück zum Thema: Wenn ich Arndts Talent hätte, würde ich versuchen das ganze grafisch aufzuwerten und als Standalone neben Osmand,Orux,Locus laufen lassen. Es wird ungemein schwer an das Potenzial der drei Programme heran zu kommen,also lieber auf die wichtigen Sachen konzentrieren und vorhandenes optimieren und konsolidieren. Ich versuche auch in meinen eigenen Scripts|Makros möglichst modular und konzentriert auf Universalität zu programmieren. Ein gutes Interface mit dem streben nach wenigen Klicks und guter Überschaubarkeit.
LG Volker.

vipanny wrote:

Wer jetzt sagt, man könne sich doch bei bestehender Route sehr gut von OSMand sprachlich navigieren lassen, der hat es wohl noch nicht getestet. Die App hört gar nicht auf zu labern. An entspanntes Radfahren ist so nicht mehr zu denken. Manchmal besser als nichts, aber überzeugt hat mich das nicht...

Also Osmand ist die zweitbeste Sprachführung, die ich kenne und nutze. Die beste ist meiner Meinung nach die des Oziexplorers unter Windows Mobile. GArmin ist nicht brauchbar und Locus zu unzuverlässig.

Bei Osmand hat man immer noch nicht gelöst, was Victor auf Englisch das Wenkelproblem nennt. Man fährt auf eine Kreuzung zu, und bekommt statt leicht rechts scharf rechts gesagt. Dies hat etwas mit unzureichenden OSM-Daten zu tun.

Brouter und Osmand sollten aber meiner Meinung eine Sache lösen. Wenn was schief geht, sind es nach Entwicklermeinung ganz gerne die unzureichenden OSM-Daten. Da es aber ähnliche Fehlersituationen sind, sollte man sich vielleicht Heuristiken einfallen lassen, um solche Fehlersituationen zu erkennen und mit ihnen umzugehen.

Z.B. highway berührt in der graphischen Darstellung den anderen highway, sind aber nicht verbunden. Ich würde mal behaupten, wenn es zwei highway=track sind, dann dürfte das de facto ein Fehler sein. highway=track highway=motorway sollten getrennt bleiben.

GUFSZ wrote:

Brouter und Osmand sollten aber meiner Meinung eine Sache lösen. Wenn was schief geht, sind es nach Entwicklermeinung ganz gerne die unzureichenden OSM-Daten. Da es aber ähnliche Fehlersituationen sind, sollte man sich vielleicht Heuristiken einfallen lassen, um solche Fehlersituationen zu erkennen und mit ihnen umzugehen.

Z.B. highway berührt in der graphischen Darstellung den anderen highway, sind aber nicht verbunden. Ich würde mal behaupten, wenn es zwei highway=track sind, dann dürfte das de facto ein Fehler sein. highway=track highway=motorway sollten getrennt bleiben.

Heuristiken mögen nützlich sein, um problematischen Situationen (nahe aber nicht verbunden, Kreuzung ohne Verbindung, ...) zu erkennen. Allerdings ist es ohne Ortskenntnisse (oder manchmal sehr guten Luftbildern) nicht entscheidbar, ob das nun real so ist oder ob ein Datenfehler vorliegt.

Da erwartest du zuviel von den Routern. Sie sollen ein Problem automatisiert lösen, was aus gutem Grund nicht automatisiert korrigiert wird.

Edbert (EvanE)

Gibt es irgendwo eine Doku zu den Profildateien?
Was heißt z.B.
assign downhillcost switch consider_elevation 60 0
assign downhillcutoff 1.5
assign uphillcost 0
assign uphillcutoff 1.5

Ich hätte eher vermutet, das uphill Kosten verursacht und nicht downhill. 😎

Chris

chris66 wrote:

Gibt es irgendwo eine Doku zu den Profildateien?
Was heißt z.B. ...

Ich hätte eher vermutet, das uphill Konsten verursacht und nicht downhill. 😎

Hallo Chris

Es gibt durchaus Leute, die ungern steile Straßen abwärts fahren, da es ihnen dann zu schnell wird. Es soll sogar Leute geben, die in solchen Situationen lieber absteigen und das Fahrrad schieben.

Aufwärts empfinden solche Leute als sicherer, da die Geschwindigkeit sehr viel niedriger liegt.

Edbert (EvanE)

chris66 wrote:

Gibt es irgendwo eine Doku zu den Profildateien?

http://brensche.de/brouter/profile_developers_guide.txt

Was heißt z.B.
assign downhillcost switch consider_elevation 60 0
assign downhillcutoff 1.5
assign uphillcost 0
assign uphillcutoff 1.5

Ich hätte eher vermutet, das uphill Konsten verursacht und nicht downhill. 😎

Was hoch geht muss auch wieder runter... Von daher ist es egal, was man zählt. Der Unterschied ist nur, dass man dararuf diese 1,5% Cutoff anwenden kann, also entweder flache Abstiege und/oder flache Aufstiege bevorzugen gegenüber steilen Strecken.

EvanE wrote:

Es gibt durchaus Leute, die ungern steile Straßen abwärts fahren, da es ihnen dann zu schnell wird.

Dazu zähl ich mich nicht. Bei mir kann es downhill schonmal 3 stellig werden. 😎

chris66 wrote:

EvanE wrote:

Es gibt durchaus Leute, die ungern steile Straßen abwärts fahren, da es ihnen dann zu schnell wird.

Dazu zähl ich mich nicht. Bei mir kann es downhill schonmal 3 stellig werden. 😎

Nun ja, es ist dein Leben.
Hoffentlich hast du hervorragende Bremsen.

@abrensch: Für eine einfache Strecke oder einen Rundkurs gilt deine Aussage
"Was hoch geht muss auch wieder runter"
nur begrenzt. Oder berücksichtigst du die Richtung der Route nicht?

Edbert (EvanE)

vipanny wrote:

Ach: Den Punkt von Volker zu den "via1-around" kann ich voll unterstützen! Finde ich sehr sinnvoll und habe ich mir auch schon mal gewünscht.

Man kann sowas ähnliches machen mit 2 nogo-Kreisen, zwischen denen der "via-around" als Durchgang frei bleibt.

Was mit via-Punkten ja ohnehin schwierig ist, ist dass man damit nicht dynamisch neu berechnen kann, weil man ja nie genau weiss, ob man einen via-Punkt jetzt noch beachten muss oder man ja "eigentlich" schon dran vorbei ist, ohne ihn wirklich erreicht zu haben. Nogo-Areas haben dieses Problem nicht, weshalb sie als Planungs-Hilfsmittel in Verbindung mit dynamischer Neuberechnung die bessere Wahl sind (DAfür bringen sie aber bei der Rechenzeit nicht den selben Gewinn wie via-Punkte)

Wenn ich sowas wie "via-around" implementieren würde, würde ich's also wohl intern auch über einen Kostenaufschlag für die Nachbargebiete abbilden.

Wenn wir BRouter das erste Mal öffnen wollen, erhalten wir die Meldung "Enter SDCARD base dir: (no basedir configured previously) /mnt/sdcard" angezeigt. Sobald wir auf OK drücken erscheint danach jedesmal die Meldung "An Error occured: from-position not found! (coordinate-source: /mnt/sdcard/oruxmaps)" beim Start der App. OruxMaps ist auf dem Android installiert. Welcher Pfad müssen wir beim ersten Start angeben?

Navi@Map09 wrote:

Wenn wir BRouter das erste Mal öffnen wollen, erhalten wir die Meldung "Enter SDCARD base dir: (no basedir configured previously) /mnt/sdcard" angezeigt. Sobald wir auf OK drücken erscheint danach jedesmal die Meldung "An Error occured: from-position not found! (coordinate-source: /mnt/sdcard/oruxmaps)" beim Start der App. OruxMaps ist auf dem Android installiert. Welcher Pfad müssen wir beim ersten Start angeben?

Die Fehlermeldung "from-position not found!" belegt eigentlich, dass mit dem Pfad alles in Ordnung ist (D.h. BRouter benutzt das selbe Basisverzeichnis wie Oruxmaps), es fehlen einfach nur die Wegpunkte "from" und "to", die Du im Oruxmaps anlegen musst, um BRouter zu sagen, von wo nach wo er routen soll.

abrensch wrote:

Habe die readme.txt jetzt (für die Version 0.8) überarbeitet und das mit aufgenommen.

Da steht:

Download␣the␣file␣"brouter_0_8.zip"

Ich finde die nicht. Ixh nehme an, Du meinst http://brensche.de/brouter/BRouter.apk

@abrensch: Vielen Dank für die schnelle Antwort. Nun erscheinte bei uns noch eine andere Meldung "An Error occured: The segments-directory /mnt/sdcard/brouter/segments2 contains no routing data files (*.rd5). see ... Habe mir dann die readme.txt Datei mal genauer durchgelesen. Und siehe da. Wer lesen kann, ist klar im Vorteil. Wir mussten noch eine der *.rd5 Dateien extra herunterladen. Jetzt sollte alles supi funktionieren. Besten Dank.

GUFSZ wrote:

Also Osmand ist die zweitbeste Sprachführung, die ich kenne und nutze.

Da redest Du jetzt jetzt aber von Fahrrad-Navigation? Ich glaub bei Auto-Navigation sind die Marktführer schon noch einen Schritt weiter.

Bei Osmand hat man immer noch nicht gelöst, was Victor auf Englisch das Wenkelproblem nennt. Man fährt auf eine Kreuzung zu, und bekommt statt leicht rechts scharf rechts gesagt. Dies hat etwas mit unzureichenden OSM-Daten zu tun.

Bei OsmAnd ist vieles noch nicht gelöst, nur in dem Fall kann es schlicht nichts mit unzureichenden OSM-Daten zu tun haben, weil OsmAnd an dieser Stelle die OSM-Daten überhaupt nicht nutzt, sondern ausschliesslich den berechneten Track verwendet.

Ich denke in der Tat, dass es genau hier den Preis zu gewinnen gibt. Wie schon gesagt, ich experimentiere zur Zeit mit der Integration in OsmAnd und beutzte dazu BRouter als Online-Dienst. Habe mir dazu OsmAnd so gepatched, dass es meinen Server kontaktiert statt den des konfigurierten Dienstes und einen gesonderten Dienst auf dem Server gestartet. Die automatischen Neuberechnungen sind schon ein echter Vorteil. Wenn ich das jetzt noch so hinkriege, dass es komplett offline läuft, langstreckenfähig und voll konfiguriertbar ist (=Profil + nogo-Areas), dann wäre das schon nicht schlecht, wenn da nicht diese grottenschlechten Sprachansagen wären.

Und da denk ich drüber nach, ob man nicht als ersten Schritt zur Integration zunächst mal den Neuberechnungstrigger und die Sprachausgaben in BRouter abbilden kann und damit erstmal die "Hemdentaschen-Navigation" brauchbar kann. Und ob man dann noch selbst eine offline-Karte rendert oder eine definierte Schnittstelle zu maptools baut, die das übernehmen, würde sich dann schon ergeben.

abrensch wrote:

Ich denke in der Tat, dass es genau hier den Preis zu gewinnen gibt. Wie schon gesagt, ich experimentiere zur Zeit mit der Integration in OsmAnd und beutzte dazu BRouter als Online-Dienst. Habe mir dazu OsmAnd so gepatched, dass es meinen Server kontaktiert statt den des konfigurierten Dienstes und einen gesonderten Dienst auf dem Server gestartet. Die automatischen Neuberechnungen sind schon ein echter Vorteil. Wenn ich das jetzt noch so hinkriege, dass es komplett offline läuft, langstreckenfähig und voll konfiguriertbar ist (=Profil + nogo-Areas), dann wäre das schon nicht schlecht, wenn da nicht diese grottenschlechten Sprachansagen wären.

Und da denk ich drüber nach, ob man nicht als ersten Schritt zur Integration zunächst mal den Neuberechnungstrigger und die Sprachausgaben in BRouter abbilden kann und damit erstmal die "Hemdentaschen-Navigation" brauchbar kann. Und ob man dann noch selbst eine offline-Karte rendert oder eine definierte Schnittstelle zu maptools baut, die das übernehmen, würde sich dann schon ergeben.

Wow! Das hört sich sehr vielversprechend an 🙂.

Hallo,
leider reichen meine Kenntnisse nicht aus um Brouter mit Oruxmaps zu verbinden.
Gelingt mir die Speicherung der Webseite am PC, verzweifel ich damit am
Android Tablet.
Wie so wir nicht einfach eine GPX Datei heruntergeladen wenn man bei der
Onlinerversion das entsprechende Feld anklickt?

edit:

Ich kann mittlerweile meine Frage selbst beantworten.

Erzeugen der Textseite aus der Online Version von Brouter mit Firefox.
Alles markieren durch längeres Drücken auf das Textfeld.
Kopieren durch längeres drücken auf das Textfeld.
Einen Texteditor öffen, hier Office Suite Pro, drücken auf leeres Textfeld, der Text wird eingefügt.
Speichern als txt Datei.
Umbenennen mit einem File Explorer in *.gpx
Die GPX Datei mit Oruxmaps öffnen.

Es wäre toll wenn das etwas einfacher funktionieren würde.
Danke an das tolle Programm an den Autor.
jörg

abrensch wrote:

Ich habe also auch für das Wegpunkt-Mapping jetzt ein "Line-Matching" implementiert was auch nur Wege findet, über die das Profil routen kann. Das habe ich aber bisher nur für die Online-Version enabled, für die Android-Version noch nicht, weil es noch ein bisschen langsam ist.

Heute habe ich die Version 0.9 veröffentlicht, die grundsätzlich das neue Location-Matching verwendet. Und es ist auch nicht mehr spürbar langsamer.

Es werden also Wegpunkte jetzt immer so zu Wegen gematched, dass der nächstgelegene Weg verwendet wird, der im Routing-Profil erlaubt ist.

Klingt wie ein unwesentliches Detail und ist es auch, wenn man die Wegpunkte selber setzt, aber für die Integration in ein Navigationssystem mit automatischer Neuberechnung ist es natürlich ganz wesentlich.

Und ich betreibe auch schon einen Online-Service und wer's probieren will und hacken kann, kann ja mal in OsmAnd die URL für yournavigation durch meine ersetzen, damit OsmAnd solche URLs ruft:

http://h2096617.stratoserver.net:7777/b … 20HTTP/1.1

Super Arndt.
Wenn du mir jetzt noch verraten tust, welche Datei man in Osmand hacken muß, wo sie zu finden ist und welche Zeile durch was zu ersetzen ist.LG Volker

VolkerKutschka wrote:

Super Arndt.
Wenn du mir jetzt noch verraten tust, welche Datei man in Osmand hacken muß, wo sie zu finden ist und welche Zeile durch was zu ersetzen ist.LG Volker

Suche mal nach "www.yournavigation.org/api/1.0/gosmore.php?format=kml" in den Java-Dateien und ersetze das durch "h2096617.stratoserver.net:7777/brouter?format=kml".

couchmapper wrote:

Suche mal nach "www.yournavigation.org/api/1.0/gosmore.php?format=kml" in den Java-Dateien und ersetze das durch "h2096617.stratoserver.net:7777/brouter?format=kml".

Ich bin wieder einen schönen Schritt weiter, indem ich diesen "Online-Dienst" auf dem Telefon laufen lasse, womit es dann natürlich ein Offline-Dienst wird, aber das ist ja mein Ziel, eine voll-konfigurierbare Offline-Lösung zu schaffen, weshalb ich über diese Online-Spielereien auch garnicht so viel reden wollte. Insbesondere die Möglichkeit, in einem integrierten Routing mit automatischer Neuberechnung auch Sperrgebiete zu berücksichtigen hatte ich vorher nicht. Das geht jetzt.

Das ist schon ganz cool, und ich habe dazu dier Version BRouter 0.9.1 deployed, die diesen Android Dienst startet. Der notwendige Patch zu OsmAnd ist aber leider immer noch nur Hackern zugänglich, funktioniert wie oben beschrieben, nur dass es statt "h2096617.stratoserver.net:7777" dann "localhost:17777" heisst, damit OsmAnd auf einen lokal laufenden Service zugreift.

Ich habe selber von einem cleveren User eine Anleitung bekommen, wie man den Patch mit dem "apktool" hinkriegt, ohne OsmAnd wirklich von den Sourcen bauen zu müssen.

Ich würde ja gerne ein gepatches OsmAnd APK zur Verfügung stellen, aber das lässt die Lizenz wohl nicht zu.

Das mit dem Offline interface ist ein "uraltes" Thema (alt gemessem am Tempo der Entwicklung auf diesem Feld), siehe hier:

https://groups.google.com/forum/?fromgr … aCDL5_xHkk

https://groups.google.com/forum/?fromgr … 98kmpxxD0J

Und das Thema ist auch noch nicht zu Ende, ein "entgültiges" Offline-Interface, was dann auch in die OsmAnd releases eingehen könnte, braucht sicher noch bisschen Hirnschmalz, und insbesondere die schnelle, partielle Neuberechnung, die ich unter dem Zwiten dieser Links mal beschrieben hatte, die muss ich jetzt endlich mal machen.

Hallo,

darf ich mal kurz dazwischen funken?

Kann man den BRouter nicht unter Verwendung der "INTENTS" -Schnittstelle mit OruxMaps "verheiraten". Da steht zum Beispiel im Manual unter anderem folgendes:

OruxMaps INTEGRATION
....
...You can also show a route based on a set of points and / or waypoints:
//Offline map on current position
//Intent i = new Intent("com.oruxmaps. VIEW_MAP_OFFLINE ");
//Online map
Intent i = new Intent("com.oruxmaps.VIEW_MAP_ONLINE");
//Waypoints
double[] targetLat = {33.4,8.3,22.2};
double [] targetLon = {33.4,8.3,22.3};
String [] targetNames = {"point alpha","point beta"};
i.putExtra("targetLat", targetLat);
i.putExtra("targetLon", targetLon);
i.putExtra("targetName", targetNames);
//Track points
double[] targetLatPoints = {33.43,8.32,22.24};

Ich habe aber keine Ahnung was Intents sind. Mit diesen kann man wohl ein Programm von einem anderen Programm fernsteuern, falls ich das richtig verstanden habe. Eventuell kann man dort im Forum erforderliche Intents vorschlagen, um BRouter nahtlos zu integrieren

...oder liege ich da voll daneben?
......dann SORRY...

Viele Grüsse
Achim

womisa wrote:

Ich habe aber keine Ahnung was Intents sind. Mit diesen kann man wohl ein Programm von einem anderen Programm fernsteuern, falls ich das richtig verstanden habe. Eventuell kann man dort im Forum erforderliche Intents vorschlagen, um BRouter nahtlos zu integrieren

...oder liege ich da voll daneben?

Nein, genau richtig. Es geht darum, die HTTP-Schnittstelle durch eine zu ersetzen, die zum Android Programmiermodell passt. Intents sind dabei nur die Nachrichten samt Empfaengeradresse, die da ausgetauscht werden, eine Schnittstelle wäre z.B. ein "Bound Service". Hat gegenüber meine jetztigen Implementierung auch so Vorteile, dass man den Dienst nicht starten muss (sondern das macht der anfragende Client implizit) und dass man einen Auswahldialog bekommt, wenn es mehrere Implementierungen für einen angefragten Dienst (hier: Routenberechnung) gibt. Aber ich bin da noch im unteren Teil der Lernkurve...

Gruss, Arndt

PS: tolle E-Bike Runde heute durch den Odenwald, 60km/600 Höhenmeter und ich hab's vorher gewusst und der Akku hat gehalten :-)

Kein Glück hier mit dem Server-Mode auf Android, BRouter schmiert nach wenigen Sekunden mit "BRouter angehalten" und irgendeiner NullPointerException bei RouterService onStart-irgendwas ab (sieht man nur in logcat, andere Log-Dateien habe ich vergeblich gesucht). Beim Start kommt zunächst noch eine Liste, in der man ein Profil auswählen kann, dann eine Meldung, dass keine from/to-Knoten für Locus definiert wurde. Hier wähle ich "Server-Modus". Es erscheint eine kurze Meldung dass der Server-Modus gestartet wurde, dann folgt recht schnell der Absturz. Keine Ahnung, was da los ist, bei mir funktioniert es jedenfalls nicht.

abrensch wrote:

Ich würde ja gerne ein gepatches OsmAnd APK zur Verfügung stellen, aber das lässt die Lizenz wohl nicht zu.

Also ich habe gestern mal versucht, die Zeile zu ersetzen. Ich weiß nicht mal, wo ich nach was für einer Datei ich suchen muss.

Kann man nicht ein kleines Programm schreiben, was die Zeile ersetzt. Ähnlich wie Map Tweak für Locus https://play.google.com/store/apps/deta … B0d2VhayJd

GUFSZ wrote:

abrensch wrote:

Ich würde ja gerne ein gepatches OsmAnd APK zur Verfügung stellen, aber das lässt die Lizenz wohl nicht zu.

Also ich habe gestern mal versucht, die Zeile zu ersetzen. Ich weiß nicht mal, wo ich nach was für einer Datei ich suchen muss.

Kann man nicht ein kleines Programm schreiben, was die Zeile ersetzt. Ähnlich wie Map Tweak für Locus https://play.google.com/store/apps/deta … B0d2VhayJd

Es geht um diese Zeile in der Klasse RouteProvider. Das Kompilieren von Quellen ist hier recht detailliert beschrieben. Ich gehe mal davon aus, dass du dir das freiwillig nicht antun willst.

couchmapper wrote:

Es geht um diese Zeile in der Klasse RouteProvider. Das Kompilieren von Quellen ist hier recht detailliert beschrieben. Ich gehe mal davon aus, dass du dir das freiwillig nicht antun willst.

Nein nicht wirklich.

Ich habe eigentlich keine Ahnung von Android. Deswegen kann ich auch nicht beurteilen, was dieser MapTweak bei Locus wirklich macht. Die Frage ist, ob man das Kompilieren nicht mit einer Art Patch umgehen könnte. Denn bei jeder Verionsänderung von Osmand neu zu kompilieren, ist auch nicht sehr produktiv.

Eigentlich dachte ich mir, ich müsste eine Datei auf meinem Telephon mit einem Texteditor öffnen und umschreiben. Mir war/ist unklar, wo die Datei überhaupt zu finden wäre. Also ähnlich wie bei Windows die EXE-Dateien.

GUFSZ wrote:

Eigentlich dachte ich mir, ich müsste eine Datei auf meinem Telephon mit einem Texteditor öffnen und umschreiben. Mir war/ist unklar, wo die Datei überhaupt zu finden wäre. Also ähnlich wie bei Windows die EXE-Dateien.

In einer APK-Datei (die eine ZIP-Datei ist und nur anders heisst) sind die compilierten Java-Klassen alle in der Date "classes.dex" in übersetzer Form enthalten. Es gibt mächtige Tools, um APKs zu modifizieren, die "classes.dex" zu disassemblieren in so einer Art Assembler-Code ( "smali"-Dateien, die man lesen und verändern kan), das ganze wieder zu re-assemblieren und anschliessend neu zu signieren.

(Einfach mal googeln nach "apktool, smali, baksmali, APK Manager 5.0.2 und so)

So in der Art hatte ich das gemacht. Das ist zwar eine nette Spielerei, aber es lohnt sich nicht, irgendwas geht dann doch immer nicht.

Ich muss jetzt einfach mich doch mal durchbeissen, den OsmAnd Source-Build hinbekommen, ein vernünftiges Interface entwickeln und als GIT-Pull-Request ins OsmAnd Release bekommen. Victor sperrt sich ja nicht, obwohl das ja zu befürchten wäre, dass sie OsmAnd abschotten wollen gegen externe Router, aber ich glaube, das ist nicht der Fall, also mach ich's jetzt einfach richtig, dauert halt nur noch bisschen.

Schaust Du dir die NullPointerException in Post #97 noch an, brauchst Du noch mehr Details? Ich hatte 3-4h für einen funktionsfähigen OsmAnd Source-Build investiert, nur um dann festzustellen, dass BRouter bei mir nicht im Server-Modus läuft. Wirklich sehr ärgerlich, dabei wollte ich den Router doch gerne mal testen.

Hallo Arndt,

planst du auch eine nahtlose Integration in OruxMaps mit Hilfe der Intents ? OSMAND hat ja schon ein Routing drin, was aber bei OruxMaps noch (?) fehlt. Da wäre der BRouter eine wirkliche sinnvolle Ergänzung.

Viele Grüsse
Achim

couchmapper wrote:

Schaust Du dir die NullPointerException in Post #97 noch an, brauchst Du noch mehr Details? Ich hatte 3-4h für einen funktionsfähigen OsmAnd Source-Build investiert, nur um dann festzustellen, dass BRouter bei mir nicht im Server-Modus läuft. Wirklich sehr ärgerlich, dabei wollte ich den Router doch gerne mal testen.

Ich komme erst am Sonntag wieder dazu.

Hast Du denn einen Stacktrace? Und welche Android Version? Bei mir läuft es auf 2.3.6 stabil, während ich bei 4.0.1 eher mal eine vorzeitgen Dienst-Stop kriege, was aber nicht wirklich ein Fehler ist, weil Android darf das.

Ich hab' Dir einen Download-Link geschickt für die BRouter-Sourcen, vielleicht magst Du's ja selber mal im Debugger laufen lassen. Der Dienst, um den es geht, ist in der Klasse BRouterService.

Ich könnte den folgenden Stacktrace anbieten, den ich mit adb logcat eingesammelt habe. Vielleicht ist das einfach irgendein dummer Folgefehler, weil irgendwas in meiner Umgebung nicht stimmt oder vergessen wurde zu installieren und damit RouteServer nicht sauber instantiiert werden konnte? Leider habe ich ansonsten keine Meldung gefunden, die mich weitergebracht hätte. Getestet hatte ich BRouter mit Android 4.1.2.

/dalvikvm(30137):␣threadid=1:␣thread␣exiting␣with␣uncaught␣exception␣(group=0x40d412a0)
E/AndroidRuntime(30137):␣FATAL␣EXCEPTION:␣main
E/AndroidRuntime(30137):␣java.lang.RuntimeException:␣Unable␣to␣start␣service␣btools.routingapp.BRouterService@41a27468␣with␣null:␣java.lang.NullPointerException
E/AndroidRuntime(30137):␣	at␣android.app.ActivityThread.handleServiceArgs(ActivityThread.java:2548)
E/AndroidRuntime(30137):␣	at␣android.app.ActivityThread.access$1900(ActivityThread.java:140)
E/AndroidRuntime(30137):␣	at␣android.app.ActivityThread$H.handleMessage(ActivityThread.java:1324)
E/AndroidRuntime(30137):␣	at␣android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime(30137):␣	at␣android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime(30137):␣	at␣android.app.ActivityThread.main(ActivityThread.java:4898)
E/AndroidRuntime(30137):␣	at␣java.lang.reflect.Method.invokeNative(Native␣Method)
E/AndroidRuntime(30137):␣	at␣java.lang.reflect.Method.invoke(Method.java:511)
E/AndroidRuntime(30137):␣	at␣com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1006)
E/AndroidRuntime(30137):␣	at␣com.android.internal.os.ZygoteInit.main(ZygoteInit.java:773)
E/AndroidRuntime(30137):␣	at␣dalvik.system.NativeStart.main(Native␣Method)
E/AndroidRuntime(30137):␣Caused␣by:␣java.lang.NullPointerException
E/AndroidRuntime(30137):␣	at␣btools.routingapp.BRouterService.onStartCommand(BRouterService.java:42)
E/AndroidRuntime(30137):␣	at␣android.app.ActivityThread.handleServiceArgs(ActivityThread.java:2531)
E/AndroidRuntime(30137):␣	...␣10␣more

Mail geht übrigens am besten über OSM Nachricht senden, den Forum-Mailer habe ich nicht aktiv.

couchmapper wrote:

Ich könnte den folgenden Stacktrace anbieten, den ich mit adb logcat eingesammelt habe. Vielleicht ist das einfach irgendein dummer Folgefehler, weil irgendwas in meiner Umgebung nicht stimmt oder vergessen wurde zu installieren und damit RouteServer nicht sauber instantiiert werden konnte?

Danke, da wird Service.onStartCommand mit einem null-intent gerufen und die API sieht das wohl auch vor (wenn Android einen Dienst re-instanziert auf einem neuen Prozess, auch wenn ich nicht verstehe, warum Android das tun sollte)

Hab' jetzt bisschen dran geschraubt, (Version 0.9.2) so dass es zumindest anders ist (REDELIVER_INTENT, own process, null-check) und auf meinen beiden Geräten getestet, ich krieg nach wie vor paar störende Dienst-Stops auf dem Android-4 Gerät, aber wie gesagt, das liegt einfach am System, davon abgesehen läuft es bei mir stabil.

Vielleicht gibst Du dem nochmal einen Versuch.

Mit meinem eigentlichen Plan, ein neues, besseres, Interface zu implementieren, bin ich noch nicht weitergekommen.

Den Source-Link habe ich auch erneuert und an Deine bevorzugte Postbox geschickt.

Gruss, Arndt

Wir versuchten gerade mit BRouter offline Fahrrad-Routing für Android von den Koordinaten Freiburg Hbf From-Latitude 47.999160°N From-Longitude 7.843040°E nach München Hbf To-Latitude 48.140232°N To-Longitude 11.558335°E eine etwas längere Route zu erstellen. Obwohl bei uns die Dateien E5_N45.rd5, E5_N50.rd5, E10_N45.rd5, E10_N50.rd5 hinterlegt sind, erhalten wir die Meldung "An Error occured, multiple from-positions!(coodinate-source" angezeigt. Für kleinere Routing funktioniert BRouter ohne Probleme. Mit der online Version von BRouter erhalten wir die Meldung "Fehler: Datei http://h2096617.stratoserver.net/cgi-bi … trekking_0 kann nicht abgerufen werden. Status: ." angezeigt. Woran könnte es liegen, dass die Fehlermeldung bei uns erscheint? Ist die Route etwas zu lange?

Navi@Map09 wrote:

Wir versuchten gerade mit BRouter offline Fahrrad-Routing für Android von den Koordinaten Freiburg Hbf From-Latitude 47.999160°N From-Longitude 7.843040°E nach München Hbf To-Latitude 48.140232°N To-Longitude 11.558335°E eine etwas längere Route zu erstellen. Obwohl bei uns die Dateien E5_N45.rd5, E5_N50.rd5, E10_N45.rd5, E10_N50.rd5 hinterlegt sind, erhalten wir die Meldung "An Error occured, multiple from-positions!

"multiple from-positions" hat mit der Länge der Route nichts zu tun, es heisst, dass der "from" (und/oder "to") Wegpunkt mehrfach vorhanden ist. Einfach nochmal alle löschen und neu anlegen.

Mit der online Version von BRouter erhalten wir die Meldung "Fehler: Datei ... kann nicht abgerufen werden. Status: ." angezeigt. Woran könnte es liegen, dass die Fehlermeldung bei uns erscheint? Ist die Route etwas zu lange?

Bei "View Route" ist der Timeout ziemlich kurz und auch nicht von mir gemacht, sondern von dem Trackviewer.

Wenn Du "Download GPX" benutzt, ist der Timeout 30 Minuten, also solange da keiner dazwischenfunkt (jede neue Berechnung schiesst die laufende ab!) kann man da auch lange Routen mit ausrechnen.

Dein Beispiel hab ich eben mal gerechnet und das ging in wenigen Minuten (384 km, 1755 Höhenmeter).

Die GPX Datei musst Du dann lokal speiechern und in einem beliebigen Trackviewer ansehen (z.B. hier: http://www.gpswandern.de/gpxviewer/gpxviewer.shtml )

Ok, die offline App BRouter startet nun ohne Fehlermeldung. Wir hatten einfach vergessen die alten Werte unter OruxMaps zu löschen. Wenn wir jetzt allerdings mit dem Routing Profil car-test die Berechnung starten, stürzt die App nach ca. über Links: 510000 in 659s (772 l/s) immer ab. Woran könnte dies liegen?

Navi@Map09 wrote:

Wenn wir jetzt allerdings mit dem Routing Profil car-test die Berechnung starten, stürzt die App nach ca. über Links: 510000 in 659s (772 l/s) immer ab. Woran könnte dies liegen?

Es ist ein Speicherüberlauf. Das Problem ist allerdings speziell für das car-routing, weil meine Caching-Architektur mit dem Fall nicht klarkommt, dass in dem Profil nur über den kleineren Teil der Nodes geroutet werden kann, die anderen Nodes bleiben dann quasi in der Pipleline hängen und verschwinden nicht mehr aus dem Memory (Die selbe Strecke mit "trekking-steep" schafft mein Handy anstandslos in 20 Minuten.)

Ich denke mal drüber nach. Also die triviale Lösung ist natürlich, für's Car-Routing eigene Datefiles zu erzeugen, in denen die Feldwege garnicht drin sind (so machens die anderen ja auch) aber das widerspricht dem Konzept eines voll konfigurierbaren Routers. Vielleicht fällt mir aber auch was klügeres ein.

Für den Online-Dienst habe ich den Speicher jetzt mal auf 128 MB hochgesetzt, damit kannst Du Dir die Strecke ausrechnen. Mit den 24 MB, die Android einem Prozess zugesteht, geht car-test auf der Strecke leider (noch) nicht.

Hallo Arndt,

wird es für Deine Online-Version auch irgendwann via-Punkte geben?

Viele Grüße 😄

Mal etwas ganz anderes. Ist es grundsätzlich möglich festzustellen, ob ein Weg in freier Wildbahn oder in besiedelter Gegend verläuft.

Ich bin zu der Meinung gekommen, dass es Wegtypen gibt, deren Priorität man je nach Umgebung wählen sollte. Damit sind hauptsächlich path und footway gemeint.

Ich habe mich im Odenwald mehrmals verfahren und wie mich da dein Routing rausführen wollte, war nicht brauchbar, weil der Path mit Radschieben nicht passierbar war.

Ich kenne dein Kostenargument. Aber ich glaube es gibt Wegtypen, deren Kostenerzeugung in der Stadt wesentlich geringer ist als Überland.

Oder Du kennst vielleicht die Leute, durch die Stadt will ich möglichst schnell, deswegen will ich Hauptstraßen. Fahre ich aber Überland, will ich eher ruhige Wege.

GUFSZ wrote:

Mal etwas ganz anderes. Ist es grundsätzlich möglich festzustellen, ob ein Weg in freier Wildbahn oder in besiedelter Gegend verläuft.

Ja, aber wirklich nur "grundätzlich", also die Renderer können ja auch die Polygone auswerten und die Wege dann über Wald, Feld oder Siedlungen zeichnen. Aber ich kann das nicht, zumindest nicht mit diesem Präprozessor, der das Planet-File verdauen kann mit seinen 2 Milliarden Nodes, da gibts einfach algorithmische Einschränkungen, die man nicht hat, wenn man ein begrenztes Gebiet komplett ins Memory laden kann und dann beliebige Korrelationen auswerten kann.

Ich bin zu der Meinung gekommen, dass es Wegtypen gibt, deren Priorität man je nach Umgebung wählen sollte. Damit sind hauptsächlich path und footway gemeint.

Ich habe mich im Odenwald mehrmals verfahren und wie mich da dein Routing rausführen wollte, war nicht brauchbar, weil der Path mit Radschieben nicht passierbar war.

Ich kenne dein Kostenargument. Aber ich glaube es gibt Wegtypen, deren Kostenerzeugung in der Stadt wesentlich geringer ist als Überland.

Ich kenne die Probleme im Odenwald auch. Das Trekking-Profil habe ich anhand von Strecken im Rhein-Main-Neckar Gebiet und im Westerwald justiert. Im Odenwald hat man das Problem, dass es zu den Landstrassen oft keine sinnvolle Alternative gibt, und wenn das Profil dann path/grade3 besser bewertet als highway=secondary, dann ist das Ergebnis entsprechend und man landet im Gestrüpp. Deswegen fahre ich dann eher mit "fastbike" durch den Odenwald.

Aber die Lösung ist vielleicht einfach ein Mittelweg aus "trekking" und "fastbike". Also fastbike + die Fernradwege-Präferenz aus "trekking" + grade2/grade3 bisschen aufgewertet, dann könnte das passen.

vipanny wrote:

wird es für Deine Online-Version auch irgendwann via-Punkte geben?

Hi,

ich hab' da nicht die Zeit und die Kraft dazu und die Online Version ist auch nicht mein Focus. Da gibt's ja noch mehr Sachen, die zum Himmel schreien wie dieser Location Picker mit Google-Maps und der Viagra-Werbung. Ist halt einfach nur so hingestrickt.

Aber wenn jemand Lust und Zeit hat, eine anständige Seite zu bauen, meine Unterstützung hat er und bekommt auch den Source-Code.

abrensch wrote:

Hi,

ich hab' da nicht die Zeit und die Kraft dazu und die Online Version ist auch nicht mein Focus. Da gibt's ja noch mehr Sachen, die zum Himmel schreien wie dieser Location Picker mit Google-Maps und der Viagra-Werbung. Ist halt einfach nur so hingestrickt.

Aber wenn jemand Lust und Zeit hat, eine anständige Seite zu bauen, meine Unterstützung hat er und bekommt auch den Source-Code.

Vielleicht finden sich ein paar Leute zusammen? Ich könnte mir gut vorstellen daran mitzuarbeiten, habe aber sicher nicht für alles die nötigen Fähigkeiten. Und Arnd kann inzwischen weiter in Ruhe den Offline-Android-Router optimieren... (da warte ich nämlich auch drauf).

abrensch wrote:

couchmapper wrote:

Ich könnte den folgenden Stacktrace anbieten, den ich mit adb logcat eingesammelt habe. Vielleicht ist das einfach irgendein dummer Folgefehler, weil irgendwas in meiner Umgebung nicht stimmt oder vergessen wurde zu installieren und damit RouteServer nicht sauber instantiiert werden konnte?

Danke, da wird Service.onStartCommand mit einem null-intent gerufen und die API sieht das wohl auch vor (wenn Android einen Dienst re-instanziert auf einem neuen Prozess, auch wenn ich nicht verstehe, warum Android das tun sollte)

Hab' jetzt bisschen dran geschraubt, (Version 0.9.2) so dass es zumindest anders ist (REDELIVER_INTENT, own process, null-check) und auf meinen beiden Geräten getestet, ich krieg nach wie vor paar störende Dienst-Stops auf dem Android-4 Gerät, aber wie gesagt, das liegt einfach am System, davon abgesehen läuft es bei mir stabil.

Vielleicht gibst Du dem nochmal einen Versuch.

Besten Dank für die neue Version 0.9.2! In der Zwischenzeit konnte ich nochmal einen OsmAnd Source Build mit BRouter-Anbindung bauen und bin begeistert: der Fehler der Version 0.9.1 tritt nicht mehr auf. Aktuell teste ich verschiedene Szenarien durch, um hoffentlich ein qualifizierteres Feedback geben zu können.

Mit meinem eigentlichen Plan, ein neues, besseres, Interface zu implementieren, bin ich noch nicht weitergekommen.

Die aktuelle Anbindung läuft wie schon zuvor beschrieben. Allerdings scheint die Auswahlmöglichkeit zwischen Auto, Fahrrad und Fußgänger kein Unterschied zu machen, maßgeblich ist wohl nur, was beim Start des BRouter ausgewählt wird. Vielleicht würde sich da eine Konfigurationsoption anbieten, die verschiedene "externe" Profile auf BRouter-interne Profile matched. Das hängt aber alles sehr davon ab, in welche Richtung sich das Interface zu OsmAnd zukünftig entwickeln wird.

Den Source-Link habe ich auch erneuert und an Deine bevorzugte Postbox geschickt.

Auch dafür besten Dank, der Link ist angekommen. Für meine Tests habe ich erstmal mit der fertig kompilierten .apk Version gearbeitet, bevor ich mich in die Quellen einarbeite.

g0ldfish wrote:

abrensch wrote:

ich hab' da nicht die Zeit und die Kraft dazu und die Online Version ist auch nicht mein Focus. Da gibt's ja noch mehr Sachen, die zum Himmel schreien wie dieser Location Picker mit Google-Maps und der Viagra-Werbung. Ist halt einfach nur so hingestrickt.

Aber wenn jemand Lust und Zeit hat, eine anständige Seite zu bauen, meine Unterstützung hat er und bekommt auch den Source-Code.

Vielleicht finden sich ein paar Leute zusammen? Ich könnte mir gut vorstellen daran mitzuarbeiten, habe aber sicher nicht für alles die nötigen Fähigkeiten. Und Arnd kann inzwischen weiter in Ruhe den Offline-Android-Router optimieren... (da warte ich nämlich auch drauf).

An einem komfortablen webbasierten Client wäre ich schon sehr interessiert, da ich lieber am großen Bildschirm plane und momentan auch noch nen Garmin nutze.

Ich hätte auch Lust, das zu entwickeln, hab aber eigentlich schon zu viele Sachen angefangen und bin momentan noch an was anderem dran. Von daher fände ich es toll, wenn wir das zusammen als Community-Projekt angehen könnten.

Wenn der Server der Online-Demo nicht für intensivere Nutzung geeignet ist, könnte man sich auch nach Alternativen umsehen. Persönlich hätte ich auch kein Problem damit, den BRouter erst mal als Java-Applikation herunterzuladen und analog zur Android-apk über eine HTTP-Schnittstelle lokal im Browser anzusprechen. Vorausgesetzt, dass eine solche Variante ohne allzu großen Aufwand machbar ist, das könnte ja auch jemand übernehmen.

Erst hatte ich die Idee, einen vorhandenen Routing-Client anzupassen, aber so einfach sah mir das beim Project-OSRM-Web gar nicht aus, zudem ist mir dort die GPL Lizenz zu restriktiv. Das Routing bei XC Trails sieht noch ganz nett aus, scheint aber nicht Open Source zu sein. Weitere hab ich noch nicht angeschaut.

Ich konnte es trotzdem nicht lassen und hab das mal mit Leaflet und den draw und GPX Plugins angetestet und vorübergehend als Beispiel hochgeladen.

Folgende Features würde ich mir wünschen:

• Route als editierbare Linie mit Zwischenpunkten zeichnen
  

in etwa wie bei GORP 2 (Autorouting in Extras aktivieren)

• interaktives Höhenprofil
  

Beispiele: Leaflet.Elevation Plugin, GPSies, osm.santolibre.net, MyGPSFiles (Track öffnen)

• Editor für Routing-Profil
  

wie bei overpass turbo (CodeMirror)

• ...
  

Wer hätte sonst noch Lust mitzumachen? Möchte das jemand in die Hand nehmen?

Gruß,
Norbert

Edit: Leaflet.Elevation, Plugin Links

Hallo

grundsätzlich hätte ich da auch Interesse was beizutragen, aber dazu fehlt mir auch das nötige Hintergrundwissen. Ich habe etwas Erfahrung in der
.NET Programmentwicklung .Ich habe da mal vor langer Zeit einen primitiven Kartenviewer geschrieben. Dieser verarbeitet aber auschließlich Tile-Karten und KEINE Vektorkarten ==> C /C# Lösung sehr aufwendig

Ich würde jedoch eine rein lokale Lösung anstreben die ohne Webserver (HTTP) läuft. Eventuell könnte man sowas in GPSPrune (HMI /Java) integrieren/verheiraten. Es kommt auf die Schnittstelle zum Brouter an. ==> reine Javalösung?

Eine Interessante alternative wäre die Integration/ Verheiratung mit Oruxmaps. Hatte ich mal weiter oben angefragt, aber leider keine Antwort bekommen. Das könnte man dann in der Virtuellen Box mit Andorid unter Windows betreiben. Der Weg ist hier beschrieben http://www.openandromaps.org/ Der Vorteil wäre die Kompatibilität zu Android. Habe ich aber noch nicht probiert. ==> Andoidlösung mit Standard Programmen

Frage:
In welcher Spache und Entwicklungsumgebung ist der Brouter geschrieben?
Wie sieht eine Schnittstelle zum BRouter aus?

Viele Grüsse
Achim

Ich finde das so schon eine riesige Verbesserung zum aktuellen Frontend des Online-Routers (und viele der auch aus meiner Sicht wünschenswerten Zusatzfeatures eher Nice to Have, weil es sie ja aktuell auch nicht gibt). Wieso meint ihr (insbesondere womisa), das müsste offline funktionieren? Es ging doch gerade um ein Web-Frontend für den Online-Router?

Ich weiß jetzt allerdings noch weniger, ob ich wirklich Sinnvolles beitragen kann. Ich hätte mir das Leaflet-Beispiel ganz sicher nicht aus dem Ärmel geschüttelt. Aber irgendwas gibt's ja meistens auch für Doofe zu tun.

ikonor wrote:

Ich konnte es trotzdem nicht lassen und hab das mal mit Leaflet und den draw und GPX Plugins angetestet und vorübergehend als Beispiel hochgeladen.

Ja cool. Finde, das ist so schon ein nettes Spielzeug. Da noch Profilauswahl, Höhendiagramm und GPX-Download und das ist brauchbar.

ikonor wrote:

Folgende Features würde ich mir wünschen:

• ...
  

Die Sperrgebiete sind ein unique-feature, was die anderen nicht können (sie können es prinzipiell nicht, weil sie shurtcuts vorberechnet haben und deswegen keine individuellen Routing-Kriterien berücksichtigen können. Wäre also auch noch schön, Sperr-Kreise (Position und Radius) setzen zu können und die als Kreis zu visualisieren.

ikonor wrote:

Wenn der Server der Online-Demo nicht für intensivere Nutzung geeignet ist, könnte man sich auch nach Alternativen umsehen.

Es ist ein Strato V-Server level 2 mit Ubuntu 10 32 bit und der läuft schon nicht schlecht (zwar nur 2 GB garantiert aber faktisch doch immer 4). Von den 100 GB Plattenplatz brauche ich aber einen Grossteil für den Präprozessor, so dass da faktisch nur ca 10-20 GB übrig sind, und der läuft einmal im Monat und braucht dann 3 GB Hauptspeicher. Also ein Serverprozess sollte sich mit 1/2 GB Hauptspeicher begnügen, sonst kann der Präprozessor nicht mehr parallel laufen.

ikonor wrote:

Persönlich hätte ich auch kein Problem damit, den BRouter erst mal als Java-Applikation herunterzuladen und analog zur Android-apk über eine HTTP-Schnittstelle lokal im Browser anzusprechen. Vorausgesetzt, dass eine solche Variante ohne allzu großen Aufwand machbar ist, das könnte ja auch jemand übernehmen.

Ich hab' mal das "Server-Jar" und zusaetzlich den Source-Code der beiden "Aufruf-Klassen" BRouter.java und RouteServer.java als Paket hochgeladen: http://h2096617.stratoserver.net/broute … bundle.zip

Das ist sowohl die Kommandozeilen-Version, als auch das CGI der Online-Demo als auch mein Standalone-Server für die "yournavigation-Simulation". Sie, und auch die Android-App, benutzen alle die gleiche API zum eigentlichen Router, die letzlich aus den Klassen CycleRoute, RoutingConfig, OsmNodeNamed und OsmTrack besteht. Ist bisschen mässig dokumentiert, aber ich kann die API an der Stelle sauber machen. Dann ist BRouter letzlich eine Java-Bibliothek. Die vollen Sourcen schicke ich Dir gesondert zu.

g0ldfish wrote:

.....
.... Wieso meint ihr (insbesondere womisa), das müsste offline funktionieren? Es ging doch gerade um ein Web-Frontend für den Online-Router?

....ganz einfach. Unabhängig von einer Netwerkverbindung zu sein, wenn man die Karten schon mal lokal geladen hat.
....und um hauptsächlich die Serverbelastung auf ein Minimum zu reduzieren
... nicht geroutete Wegpunktdateien halte ich sowieso lokal und kann diese dann mit verschiedenen Parametern durch den BRouter jagen

Ich habe mal mit dem Webinterface gespielt und das funzt gut. Ist es erlaubt mit dem Server einige Tests durchzuführen?
Ich stelle mir das so vor, ich erstelle mir eine Route mit signifikanten (erwünschten) Wegpunkten und iteriere jeweils mit 2 Wegpunkten durch den BRouter und erstelle so sukzesive meinen gerouteten Track/Route. Das teste ich mal mit einem C#Client in Verbindung mit dem BRrouter Webserver.

Oder geht das einfacher (Viapunkte)?

Was muß ich ALLES haben um unter Windows einen BRouter-Server laufen zu lassen, oder gibts da schon eine EXE oder einen ausführbaren JAR File?

Vielen Dank
Achim

abrensch wrote:

Wäre also auch noch schön, Sperr-Kreise (Position und Radius) setzen zu können und die als Kreis zu visualisieren.

Ist notiert. Kreise sollten kein Problem sein, siehe Leaflet.draw demo, hab ich nur wegkonfiguriert.

abrensch wrote:

Ich hab' mal das "Server-Jar" und zusaetzlich den Source-Code der beiden "Aufruf-Klassen" BRouter.java und RouteServer.java als Paket hochgeladen: http://h2096617.stratoserver.net/broute … bundle.zip

Dankeschön!

abrensch wrote:

Das ist sowohl die Kommandozeilen-Version, als auch das CGI der Online-Demo als auch mein Standalone-Server für die "yournavigation-Simulation". Sie, und auch die Android-App, benutzen alle die gleiche API zum eigentlichen Router, die letzlich aus den Klassen CycleRoute, RoutingConfig, OsmNodeNamed und OsmTrack besteht. Ist bisschen mässig dokumentiert, aber ich kann die API an der Stelle sauber machen. Dann ist BRouter letzlich eine Java-Bibliothek.

Ich denke mit der API kommt man schon erst mal klar so. Bei Unklarheiten können wir ja auch fragen.

g0ldfish wrote:

Wieso meint ihr (insbesondere womisa), das müsste offline funktionieren? Es ging doch gerade um ein Web-Frontend für den Online-Router?

So wie ich Arndt verstehe ist der Online-Server - zumindest im Moment - nur als Demo gedacht und nicht für den produktiven Betrieb. Wenn ich das richtig sehe, hat der Server folgende Einschränkungen, weil Online halt keine Priorität hat:
- es kann nur eine Anfrage gleichzeitig verarbeitet werden, bei einer zweiten wird die aktuelle abgeschossen
- bei jeder Anfrage wird die Java Runtime neu gestartet, das ist schon ein ziemlicher Overhead

Mir geht es daher nicht um Offline, sondern darum die Routing-Engine lokal zu haben, damit ich vor allem während der Entwicklung niemandem in die Quere komme (und umgekehrt) und die Engine ohne schlechtes Gewissen quälen kann 😉

Um einen richtigen Routing-Server aufzusetzen müsste man noch etwas Arbeit investieren und z.B. einen Java Server (Tomcat) installieren, in dem ein Servlet die Engine ansteuert.

g0ldfish wrote:

Ich weiß jetzt allerdings noch weniger, ob ich wirklich Sinnvolles beitragen kann. Ich hätte mir das Leaflet-Beispiel ganz sicher nicht aus dem Ärmel geschüttelt. Aber irgendwas gibt's ja meistens auch für Doofe zu tun.

Da gibt es sicher genug Möglichkeiten. Da ich aktuell eigentlich noch an etwas anderem arbeite, wäre eine Idee, die noch fehlenden Sachen aus dem jetzigen Client in das Leaflet Beispiel einzubauen, um erst mal die aktuelle Funktionalität nachzubauen.

Ich bin aber nicht unbedingt auf Leaflet festgelegt, nur möchte ich mit OpenLayers 2 nichts neues mehr anfangen und für OL3 ist es vermutlich noch zu früh 🤔

womisa wrote:

Ich würde jedoch eine rein lokale Lösung anstreben die ohne Webserver (HTTP) läuft.

Das RouteServer.java macht sein eigenes Socket auf und ich möchte das auch so verwenden, dass man damit den BRouter mit integriertem Server startet, also keinen extra Webserver benötigt. Allerdings möchte ich definitiv einen Web-Client im Browser haben, also wird eine lokale Anwendung schon aus zwei Teilen bestehen und für die Kartenanzeige wird man im Normalfall schon eine Online-Verbindung benötigen. Da kommen wir dann vermutlich nicht zusammen.

womisa wrote:

Eventuell könnte man sowas in GPSPrune (HMI /Java) integrieren/verheiraten. Es kommt auf die Schnittstelle zum Brouter an. ==> reine Javalösung?

Ja, das ist rein Java und das jar könnte als Bibliothek direkt in einem anderen Java-Programm integriert werden.

womisa wrote:

Eine Interessante alternative wäre die Integration/ Verheiratung mit Oruxmaps. Hatte ich mal weiter oben angefragt, aber leider keine Antwort bekommen. Das könnte man dann in der Virtuellen Box mit Andorid unter Windows betreiben. Der Weg ist hier beschrieben http://www.openandromaps.org/ Der Vorteil wäre die Kompatibilität zu Android. Habe ich aber noch nicht probiert. ==> Andoidlösung mit Standard Programmen

Das mit der VM wäre mir persönlich jetzt zu umständlich.

womisa wrote:

Ich stelle mir das so vor, ich erstelle mir eine Route mit signifikanten (erwünschten) Wegpunkten und iteriere jeweils mit 2 Wegpunkten durch den BRouter und erstelle so sukzesive meinen gerouteten Track/Route. Das teste ich mal mit einem C#Client in Verbindung mit dem BRrouter Webserver.

Oder geht das einfacher (Viapunkte)?

Da bin ich auch unschlüssig, da ich nicht weiß, wie viel Mehraufwand das für den Router ist. Für den Client wäre es einfacher mit Via-Punkten zu arbeiten, entweder mit einmaliger Berechnung am Schluß, oder mit kompletter Neuberechnung bei jedem Anlegen eines Punktes, was ich schon schön fände. Ich denke, es macht auf jeden Fall Sinn, wenn wir Via-Punkte in die API einbauen.

womisa wrote:

Was muß ich ALLES haben um unter Windows einen BRouter-Server laufen zu lassen, oder gibts da schon eine EXE oder einen ausführbaren JAR File?

Was bequemes gibt es noch nicht. Habs noch gar nicht getestet, aber der Kommandozeilen-Aufruf (siehe Command-Line-Mode in readme.txt) müsste so schon gehen (wenn Java Runtime installiert ist). Der CGI-Mode braucht nen Webserver. Den Stand-Alone-Server müsste man von Kommandozeile auch schon starten können, allerdings mit yournavigation-Schnittstelle, die man eher nicht verwenden will.

Falls sich sonst niemand meldet, wäre das vielleicht ein Punkt, den ich als erstes angehen würde: Eine vollständige BRouter HTTP API mit Via-Punkten und Sperrzonen in das RouteServer.java (oder extra) einbauen und ein kleines Script zum Starten.

ikonor wrote:

Wenn ich das richtig sehe, hat der Server folgende Einschränkungen:
- es kann nur eine Anfrage gleichzeitig verarbeitet werden, bei einer zweiten wird die aktuelle abgeschossen

Das ist ein schwieriges Thema, weil es bei diesem Router ja kein oberes Limit für die Bearbeitungszeit gibt. Und es passiert mit dem neuen, besseren Location-Matching zwar nicht mehr häufig, aber immer noch, dass wegen einer "Zielinsel" keine Route gefunden wird, es aber auch kein Abbruch-Kriterium gibt, und das muss man irgendwann beenden. Ich hatte es zuerst mit Warteschlange und Timeout gemacht, aber das ist unglücklich, weil man mit so einem Timeout ein künstliches Limit schafft für die geroutete Distanz, daher das jetzige Verfahren mit dem Process-Kill. Ich denke, man kann das noch bisschen klüger machen mit z.B. einem Pool von 5 parallelen Berechnungen (und erst die 6. schiesst die älteste ab) und einer Rechenzeit-Priorität für die Kurzläufer.

ikonor wrote:

womisa wrote:

Ich stelle mir das so vor, ich erstelle mir eine Route mit signifikanten (erwünschten) Wegpunkten und iteriere jeweils mit 2 Wegpunkten durch den BRouter und erstelle so sukzesive meinen gerouteten Track/Route. Das teste ich mal mit einem C#Client in Verbindung mit dem BRrouter Webserver.

Oder geht das einfacher (Viapunkte)?

Da bin ich auch unschlüssig, da ich nicht weiß, wie viel Mehraufwand das für den Router ist. Für den Client wäre es einfacher mit Via-Punkten zu arbeiten, entweder mit einmaliger Berechnung am Schluß, oder mit kompletter Neuberechnung bei jedem Anlegen eines Punktes, was ich schon schön fände. Ich denke, es macht auf jeden Fall Sinn, wenn wir Via-Punkte in die API einbauen.

Bei Via-Punkten macht auch BRouter das Routing für jedes Teilstück einzeln, es gibt da ein bisschen Re-Use beim Location-Matching und kleineren Caches, aber das sollte glaubich die Design-Entscheidung nicht beinflussen, ob über vias im Web-Client oder im BRouter iteriert wird.

ikonor wrote:

Falls sich sonst niemand meldet, wäre das vielleicht ein Punkt, den ich als erstes angehen würde: Eine vollständige BRouter HTTP API mit Via-Punkten und Sperrzonen in das RouteServer.java (oder extra) einbauen und ein kleines Script zum Starten.

Ich hab' Dir die vollständigen Sourcen jetzt geschickt (an Deine gmx-adresse), ohne ists ein bisschen schwierig, weil die API doch arg verbastelt ist. Zu Sperrgebieten ist in RouteServer.java die Anbindung im Prinzip drin ("nogoList"), aber nicht der Konstruktor dieser Objekte:

List<OsmNodeNamed> nogoList= new ArrayList<OsmNodeNamed>();
OsmNodeNamed n = new OsmNodeNamed();
n.name = "nogo2000";
n.isNogo = true;
n.ilon = (int)( ( lon + 180. )*1000000. + 0.5);
n.ilat = (int)( ( lat + 90. )*1000000. + 0.5);
nogoList.add( n );

Der Radius steckt also im Namen, und das Koordinatensystem ist das BRouter-Interne. Die Erweiterung um via-Punkte in dem RouteServer.java Beispiel ist trivial, da wird einfach nur die Wegpunktliste länger, also statt from-to dann from-via1-via2-to. Die Beschränkung auf 9 Vias gibts nur in der Android-App (wegen der Namenskonvention), an dieser Stelle in der API ist die Zahl nicht beschränkt und auch die Namen der Wegpunkte sind beliebig.

Hallo

ich habe mal im Routeconverterforum nachgefragt ob eine Integration von BRouter von Interesse wäre. Routconverter hat alles für eine komfortable Routenerstellung /Editiermodus etc. standardmäßig schon drin. RC könnte doch auf dem PC die Rolle von Osmand, Oruxmaps sinngemäß übernehmen. Routeconverter ist auch in Java geschrieben.

Würde das die Zustimung und eventuelle Unterstützung vom BRouterAutor bekommen?

MfG
Achim

womisa wrote:

Hallo

ich habe mal im Routeconverterforum nachgefragt ob eine Integration von BRouter von Interesse wäre. Routconverter hat alles für eine komfortable Routenerstellung /Editiermodus etc. standardmäßig schon drin. RC könnte doch auf dem PC die Rolle von Osmand, Oruxmaps sinngemäß übernehmen. Routeconverter ist auch in Java geschrieben.

Hi Achim,

wenn ich es richtig verstehe, kann Routeconverter (noch?) keine Offline-Karten. Richtig Sinn machen würde das ja dann, wenn man so eine echte offline-Lösung für den Desktop schaffen würde, und da hätte ich auch grosses Interesse dran. Wenn man aber ohnehin den online-Zugang braucht für den Tileserver, dann wird man es den Benutzern nicht vermitteln können, sich mit dem Download der Routing-Datafiles rumzuschlagen.

Alternativ könnte man da aber auch den Router als Online-Dienst einbinden (sie haben wohl schon andere Dienste drin?), das wäre ja mit wenig Aufwand zu machen, und da wären wir ja wieder bei Norberts Vorschlag, zunächst mal eine dokumentierte http-schnittstelle zu schaffen mit der vollen Funktionalität in der API.

womisa wrote:

Würde das die Zustimung und eventuelle Unterstützung vom BRouterAutor bekommen?

Ja, ich würde beides (die offline und die online-Integration) unterstützen, mit Arbeit zurzeit nur begrenzt (muss bisschen kürzer treten bei dem Thema), mit der Lizenz kann man das vielleicht irgendeine Lösung finden, den Router dort zu integrieren ohne BRouter gleich selbst unter GPL-Lizenz stellen zu müssen.

Gruss, Arndt

Hallo Arndt,

vielen Dank für die freundliche Antwort.
Eine andere Idee für eine "offline" Version wäre eventuell noch MOBAC als Oberfläche zu benutzen. Ich habe vor langer Zeit mal angeregt, dass man externe Programme mit Parameter aufrufen kann. Damit hat man zum Beispiel Maperitive mit einer Batchdatei steuern können. Dieses Feature hatte ich zusammen mit dem Autor ausgetestet. Sinngemäß könnte man das mal mit BRouter versuchen.

Mir ist aber noch nicht klar wie bekomme ich unter Windows eine Standolone-Version vom BRouter (Kein Server) zum Laufen und wie ist die Parameterübergabe?
Idee wäre man übergibt eine gpx Datei mit mindestends zwei Punkten und bekommnt eine geroutete GPX Datei mit dem Track zurück bzw. mehrere GPX Dateien mit den alternativen Routen. MOBAC,Maperitive und BRouter könnte auch in Betracht gezogen werden, wobei Maperitive ja mit Scripten programmierbar ist.

Viele Grüsse
Achim

Mal ganz was anderes, ich habe gestern auf dem Rad mal über deine Frickeleien nachgedacht, wie Du die Verbindung zu verschiedenen Apps herstellst. Wäre es auf Dauer nicht einfacher, wenn Du deinem Brouter einen eigenen Kartenviewer und Sprachausgabe spendieren würdest. Letztendlich eine eigenständige Navigationsapp. Die Hauptaufgabe sinnvolle Navigation hast Du ja schon gelöst. Der Rest wäre doch eher leicht zu programmierendes Beiwerk?

Aus purem Zufall bin ich letzten Freitag bei Android-Hilfe über einen Beitrag zu Brouter gestolpert und habe es sofort online ausprobiert: Sehr beeindruckendes Resultat für das von mir gewählte Profil (fastbike o.ä., Rennradfahrer).
Als allerersten möchte ich mich aufs herzlichste dafür bedanken!
Heute habe ich mir dann den ganzen offline-Kram heruntergeladen, in einer virtuellen Box installiert und ein wenig damit herum gespielt, als Offroad Proggies fungierten Locus und Oruxmaps.
Ein paar Punkte, die mir dabei aufgefallen sind, möchte ich nachfolgend aufführen.

1. Ich habe hauptsächlich das Rennrad? Profil gewählt, es hat für mich! erstklassige Vorschläge gelistet, teilw. wirklich excellent.
Gut asphaltierte Nebenstraßen mit ordentlichen Steigungen (> 10%) waren genauso mit von der Partie wie die stark befahrene Bundesstraßen. Leider sind letztere nicht immer die erste Wahl bei meinen Gesinnungsgenossen aus diversen Radsportvereinen, die meisten versuchen diese zu meiden, insbesondere dann, wenn es weniger verkehrbelastete Alternativen gibt. In diesem Zusammenhang ist mir aufgefallen, dass manchmal auch dann eine mehrfach ampelverstellte Hauptverkehrsstraße gewählt wird obwohl eine lupenreine und sogar kürzere Radwegalternative vorhanden ist.
Im Extremfall meidet Brouter sogar "Radwege" wie der Teufel das Weihwasser.
Beispiel ist eine Route von Dormagen/Zons über den Rhein Richtung Wuppertal. Nur mit Start- und Zielkoordinaten versorg wird ohne Zögern die Fähre bei Zons genommen. Für Jugendliche duraus romantisch nehmen die meisten RRler doch wohl eher eine Rheinbrücke. Nachdem die Fähre gesperrt wird findet der Router nur zwei große Umwege, entweder über die A1 bei Köln/Leverkusen oder die Düsseldorfer Südbrücke, beides befahrbare Radwege. die naheliegende Strecke über die Fleher Brücke (A46) mit ihren erstklassigen Radwegen bleibt außen vor. Werden Wegpunkte direkt auf die Brücke gesetzt passiert folgendes: die der linksrheinischen Brückenauffahrt am nächsten liegenden werden zunächst angefahren, dann heißt es wenden und im großen Bogen an der Neusser Galopprennbahn vorbei über die Südbrücke hin zur Fleher, dann die rechstrheinische Auffahrt hoch und die dieser Auffahrt näher gelegenen Punkte einsammeln, wenden, die Auffahrt wieder runter und den Weg fortsetzten.
Im Modus "tracking" wird die Brücke benutzt, dann aber die holprigere Nordseite, wahrscheinlich wegen der flacheren Auffahrt, die von RRlern bevorzugte "knackigere" und babypoasphaltierte Südseite kommt erst beim Profil "shortest" zum Zug.

2. Das Profil "shortest" routet ohne Rücksicht auf Verluste, d.h. auch über wenig genutzte weil verwinkelte Brücken, d.h. enge und steile Treppen bzw. Drahtkäfige, wo man sein Rad aus Platzmangel kaum hochtragen kann bzw. senkrecht vor sich her bugsieren muss.

Beim gestrigen Querlesen habe ich irgendwo etwas von einem "Kostenfaktor" gelesen, eine Eingabemöglichkeit dafür habe ich nicht gefunden.
Weiterhin habe ich ebenfalls gelesen, dass Brouter wohl urspünglich für die Cooperation mit OSMAND ausgelegt wurde. Ich konnte aber heute feststellen, dass es, wenn auch "etwas umständlich", "Routinganforderungen" sowohl von Locus als auch von Oruxmaps erkennt und die Ergebnisse in deren Verzeichnisstruktur bereitstellt. Da nun diese beiden Programme Vektormaps Marke "mapsforge" sollte es doch spätestens mit der nächsten Version 0.4. möglich sein, diese fürs Routen zu nutzen.

GUFSZ wrote:

Letztendlich eine eigenständige Navigationsapp. Die Hauptaufgabe sinnvolle Navigation hast Du ja schon gelöst. Der Rest wäre doch eher leicht zu programmierendes Beiwerk?

...ist diese Aussage Ernst gemeint?

Hast du mal die entsprechenden Kartenprogramme zeitlich verfolgt wie lange das gebraucht hat bis diese in ihrer jetzigen Form stabil waren (OruxMaps, OsmAnd,Mapsforge, Locus etc.). Es ist ja nicht "nur" die Kartenanzeige sondern auch die Track/Routen Verwaltung/Anzeige und das navigieren auf einer vorgegebenen Route. Das ist glaube ich schon ein wenig Zeitaufwändig, oder?
Es geht doch auch um eine Lösung die auf dem PC (großer Bilschirm läuft). Da gilt für die entsprechenden Kartenprogramme das Gleiche (GpsPrune, Routeconverter, etc.)

In diesem Sinne
Achim

GUFSZ wrote:

Mal ganz was anderes, ich habe gestern auf dem Rad mal über deine Frickeleien nachgedacht, wie Du die Verbindung zu verschiedenen Apps herstellst. Wäre es auf Dauer nicht einfacher, wenn Du deinem Brouter einen eigenen Kartenviewer und Sprachausgabe spendieren würdest. Letztendlich eine eigenständige Navigationsapp.

Naja, bisschen mehr Respekt vor der Leistung dieser Kartenprogramme hab ich schon, und mein Router ist ein 1-Mann Hobbyprojekt...

Ich verfolge ja eine andere Strategie um die "Frickeleien" zu überwinden, über eine standartisierte Router/Maptool Schnittstelle. So ein bisschen funktioniert das ja schon mit OsmAnd mit dem Hack mit dem Android-Lokalen HTTP-Server, der einen Yournavigation-Server simuliert, und wenn's irgenwann mal wieder schlechteres Wetter gibt, komm ich da hoffentlich auch weiter.

bianchifan wrote:

1. Ich habe hauptsächlich das Rennrad? Profil gewählt, es hat für mich! erstklassige Vorschläge gelistet, teilw. wirklich excellent.
Gut asphaltierte Nebenstraßen mit ordentlichen Steigungen (> 10%) waren genauso mit von der Partie wie die stark befahrene Bundesstraßen.

In "meiner" Höhenpräferenz werden zwar flache Abfahrten bevorzugt, bei den Anstiegen gibt es keine Präferenz, so dass da gerne auch mal steile Anstiege gewählt werden. Viele Leute mögen das nicht und kann man aber ändern.

bianchifan wrote:

Leider sind letztere nicht immer die erste Wahl bei meinen Gesinnungsgenossen aus diversen Radsportvereinen, die meisten versuchen diese zu meiden, insbesondere dann, wenn es weniger verkehrbelastete Alternativen gibt. In diesem Zusammenhang ist mir aufgefallen, dass manchmal auch dann eine mehrfach ampelverstellte Hauptverkehrsstraße gewählt wird obwohl eine lupenreine und sogar kürzere Radwegalternative vorhanden ist.

Ja das fastbike-Profil ist bisschen ein "stiefkind", weil es nicht so viel benutzt wird und da steckt auch nicht so viel Tuning drin. Ich selbst mache aber zur Zeit viele "schnelle Ebike Touren", was bisschen vergleichbar ist zum Rennrad, und bastel an einem Profil ähnlich fastbike, was aber auch Radwege un Ampeln kennt.

bianchifan wrote:

Im Extremfall meidet Brouter sogar "Radwege" wie der Teufel das Weihwasser.
Beispiel ist eine Route von Dormagen/Zons über den Rhein Richtung Wuppertal. Nur mit Start- und Zielkoordinaten versorg wird ohne Zögern die Fähre bei Zons genommen ... die naheliegende Strecke über die Fleher Brücke (A46) mit ihren erstklassigen Radwegen bleibt außen vor.

Das ist ganz klar ein Fehler, und Du kannst Dir aussuchen, ob der Fehler im OSM-Tagging steckt oder im fastbike-Profil. Die A46-Brücke hat "highway=path, bicycle=designated" und das hat im fastbike-Profil Kostenfaktor 10, also so gut wie verboten. Das trekking-Profil hingegen erkennt das "bicycle=designated" und bewertet den Weg besser. Da fehlt einfach ein tracktype=grade1 oder surface=paved, oder highway=cycleway, irgendwas halt, was den Weg aufwertet.

bianchifan wrote:

2. Das Profil "shortest" routet ohne Rücksicht auf Verluste, d.h. auch über wenig genutzte weil verwinkelte Brücken, d.h. enge und steile Treppen bzw. Drahtkäfige, wo man sein Rad aus Platzmangel kaum hochtragen kann bzw. senkrecht vor sich her bugsieren muss.

shortest ist auch nicht zum Radfahren gedacht, es ist einfach der Kürzeste Weg, den man zu Fuss passieren kann.

bianchifan wrote:

Beim gestrigen Querlesen habe ich irgendwo etwas von einem "Kostenfaktor" gelesen, eine Eingabemöglichkeit dafür habe ich nicht gefunden.

Die Profile enthalten die Kostenfaktoren, wenn Du da mal reinschaust siehst Du ganz viele Zahlen und die meisten davon sind Kostenfaktoren. Und die Fähre wurde auch nicht einfach so genommen, sondern mit 10000m Zusatzkosten, also die nimmt er nur, weil die Brücke so weit weg ist. Und diese Zahlen kann man alle ändern. In der Online-Version gibts dafür einen "Upload" Button, auf dem Handy muss man das mit einem Texteditor machen.

bianchifan wrote:

Weiterhin habe ich ebenfalls gelesen, dass Brouter wohl urspünglich für die Cooperation mit OSMAND ausgelegt wurde. Ich konnte aber heute feststellen, dass es, wenn auch "etwas umständlich", "Routinganforderungen" sowohl von Locus als auch von Oruxmaps erkennt und die Ergebnisse in deren Verzeichnisstruktur bereitstellt. Da nun diese beiden Programme Vektormaps Marke "mapsforge" sollte es doch spätestens mit der nächsten Version 0.4. möglich sein, diese fürs Routen zu nutzen.

Den Gedanken hatte ich auch schon, statt meiner eigenen "routing-data-files" einfach die open-andro-maps zu nehmen, aber ich habe mir das Format bisher nicht näher angeschaut, meine eigenen Dateien sind halt von der Daten-Vorverarbeitung und der Index-Struktur schon ziemlich spezifisch für schnellen Zugriff fürs Routing gemacht.

abrensch wrote:

Den Gedanken hatte ich auch schon, statt meiner eigenen "routing-data-files" einfach die open-andro-maps zu nehmen, aber ich habe mir das Format bisher nicht näher angeschaut, meine eigenen Dateien sind halt von der Daten-Vorverarbeitung und der Index-Struktur schon ziemlich spezifisch für schnellen Zugriff fürs Routing gemacht.

Hallo Arndt,

Ich könnte mir schon vorstellen die Tags die Du brauchst in die OpenAndroMaps einzubauen, oder auch deine Routingfiles so wie sie jetzt sind passend zu meinen Karten zu generieren.
Ich könnte ja mal eine Testkarte generieren, was ich bräuchte sind informationen über die erforderlichen Tags und was Du sonst noch benötigst und einen Permalink für den gewünschten Ausschnitt.

Wobei, vom Standpunkt der allgemeinen Verwendbarkeit ist Deine Lösung mit den eigenen Routingfiles sicher besser da es damit egal ist ob jemand die Freizeitkarte oder die Openandromaps oder die internen Locus-Karten verwendet. Ausserdem ist der User (und auch Du) damit unabhängig von Versionswechseln und Bugs in Mapsforge (da gibt es ganz Fiese) ausserdem nimmt Mapsforge immer das gesammte Objekt (Way/Poi) mit in die Karte auf wenn auch nur ein Tag gematched wird was bedeutet, das wenn ein way eine Routinginformation enthält, der ganze way mit allen Tags schon bei sehr niedrigen Zoom_leveln (die Du sicher fürs Routing ab Zoom Level 1 brauchst) komplett in die Karte aufgenommen wird - was sicher Probleme verursacht. ... Müsste man ausprobieren.

Beste Grüsse
Christian
www.openandromaps.org

Ui, das ging ja schnell...

abrensch wrote:

Die Profile enthalten die Kostenfaktoren, ....

Danke, habe ich heute entdeckt, ebenfalls auch so was wie ne Doku
(developers guide), muss ich mir mal reinziehn.
Ebenso habe ich entdeckt, dass Du wohl mit menion in Kontakt steht, sehr schön.
Das mit dem Server ist ne prima Sache, die auch weitere Einsatzmöglichkeiten eröffnet.

OT: Jetzt muss man Orux nur noch gescheite Sprachansagen beibringen 😉

christiank61 wrote:

..Wobei, vom Standpunkt der allgemeinen Verwendbarkeit ist Deine Lösung mit den eigenen Routingfiles sicher besser da es damit egal ist ob jemand die Freizeitkarte oder die Openandromaps oder die internen Locus-Karten verwendet...

Das steht völlig außer Frage und ist bei Verwendung von Pixelbildchen auch unerlässlich, es ging nur um den speziellen Fall des Vorhandenseins von mapsforge-Daten. Wenn ich richtig gelesen habe, sollen die in der Version 0.4 routingfähig werden. Ob das dann tatsächlich klappt, steht auf einem anderen Blatt.
Abgesehen davon ist auch auf Sd-Karten der Plattz nicht unendlich und bei echten Fernradlern kanns da auch schon mal knapp werden.

Etwas anderes, was ich gestern vergessen hatte, und mir beim Testen diverser Brücken aufgefallen ist:
Bei sehr kurzen Routen, so ca. 1 - 2 km LL wurden viapoints ignoriert, das Ergebnis kam dann auch ziemlich schnell ohne sichtbare Animation.

christiank61 wrote:

Ich könnte ja mal eine Testkarte generieren, was ich bräuchte sind informationen über die erforderlichen Tags und was Du sonst noch benötigst und einen Permalink für den gewünschten Ausschnitt.

Hi Christian,

naja, was ich bräuchte und was ich in den jetzigen rd5-Dateien drin habe ist leider nicht dasselbe... Ein voll-konfigurierbarer Router braucht per Definition alle Tags mit abzählbaren Wertebereich (d.h. Freitextfelder oder auch Strassennamen brauche ich nicht) In der lookup-Datei (http://brensche.de/brouter/profiles2/lookups.dat ) sind die 26 way-tags aufgeführt, die tatsächlich drin sind, wobei einige auch synthetisch sind (reversedirection, highway=ferry, ..). Die Beschränkung auf diese 26 ist eine rein technische, weil ich die in ein 64-bit Wort kodiere, und das ist eine ziemlich schmerzhafte Einschränkung, weil das viele Spezialanwendungen verhindert (Wheelchair-Routing zum Beispiel). Bei den Relationen ist es noch dünner, ich packe nur ein syntethisches Tag an den way: longdistancecycleway=yes heisst, es gibt mindestens eine Relation mit route=bicycle. Das heisst das Network-Tag an der Relation geht mir verloren, und das tut auch weh ("route=bicycle network=radweit" ist was ganz anderes als network=ncn), und Fernwanderwege sind auch nicht drin und Abbiegebeschränkungen auch nicht.

Also sollte ich irgendwann nochmal das Format refactoren, dann natürlich mit dem Ziel, diese Beschränkungen zu überwinden. Aber aktuell ist das kein Thema für mich. Speziell ist natürlich in den rd5-Dateien noch, dass an jedem Node die Höhe dransteht (linear aus SRTM interpoliert), glaube in den Vektor-Karten steht die nur indirekt als Höhenlinie?

Gruss, Arndt

bianchifan wrote:

OT: Jetzt muss man Orux nur noch gescheite Sprachansagen beibringen 😉

Ich vermute einfach mal, dass Orux die Android-Sprachausgabe nutzt. Also müsste man nicht Orux gescheite Sprachansagen beibringen sondern dem Android eine bessere TTS-Engine verpassen (in FroYo: com.android.settings -> "Voice input & output settings" (das vorletzte)). (Ausser du meintest den verwendeten Text und nicht die Stimme, ich kenne Orux nicht)

So, ich oute mich mal, als wenig englisch sprechender/verstehender. 🙂
Kann mir bitte einmal jemand die Namen der Profile übersetzen/erklären?

car-Test = scheint für Autos zu sein, also für mich nix. 🙂
trecking-ignore-cr= ?????
trecking-nosteps= ????
trecking=Normales Radfahren?
safety=Sicherheit? Was wird da sicherer?
shortest=Kürzester Weg auch über Landstraßen?
trekking-steep= ????
trekking-noferries= ????
fastbike= Rennrad?
moped= Roller/Moped, also keine Radwege, also für mich nix. 🙂

Meine Frage ist, welches der Profile soll ich verwenden, wenn mir folgendes wichtig ist.
Radwege=OK
Fußgängerwege=OK
Feldwege=Ok, wenn sie befestigt sind. (ich bin kein Matschfahrer)
Normale Straßen, also Ausserorts nur wenn es sein muss.

Ich dachte, damit wäre ich der normale Radfahrer.

Gruß, Rudi

Rudi56 wrote:

Kann mir bitte einmal jemand die Namen der Profile übersetzen/erklären?

car-Test = Auto, aber ohne Abbiegebeschränkungen, also in Städten mit Vorsicht zu geniessen
trekking-ignore-cr= Radrouten ohne Berücksichtigung von Fernradwegen
trekking-nosteps= Radrouten, die keine Treppen enthalten dürfen
trekking= "Normale Radrouten"
safety=Radrouten mit Vermeidung von Hauptstrassen ohne Radweg
shortest=kürzester Weg, der zu Fuss passierbar ist
trekking-steep= Radrouten ohne Berücksichtung des Höhenprofils
trekking-noferries= Radrouten, die keine Fähren enthalten dürfen
fastbike= Radrouten im wesentlichen auf Strassen oder erstklassigen Wirtschaftswegen/Radwegen
moped= Radrouten da, wo auch Autos fahren dürfen (auch für S-Pedelec)

Rudi56 wrote:

Meine Frage ist, welches der Profile soll ich verwenden, wenn mir folgendes wichtig ist.
Radwege=OK
Fußgängerwege=OK
Feldwege=Ok, wenn sie befestigt sind. (ich bin kein Matschfahrer)
Normale Straßen, also Ausserorts nur wenn es sein muss.

Ich dachte, damit wäre ich der normale Radfahrer.

Dann ist trekking schon o.k., wobei das im Dunkeln oder bei Regen
schon grenzwertig sein kann. Dann besser auf fastbike ausweichen.

Kurz und schmerzlos: ausprobieren!
steep heißt steil, noferries vermeidet Fähren, nosteps wahrscheinlich Treppen, ignore-cr und safety.. k.A., bislang habe ich keines dieser Profile getestet.
Tracking ist zumindest nicht übel.

Rudi56 wrote:

shortest=Kürzester Weg auch über Landstraßen?

Wenn eine Landstraße auf dem kürzesten Weg vorkommt, ja.
Ansonsten werden Steiltreppen und Drahtkäfige genauso bevorzugt wie SIngletrails, also nicht matschig sondern mitunter auch extrem holprig.

Ausgehend von der Prämisse "BRouter: offline Fahrrad-Routing für Android" sollte man da vielleicht einen Warnhinweis ausgeben 😉

Ich wollte es kaum glauben, aber Orux war fast schneller als der Schall:P, heute morgen war eine neue Beta fettich!

1. Brouter starten und als Server schlafen legen.
2. Oruxmaps starten, die Routenschalfläche betätigen, Route suchen selektieren, Startposition klicken, Ziel klicken, Broute (offline) als Dienst selektieren und ab die Lucy...nach kurzer Wartezeit wird die fertige Route eingeblendet. Wow!

Es handelt sich um eine erste Beta ohne viel Schnickschnack, da geht es ums Zusammenspiel, um Serverstabilität, einfach um die generelle Funktionsweise.
Brouter wird aufgerufen so wie er ist, bzw. in dem Zustand, in dem er als Server zum Schlafen bzw. watchdoggen, lauschen oder was auch immer geschickt wurde, d.h. ohne weitere Wegpunkte, ohne Profile, es wird das zuletzt verwendete herangezogen.
Wer das Profil wechseln möchte muss Brouter aufwecken und das gewünschte Profil selektieren.
Wer mit Wegpunkten und Sperrzonen arbeiten möchte kann das selbstverständlich auch, einfach wie gehabt definieren, Brouter starten, Animation betrachten und im Anschluss die erstellte Route selektieren und laden.
Möchte man im Anschluss wieder das interne Serverrouting strapazieren, no problem. Wenn man dafür aber das Profil wechselt und die erstellten Wegpunkte in der DB nicht entfernt hat gibt es eine schöne Animation und eine weitere Route:P

Und sonst? Einmal habe ich mich vertan und beim Initialisieren des Servers wahrscheinlich das Autoprofil gewählt, meine in die Pampas gelegten Eckpunkte wurden ungefragt auf in der Nähe befindlichen Kreuzungspunkten von Autustraßen gelegt:D

Ein paar Bildchen..

Definition in Oruxmaps

erneute Definition in Oruxmaps mit gleichen Koordinaten nach vorheriger Profiländerung fast -> track

Beide Ergebnisse in einem Bild

Selbe Gegend, andere Eckpunkte, diverse Ergebnisse intern/extern bzw. mit ohne Wegpunkte, aber mit selbststänger Verlagerung der Eckpunkte durch den Router

Und noch mal ne Übersicht mit Kurzprofil

---

OSMAND
Davon hatte ich nur eine Uraltversion auf meiner Speicherkarte, gestern habe ich mal das neueste gesaugt. Das mochte die alten Karte nicht mehr, also weitere 500 MB! für ein paar qkm. Erst heute wurden sie dann nach gefühlten 100 Startversuchen im Emulator erkannt.
Positiv: Von der Orientierung her eine der besten OSM-Karten, in vielen Zoomstufen werden Städte- und Gemeindenamen gelistet, auch wenn sich hier ebenfalls der ein oder andere Hinterhof hineinschummelt.
Negativ: entfällt - das gleiche wie früher, ich kapier das System nicht, für meinen Horizont ist das Proggie nicht geschaffen, mit Intuition komme ich nicht weiter, zum Einlesen habe ich keinen Bock.

Edit:
Und noch etwas: Orux hat sich an anderer Stelle zur Problematik des wohl auch bei ihm manchmal abrauchenden Servers geäußert.
Bei mir ist er bislang nicht weggetaucht, weder in der virtuellen Box noch auf'm Defy (Quarx'sche Spezialversion 😉 )

bianchifan wrote:

Ich wollte es kaum glauben, aber Orux war fast schneller als der Schall:P, heute morgen war eine neue Beta fettich!

Hi und Danke fuer den Hinweis,

Du hast es zwar verlinkt, aber hier nochmal der Link auf das APK: http://www.oruxmaps.com/OruxMaps5.5.2beta10.apk

Hab's auch mal probiert und funktionert schon nicht schlecht.

Aber die Issues sind ja bekannt:

- einmal das Konfigurations-Thema, dass in diesem Setup auch die car/bike/foot,fast/short Auswahl aus dem Maptool einen Sinn machen sollte (wie couchmapper auch schon geschrieben hat: http://forum.openstreetmap.org/viewtopi … 61#p340861 )

- und das Problem der Server-Stops durch Android, von dem Du auch schreibst.

Aber da kommt langsam Dynamik in das Thema, sollte doch möglich sein, bald ein unabhängiges Maptool <-> Router Interface zu etablieren, was nicht nur für BRouter funktioniert, sondern für jeden offline-Router, der das Interface implementiert.

bianchifan wrote:

Wer mit Wegpunkten und Sperrzonen arbeiten möchte kann das selbstverständlich auch, einfach wie gehabt definieren, Brouter starten, Animation betrachten und im Anschluss die erstellte Route selektieren und laden.

Die Sperrzonen behält auch der Servermode! Die Wegpunkte aber nicht, das geht konzeptionell nicht.

bianchifan wrote:

Und sonst? Einmal habe ich mich vertan und beim Initialisieren des Servers wahrscheinlich das Autoprofil gewählt, meine in die Pampas gelegten Eckpunkte wurden ungefragt auf in der Nähe befindlichen Kreuzungspunkten von Autustraßen gelegt:D

Das er die Position auf den nächstgelegenen Weg matched, über den das gewählte Profil auch routen kann, ist ein Feature und kein Fehler... Für automatische Neuberechnungen, wenn die Position vom GPS kommt und nicht von einer Benutzereingabe, ist das wichtig.

abrensch wrote:

naja, was ich bräuchte und was ich in den jetzigen rd5-Dateien drin habe ist leider nicht dasselbe...
...dass an jedem Node die Höhe dransteht (linear aus SRTM interpoliert), glaube in den Vektor-Karten steht die nur indirekt als Höhenlinie?

Hallo Arndt,

Die Höhendaten gibt es in Mapsforge tatsächlich nur als Kontourlinie ohne jede interne Beziehung zu den OSM-Nodes.

Es gibt noch eine kleine Gemeinheit in Mapsforge:
Wenn in einem Objekt mehrere Attribute drinstehen die die gleichen Values habe können (oneway=yes/no tunnel=yes/no etc) ist es dem Zufall überlassen was nun für welches Tag gerendert wird, dh. wenn ein tunnel (=yes) ein oneway=no enthält so wird der Tunnel oft mit dem Attribut des oneways gerendert (also NO).
Wo der Fehler liegt weis ich nicht, ich würde mich beim Routing jedenfalls nicht auf Mapsforge verlassen - für die Kartendarstellung selbst ist egal, ich Filtere einfach die unnötigen Tags raus oder weise ihnen eindeutige values zu - fürs Routing ist das sicher weniger lustig mit solch "gekürzten/modifizierten" Datensätzen zu arbeiten.

Viele Grüsse
Christian
PS: Ich habe mir den BRouter mal angesehen - WELL DONE, alle Achtung, das das überhaupt geht hätte vor ein paar Monaten noch keiner geglaubt!!

Also zuerst nochmal:
Ein ganz dickes DANKE an den brouter Autor!

Ich versuche den in Zusammenarbeit mit OSMAND. (Hatte ich ja schon erwähnt)
Um Ihm nun ab zu gewöhnen, mich immer wieder über Wege zu routen, die ich nicht mag,
Versuche ich mich in den Config Files.
Da ich des Englischen aber nicht so 100% mächtig bin versuche ich mal, mir das eine
und andere hier erklären zu lassen. Ich hoffe ich gehe euch nicht zu sehr auf den Keks.

Zuerst mal zu der Zeile:
"assign probablyGood or ispaved and isbike not isunpaved"
Da wird der Variablen "probablyGood" etwas zugewiesen.
Was ich dabei nicht verstehe: wie ist das oder das und und das not zu sehen.
Kann mir das mal einer in der Form hinschreiben:
probablyGood = (( ispaved || != isunpaved ) && (isbike) )
Also etwas C Like. 🙂
Stimmt das was ich da geschrieben habe?

Nächster Fall, der mir etwas Kopfzerbrechen bereitet:

switch␣or␣highway=track␣or␣highway=road␣or␣highway=path␣highway=footway
switch␣tracktype=grade1␣switch␣probablyGood␣1.0␣1.3
switch␣tracktype=grade2␣switch␣probablyGood␣1.1␣2.0
switch␣tracktype=grade3␣switch␣probablyGood␣1.5␣3.0
switch␣tracktype=grade4␣switch␣probablyGood␣2.0␣5.0
switch␣tracktype=grade5␣switch␣probablyGood␣3.0␣5.0
switch␣probablyGood␣1.0␣5.0

Warum stehen da immer 2 Zahlen dahinter.
Es scheint mir so, das ich das ganze SWITCH Konstrukt nicht verstehe.
Schon die Eingangszeile mit dem "switch or .." versteh ich nicht.
Wann ist ein switch fertig?

Ich bin wie immer für alle Antworten Dankbar.

Gruß, Rudi

Auf meinem Motorola Defy+ (Android 2.3.6) mit OruxMaps v.5.5.2 funktioniert BRouter 0.9.3 nicht.
Ich starte BRouter und wähle das "trekking"-Profil.
Dann erscheint die Meldung:
"Success

---

no from/to found (coordinate-source: /mnt/sdcard/oruxmaps)

---

[Exit] [Server-Mode]"
Diese Meldung bestätige ich mit [Server-Mode].
Danach setzte ich die service-modes foot_short, foot_fast, bicycle_shot und bicycle_fast und bestätige mit [Ok].
Nach dem Tippen auf [Ok] (bei der service-mode-Auswahl) erscheint wieder mein Android-Home-Screen. Ist jetzt BRouter abgestürzt?
Wenn ich jetzt in OruxMaps das Routing über BRouter versuche, erhalte ich die Fehlermeldung:
"BRouter http://brence.de/brouter not found or not started. Must be installed and started as a server." (oder so ähnlich)

Rudi56 wrote:

Zuerst mal zu der Zeile:
"assign probablyGood or ispaved and isbike not isunpaved"

Da wird der Variablen "probablyGood" etwas zugewiesen.
Was ich dabei nicht verstehe: wie ist das oder das und und das not zu sehen.
Kann mir das mal einer in der Form hinschreiben:
probablyGood = (( ispaved || != isunpaved ) && (isbike) )
Also etwas C Like. 🙂
Stimmt das was ich da geschrieben habe?

Nein. Es heisst:

probablyGood = ispaved || ( isbike && !isunpaved )

Das ungewohnte ist, dass der Operator immer voran steht (=polnische Notation,
http://de.wikipedia.org/wiki/Polnische_Notation )

Lag ursprünglich daran, dass mir ein parser/compiler für die "gewohnte" Notation zu schwierig war, aber letztendlich finde ich diese klammerfreie Schreibweise auch ganz gut lesbar, wenn man's mal gewohnt ist.

Rudi56 wrote:

Nächster Fall, der mir etwas Kopfzerbrechen bereitet:

switch␣or␣highway=track␣or␣highway=road␣or␣highway=path␣highway=footway
switch␣tracktype=grade1␣switch␣probablyGood␣1.0␣1.3
switch␣tracktype=grade2␣switch␣probablyGood␣1.1␣2.0
switch␣tracktype=grade3␣switch␣probablyGood␣1.5␣3.0
switch␣tracktype=grade4␣switch␣probablyGood␣2.0␣5.0
switch␣tracktype=grade5␣switch␣probablyGood␣3.0␣5.0
switch␣probablyGood␣1.0␣5.0

Warum stehen da immer 2 Zahlen dahinter.
Es scheint mir so, das ich das ganze SWITCH Konstrukt nicht verstehe.
Schon die Eingangszeile mit dem "switch or .." versteh ich nicht.
Wann ist ein switch fertig?

Nach 3 Ausdrücken, also

switch <boolean-expression> <true-expression> <false-expression>

In dieser verketteten Schreibweise wird ein "switch" also in einer Zeile nicht fertig,
in der naechsten Zeile beginnt in der Regel die "false-expression" eines unfertigen
Switch-Ausdrucks, also wenn man Klammern setzt:

␣␣␣switch␣(or␣highway=track␣or␣highway=road␣or␣highway=path␣highway=footway)
(␣switch␣tracktype=grade1␣(␣switch␣probablyGood␣1.0␣1.3␣)
(␣switch␣tracktype=grade2␣(␣switch␣probablyGood␣1.1␣2.0␣)
(␣switch␣tracktype=grade3␣(␣switch␣probablyGood␣1.5␣3.0␣)
(␣switch␣tracktype=grade4␣(␣switch␣probablyGood␣2.0␣5.0␣)
(␣switch␣tracktype=grade5␣(␣switch␣probablyGood␣3.0␣5.0␣)
(␣switch␣probablyGood␣1.0␣5.0␣)
)␣)␣)␣)␣)

Leider nur auf englich mehr dazu hier: http://brensche.de/brouter/profile_developers_guide.txt

Tobias Heilig wrote:

Auf meinem Motorola Defy+ (Android 2.3.6) mit OruxMaps v.5.5.2 funktioniert BRouter 0.9.3 nicht.

Also für die direkte Zusammenarbeit zwischen OruxMaps und BRouter passt das so leider nicht zusammen.

Was Oruxmaps da macht bezieht sich auf die Vorgaenger-Schnittstelle, die internes HTTP auf dem Handy verwendet. Dazu musst Du BRouter BRouter 0.9.2 verwenden. Macht aber nicht so wirklich Freude, weil der HTTP-Server sich immer mal beendet und dann neu gestartet werden muss. Siehe http://brensche.de/brouter/revisions.html

Jose wollte in Oruxmaps die neue Schnittstelle aus BRouter 0.9.3 einbauen (=Android-Spezifische Interprozesskommunikation), aber irgendwie ist da gerade Sommerpause, das zieht sich bisschen.

Was aber auf jeden Fall funktioniert ist die "klassische Bedienung" über die Dateischnittstelle, wenn Du Wegpunkte setzt in Oruxmaps.

abrensch wrote:

Nach 3 Ausdrücken, also

switch <boolean-expression> <true-expression> <false-expression>

In dieser verketteten Schreibweise wird ein "switch" also in einer Zeile nicht fertig,
in der naechsten Zeile beginnt in der Regel die "false-expression" eines unfertigen
Switch-Ausdrucks, also wenn man Klammern setzt:

␣␣␣switch␣(or␣highway=track␣or␣highway=road␣or␣highway=path␣highway=footway)
(␣switch␣tracktype=grade1␣(␣switch␣probablyGood␣1.0␣1.3␣)
(␣switch␣tracktype=grade2␣(␣switch␣probablyGood␣1.1␣2.0␣)
(␣switch␣tracktype=grade3␣(␣switch␣probablyGood␣1.5␣3.0␣)
(␣switch␣tracktype=grade4␣(␣switch␣probablyGood␣2.0␣5.0␣)
(␣switch␣tracktype=grade5␣(␣switch␣probablyGood␣3.0␣5.0␣)
(␣switch␣probablyGood␣1.0␣5.0␣)
)␣)␣)␣)␣)

Ok, dauert etwas für mich, mich da einzulesen, aber ich glaube der erste Funke ist über gesprungen.
Danke dir dafür.

Gruß, Rudi

bianchifan wrote:

Und noch etwas: Orux hat sich an anderer Stelle zur Problematik des wohl auch bei ihm manchmal abrauchenden Servers geäußert.
Bei mir ist er bislang nicht weggetaucht, weder in der virtuellen Box noch auf'm Defy (Quarx'sche Spezialversion 😉 )

Mittlerweile ist die Technik umgestellt, BRouter implementiert seit Version 0.93 eine Android-spezifische Dienste-Schnittstelle und OruxMaps in der Version 5.5.3 (= aktuell in Google-Play) ruft diese Schnittstelle.

Damit gibt's keine Probleme mehr mit dem Dienst-Lebenszyklus (da muss kein Dienst laufen, OruxMaps startet ihn einfach) und damit gibt's auch nicht mehr die "voller Internetzugang" Berechtigung bei BRouter (ist ja schliesslich eine Offline-App...)

Ich hab' an der "anderen Stelle" heute noch bisschen was geschrieben zur Konfiguration.

https://groups.google.com/forum/#!topic … AGCaq32QUU

Das die Google-Play Variante von Orux das jetzt kann ist ein schöner Schritt vorwärts, aber es gibt halt auch noch sooo viel zu tun (schnelle partielle Neuberechnungen, Advanced Voice-Navigation hints, ...)

Bei Locus besteht Interesse, diese Schnittstelle zu integrieren (aber er hätte auch gerne die Voice-Navigation hints...), bei OsmAnd ist das Interesse gedämpfter weil sie ja einen eigenen offline Router haben, aber die Aussgae ist, dass sie einen Pull-Request dazu nicht ablehnen würden. Was jetzt fehlt ist primär Zeit...

Hi Arndt,

ich habe BRouter in Verbindung mit Oruxmaps getestet. Auf meinem Huawei X3 mit Android 2.3.3 läuft die Verbindung BRouter OruxMaps problemlos.
Oruxmaps liegt auf der SD Karte unter /mnt/sdcard/oruxmaps. Es geht sowohl Brouter mit "from/to", als auch das Routing innerhalb von OruxMaps.

...aber auf meinen LG-P700 mit Android 4.0.3 bringe ich das nicht zum Laufen.
OruxMaps kann ja nicht vollständig auf /mnt/sdcard/external_sd/ ausgelagert werden die ORUX-DB mit den Waypoints etc. muß auf der internen SD liegen (laut Forum) also auf /mnt/sdcard.
Es gibt also zwei Pfade:

/mnt/sdcard/oruxmaps kann/darf nicht verschoben werden laut Orux

und

/mnt/sdcard/external_sd/OruxData zegt auf die Maps, exportierten Tracklogs etc. gleiche Struktur wie zuvor

Wie muß man BRouter installieren bzw. geht das überhaupt?

BRouter meldet "An Error occured"
No coordinate source from a maptool found.......etc...

und kann nicht gestartet werden. Kann nur durch Deinstallation beseitigt werden.

Was mache ich falsch?

Viele Grüsse
Achim

Ps: Pathproblem OruxForum ==> http://oruxmaps.foroactivos.net/t2816-t … or-feature

abrensch wrote:

bianchifan wrote:

Und noch etwas: Orux hat sich an anderer Stelle zur Problematik des wohl auch bei ihm manchmal abrauchenden Servers geäußert.
Bei mir ist er bislang nicht weggetaucht, weder in der virtuellen Box noch auf'm Defy (Quarx'sche Spezialversion 😉 )

Mittlerweile ist die Technik umgestellt, BRouter implementiert seit Version 0.93 eine Android-spezifische Dienste-Schnittstelle und OruxMaps in der Version 5.5.3 (= aktuell in Google-Play) ruft diese Schnittstelle.

Damit gibt's keine Probleme mehr mit dem Dienst-Lebenszyklus (da muss kein Dienst laufen, OruxMaps startet ihn einfach) und damit gibt's auch nicht mehr die "voller Internetzugang" Berechtigung bei BRouter (ist ja schliesslich eine Offline-App...)

Ich hab' an der "anderen Stelle" heute noch bisschen was geschrieben zur Konfiguration.

https://groups.google.com/forum/#!topic … AGCaq32QUU

Das die Google-Play Variante von Orux das jetzt kann ist ein schöner Schritt vorwärts, aber es gibt halt auch noch sooo viel zu tun (schnelle partielle Neuberechnungen, Advanced Voice-Navigation hints, ...)

Bei Locus besteht Interesse, diese Schnittstelle zu integrieren (aber er hätte auch gerne die Voice-Navigation hints...), bei OsmAnd ist das Interesse gedämpfter weil sie ja einen eigenen offline Router haben, aber die Aussgae ist, dass sie einen Pull-Request dazu nicht ablehnen würden. Was jetzt fehlt ist primär Zeit...

Hi Arndt,

das klingt wunderbar. Leider bekomme ich weder ein Routerin mit OruxMaps hin (was muss in einstellen?) und dann verstehe ich noch nicht die Zuordnung der Routing-Profile. Welches ist welches? Was ist "Bicycle_short" und was "Bicycle_fast"? Ich würde gerne "trekking" und ein eigenes Profil verwenden, dass sich an die CycleRoutes hält. Kann man die Profile zuweisen?

womisa wrote:

OruxMaps kann ja nicht vollständig auf /mnt/sdcard/external_sd/ ausgelagert werden die ORUX-DB mit den Waypoints etc. muß auf der internen SD liegen (laut Forum) also auf /mnt/sdcard.
Es gibt also zwei Pfade:

/mnt/sdcard/oruxmaps
/mnt/sdcard/external_sd/OruxData

Wie muß man BRouter installieren bzw. geht das überhaupt?
...
Was mache ich falsch?

Hi Achim,

garnichts, Du hast einfach Recht, da ist eine Lücke. Da muss ich wohl nochmal ran und die Konfiguration der Basisverzeichnisse bzw. die Suche nach den Map-Tools flexibler machen.

Du kannst natürlich das BRouter-Verzeichnis auch unter /mnt/sdcard/ anlegen, dann passt es, d.h. er findet die Datei /mnt/sdcard/oruxmaps/tracklogs/oruxmapstracks.db (mehr braucht er nicht).

Du kannst aber auch einmalig die Datei oruxmapstracks.db händisch an eine Stelle im Dateisystem kopieren, wo BRouter sie findet, also /mnt/sdcard/external_sd/oruxmaps/tracklogs/oruxmapstracks.db (wenn /mnt/sdcard/external_sd Dein Basisverzeichnis ist), denn Du brauchst da ja nur initial, um die Konfiguration durchzuführen, beim Betreib über die Diensteschnittstelle spielen Datei-Pfade ja dann keine Rolle mehr.

thaigait wrote:

das klingt wunderbar. Leider bekomme ich weder ein Routerin mit OruxMaps hin (was muss in einstellen?) und dann verstehe ich noch nicht die Zuordnung der Routing-Profile. Welches ist welches? Was ist "Bicycle_short" und was "Bicycle_fast"? Ich würde gerne "trekking" und ein eigenes Profil verwenden, dass sich an die CycleRoutes hält. Kann man die Profile zuweisen?

Hallo thaigait,

in oruxmaps ist es das Autobahn-Symbol in der Top-Leiste und dann "Route suchen". Dann hast Du unten 3 Auswahlboxen. In der dritten musst Du statt "Cloudmade" "BRoute" wählen. Die beiden anderen definieren den Modus (also eine der 6 Kombinationen aus Auto/Fahrrad/Fuss + short/fast).

Ein Mapping zwischen Modus und Profil gebe ich nicht vor, das musst Du selber konfigurieren, indem Du Brouter "klassisch" startest (mit oder ohne from/to-Koordinaten, geht beides) und anschliessend den "Server-Mode" Button drückst, dann hast Du die 6 Modi zur Auswahl und kannst wählen, für welche Du die gerade eben benutzte Konfiguration (=Profil + Liste der Sperrpunkte) hinterlegen willst. Solange Du das nicht gemacht hast, wird Oruxmaps eine Fehlermeldung bringen, wenn nur einModus fehlt, nimmt er stattdessen den zuletzt konfigurierten.

abrensch wrote:

Mittlerweile ist die Technik umgestellt, BRouter implementiert seit Version 0.93 eine Android-spezifische Dienste-Schnittstelle und OruxMaps in der Version 5.5.3 (= aktuell in Google-Play) ruft diese Schnittstelle

I do know it... und habe es bereits vor einiger Weile gestestet, Orux hatte wenige Tage nach Erscheinen Deiner 0.93 bereits umgestellt, ich war lediglich schreibfaul..:P

Ich hatte die Kombi intensiv getestet und dutzende Bilder hochgeladen, bei Gelegenheit werd ich mal einige hier verlinken.
Vorab: Ein Hauptproblem im Zusammenspiel ist nach wie vor die Geschwindigkeit, was auf dem 4-Kerner in der Emu noch klappt rennt auf dem realen Androiden dann ins timeout: Routen mit mehr als ca. 50km Länge kann mein Defy nicht routen.
Lange Routen, so 120 - 150 km in ca. dauern auch in der Emu so ab 300 sec aufwärts, 500 - 600 sec können erreicht werden.
Lt. Animation scheinen 3 Durchläufe statt zu finden, der erste ist meistens recht schnell, von Sekundenbruchteilen bis zu ca. 20 sec, der zweite deutlich langsamer und der dritte quälend langsam. SO kann z.B. eine 60 km Route im 1. Lauf unter 2 sec benötigen, im 2. zwischen 5 und 20 und im 3. dann im Zeitfenster noch gerade ein Ergebnis liefern oder dieses mit über 100 sec drastisch verfehlen.

Hier ist noch einiges zu tun, imho sinnvoller als Auto(mobil) Gedöns und weitere Profile.

Des weiteren ist mir aufgefallen, dass Brouter bei LInkskurven mit separaten Radwegen den Weg in der Gegenrichtung wählt, nach STVO nicht gestattet und kürzlich in D'dorf im Rahmen einer Aktionwoche mit saftigem Bußgeld (30 Euro wegen Verkehrgefährdung) belegt.

womisa wrote:

..OruxMaps kann ja nicht vollständig auf /mnt/sdcard/external_sd/ ausgelagert werden die ORUX-DB mit den Waypoints etc. muß auf der internen SD liegen (laut Forum) also auf /mnt/sdcard.
Es gibt also zwei Pfade:

/mnt/sdcard/oruxmaps kann/darf nicht verschoben werden laut Orux

und

/mnt/sdcard/external_sd/OruxData..

Das verstehe ich nicht so wirklich..wieso interne SD Karte, verschieben..?

Möchtest Du die app auf die externe SD Karte verschieben? Warum um alles in der Welt?
Ich bin kein ANdroid Spezi, aber ich habe mal irgendwo gelesen, das das Verschieben einer app-Installation auf die externe SD Karte seid Version 4.0 nicht mehr möglich ist, jedenfalls nicht mit dem offiziellen Android.
Im Normalfall sollte daher die app auf der internen SDcard installiert sein, die Arbeitsverzeichnisse (also Karten, Db e.t.c, der ganze schmarren halt) aber komplett auf der externen SD Karte! Und deren Hauptverzeichnis wird bei der Brouter Installation angegeben!
Wie das nun letztendlich ist abhängig von android Version bzw. Herstellerimplementation.

Das kann sein:
/mnt/sdcard
/mnt/ext_SD
/mnt/erternal_sd
/storage/external
/storage/emulated/0

Am häufigsten gesehen habe ich bislang /mnt/sdcard und /storage/emulated/0.

Solltest Deine externe SD also /mnt/sdcard/external_sd heißen dann ist dem halt so.
Die paar kB Oruxmaps sollten doch noch ein Plätzchen auf der internen SD Karte finden und als Arbeitsverzeichnisse nimmst Du die externe Karte,
also /mnt/sdcard/external_sd/oruxmaps/tracklogs z.B für die oruxmapstracks.db

bianchifan wrote:

Des weiteren ist mir aufgefallen, dass Brouter bei Linkskurven mit separaten Radwegen den Weg in der Gegenrichtung wählt, nach STVO nicht gestattet und kürzlich in D'dorf im Rahmen einer Aktionwoche mit saftigem Bußgeld (30 Euro wegen Verkehrgefährdung) belegt.

Darum sollten Radwege bei denen das zutrifft ein oneway=yes erhalten 😉

Hi Arndt,
vielen Dank für die Antwort. Die Segmentdateien will ich natürlich auf der externen SD Karte haben. Also bleibt mir nur die OruxDB zu kopieren. Das geht dann auch wenn man das Routing intern von Oruxmaps nutzt.

abrensch wrote:

Du kannst aber auch einmalig die Datei oruxmapstracks.db händisch an eine Stelle im Dateisystem kopieren, wo BRouter sie findet, also /mnt/sdcard/external_sd/oruxmaps/tracklogs/oruxmapstracks.db (wenn /mnt/sdcard/external_sd Dein Basisverzeichnis ist), denn Du brauchst da ja nur initial, um die Konfiguration durchzuführen, beim Betreib über die Diensteschnittstelle spielen Datei-Pfade ja dann keine Rolle mehr.

...aber dann geht das Routen mit BRouter mit "from/to" nicht. Bei mir kommt dann die Meldung

...Sucess
no from/to found
(coordinate-source:/mnt/sdcard/external_sd/osmand)

... warum er da ins osmand direktory geht kannst nur Du wissen. Er sollte in dem Fall im .../OruxData/tracklogs suchen. Aber selbst da würde er nur die kopierte DB mit dem from/to finden. Suchen sollte er aber im
aktuellen /mnt/sdcard/oruxmaps/tracklogs Direktory. Ich nutze Brouter um mir mehere alternativen zu generieren. Das geht ja intern in OruxMaps nicht, ODER?

Das mit dem from/to ist eine feine Sache seit man die from/to Marker verschieben kann. Ist das nicht möglich dieses auch in OruxMaps via Intent aufzurufen, ohne dass man OruxMaps verlassen muß um BRouter mehrmals zu starten? Angenehm ist, dass da GPX Routen/Files angelegt werden......

Wie aber schon oben erwähnt, unter 2.3.3 auf dem Huawei X3 funktioniert das gut

bianchifan wrote:

Solltest Deine externe SD also /mnt/sdcard/external_sd heißen dann ist dem halt so.
Die paar kB Oruxmaps sollten doch noch ein Plätzchen auf der internen SD Karte finden und als Arbeitsverzeichnisse nimmst Du die externe Karte,
also /mnt/sdcard/external_sd/oruxmaps/tracklogs z.B für die oruxmapstracks.db

...genau so mache ich das ja. Aber da klappt das Zusammenspiel OruxMaps mit BRouter nicht! Genau das ist mein Problem, welches von Arndt bestätigt wurde..... und hoffentlich bald abgemildert wird.

Hi,

Ich antworte mal gesammelt:

zur /sdcard-Problematik: die Probleme entstehen mit Android-4, wo /mnt/sdcard in der Regel garkeine Karte mehr
ist, sondern fest eigebaut, aber *trotzdem* was anderes als der "interne Telefonspeicher", wo die Apps selbst
installiert sind (und auch nochmal ein Arbeitsverzeichnis haben, wo sie Dateien ablegen können. Mein bisheriger
Ansatz, das Basisverzeichnis für die BRouter-Dateien und für die Suche nach den Wegpunkte-Datenbanken der Maptools
gleichzusetzen funktioniert bei Oruxmaps nicht mehr, weil Oruxmaps bzgl. der Datenbankfiles fest gegen die
eingebaute Karte (/mnt/sdcard) programmiert ist. Ich werde BRouter entsrechend flexibler machen.

Zur Geschwindigkeit: Das mit den 3 Durchgängen stimmt, und der erste entspricht dem, was sie
bei OsmAnd "Routing" nennen und der dritte dem, was sie bei OsmAnd "precice Routing" nennen. Ich mache
den ersten Durchgang aber nur, um eine obere Schätzung zu bekommen, die beim dritten Durchgang das
Suchgebiet besgrenzen soll und würde nicht auf die Idee kommen, das Ergebnis des ersten Durchgangs als
Routingergebnis zu verkaufen. Das ist nämlich keins.

Andere setzten auf contraction-hirachies, also vorberechnete Teil-Routen, aber dabei geht jede Konfigurierbarkeit verloren.

Was ich tatsächlich plane nenn ich "fast partial recalculations", um speziell das Problem der Neuberechnung nach
Track-Abweichung zu lösen. Das kann man natürlich bisschen weiter spinnen, indem man nicht nur einen
"vorher berechneten Track" speichert, auf den man sich bei einer partiellen Neuberechnung bezieht, sondern
mehrere, und da wird der Übergang zu den contraction-hirarchies fliessend. mal sehen.

zu den paarweisen Radwegen ich denke, ich werd's mal so probieren, dass ich mich mal auf die gemappte Richtung des Radweges beziehe und nur eine kleine Symmetriebrechung einbaue, (+- 2% Kostendifferenz oder so), so dass in der Regel die richtige Seite genommen werden sollte. onway=yes für solche Wege halte ich für problematisch.

Gruss, Arndt

abrensch wrote:

thaigait wrote:

das klingt wunderbar. Leider bekomme ich weder ein Routerin mit OruxMaps hin (was muss in einstellen?) und dann verstehe ich noch nicht die Zuordnung der Routing-Profile. Welches ist welches? Was ist "Bicycle_short" und was "Bicycle_fast"? Ich würde gerne "trekking" und ein eigenes Profil verwenden, dass sich an die CycleRoutes hält. Kann man die Profile zuweisen?

Hallo thaigait,

in oruxmaps ist es das Autobahn-Symbol in der Top-Leiste und dann "Route suchen". Dann hast Du unten 3 Auswahlboxen. In der dritten musst Du statt "Cloudmade" "BRoute" wählen. Die beiden anderen definieren den Modus (also eine der 6 Kombinationen aus Auto/Fahrrad/Fuss + short/fast).

Oh man, ich war echt zu doof 🙄! Vielen Dank für Deine GEDULD hier 😄!

abrensch wrote:

Ein Mapping zwischen Modus und Profil gebe ich nicht vor, das musst Du selber konfigurieren, indem Du Brouter "klassisch" startest (mit oder ohne from/to-Koordinaten, geht beides) und anschliessend den "Server-Mode" Button drückst, dann hast Du die 6 Modi zur Auswahl und kannst wählen, für welche Du die gerade eben benutzte Konfiguration (=Profil + Liste der Sperrpunkte) hinterlegen willst. Solange Du das nicht gemacht hast, wird Oruxmaps eine Fehlermeldung bringen, wenn nur einModus fehlt, nimmt er stattdessen den zuletzt konfigurierten.

Ahhh, JETZT hab ich auch das verstanden 🙂. Nun funktioniert alles wunderbar. Ich finde es nur etwas schade, dass man nicht die Länge der Strecke anzeigen lassen kann. Aber das ist ja ein OruxMaps Problem....

thaigait wrote:

........ Ich finde es nur etwas schade, dass man nicht die Länge der Strecke anzeigen lassen kann. Aber das ist ja ein OruxMaps Problem....

..also auf Umwegen geht das schon. Ich habe auch lange gesucht. Vorgehensweise:

-Routen mit BRouter erstellen ( Einstellungen Track/Route muss Routenstart angehakt sein!!!)
-KURZ (!!!)auf den Marker am Routenanfang klicken
-Im Kontextmenü runterscrollen und die Route speichern
-Route entfernen
-Abgespeicherte Route laden
-Auf Routenanfangmarker klicken (kurz)
-Im Kontextmenü gibts jetzt zwei Abschnitte (Wegpunkt) und (Route)
-Im zweiten Abschnitt steht dann zum Beispiel die Strecke ..etc....

Ich hoffe das hilft dir etwas.

BRouter auf Nexus 7 (Android 4.3)

Das Thema zieht sich ja leider schon recht lange dahin, nachdem es wieder bei einem klappt, schliesse ich mich mit "geht nicht " an :-)

Ich habe bereits alle möglichen Pfade ausprobiert (Post 155), das Nexus 7 hat hier nahezu alle im Angebot, die dann im selben Verzeichnis landen (es sieht zumindest so aus)

Stand:
Ich erhalte nach der Installation die Verzeichnisabfrage die ich bestätige
dann kommt die Profilauswahl -> Hier wähle ich z.B Trecking
Dann erhalte ich eine Fehlermeldung:
An Error occured
java.lang.RuntimeExeption:java.ioEOFExeption
->Jetzt kommt man nur noch mit deinstallieren und reinstallieren weiter, man erhält sonst immer die Meldung.

Habt ihr noch ein paar Tipps?

Gruß Ludwig

ludwich wrote:

An Error occured
java.lang.RuntimeExeption:java.ioEOFExeption
->Jetzt kommt man nur noch mit deinstallieren und reinstallieren weiter, man erhält sonst immer die Meldung.

Ich tippe auf korrupte .rd5 Dateien, z.B. abgeschnittene (also zu kleine) Kannst Du mal die Datei-Grössen der verwendeten RD5-Dateien prüfen?

Danke für den Tipp .-)

Sieht gut aus - jetzt geht`s ans testen.

ludwich

abrensch wrote:

Mein bisheriger Ansatz, das Basisverzeichnis für die BRouter-Dateien und für die Suche nach den Wegpunkte-Datenbanken der Maptools gleichzusetzen funktioniert bei Oruxmaps nicht mehr, weil Oruxmaps bzgl. der Datenbankfiles fest gegen die eingebaute Karte (/mnt/sdcard) programmiert ist. Ich werde BRouter entsrechend flexibler machen.

Ich habe heute die Version 0.94 deployed, die diese Änderung enthält. Siehe http://brensche.de/brouter/revisions.html

Alle unterstützten Mapttools (osmand/locus/oruxmaps) werden jetzt immer zusätzlich unter /mnt/sdcard gesucht (genauer: unter Environment.getExternalStorageDirectory() )

Ausserdem habe ich einen Fehler in der Fehlerbehandlung im Service-Interface behoben, so dass man dort jetzt bessere Fehlermeldungen bekommt.

Hallo Arndt,

..werde ich dann mal testen. Danke für das Update.

Bei OruxMaps ist das unangenehm, dass man bei jedem Routen die Parameter neu einstellen muß. Oder dass man das in der Konfiguration einstellen kann. Hast Du einen direkten Draht zu dem Oruxentwickler um das anzuregen, im Forum geht das meistens unter.

Eine andere Frage: Kann mann mit Oruxmaps mit der Routingfunktion auch gleich die alternativen generieren (zB.:Parameter Anzahl=3) und es werden entsprechend Brouter Files erzeugt, ohne BRouter extern aufrufen zu müssen....

Hallo Arndt,

also auf meinem LG_P700 mit der Android Version 4.0.3 läuft das in Verbindung mit Oruxmap jetzt.

Was mir (!) nicht so gefällt ist folgendes, aber man kann damit leben!!!

Ich habe zur Zeit OruxMaps V5.5.3beta11.

OruxInstallationsdir: /mnt/sdcard/oruxmaps/
OruxDaten: /mnt/sdcard/external_sd/OruxData

BRouter DirAnfrage : /mnt/sdcard/external_sd/

-Installation funzt jetzt.

Was mir nicht so gefällt, dass BRouter wenn man den außerhalb von Oruxmaps mit den "from/to" Parametern startet werden die Routingfiles im Oruxmaps dir wo die Datenbank ist abgelegt ==> /mnt/sdcard/oruxmaps/tracklogs

und nicht im erwarteten OruxDatendirektory also auf ==>/mnt/sdcard/external_sd/OruxData/tracklogs

Oruxmaps sucht aber DEFAULT mäßig im konfigurierten Daten-Verzeichnis:==> /mnt/sdcard/external_sd/OruxData/tracklogs

Somit muß man jedesmal beim Laden der "brouterx.gpx" Files jedesmal das Direktorie wechsen und das ist unschön.

Schön wäre auch, wenn man mit einem Lauf von BRouter gleich x Alternativen (zB: 4) generieren könnte, ohne jedesmal den BRouter zu beenden und wieder neu zu starten.

Aber ich kann damit leben und das soll nur als eine konstruktive (!!!) Kritik aufgefasst werden.

Für Deine Arbeit nochmals vielennDank
Achim

Habe heute die Version 0.9.5 von BRouter deployed ( http://brensche.de/brouter/revisions.html )

Neben einer allgemeinen Performance-Verbesserung und einer Sonderlocke fürs Car-Routing ("car-subset" files) addressiert das insbesondere das Problem des Timeouts im Service-Interface, und ich nenne das "timeout-free recalculations".

Das alles mit dem Ziel, eine praxistaugliche Lösung für die Langstrecken-Navigation zu schaffen.

Ist im Moment noch bisschen akademisch, weil das Service-Interface ja bisher nur von Oruxmaps unterstützt wird, und Oruxmaps aber keine dynamische Neuberechnung macht, wenn man von der Route abweicht. Locus unterstützt das Service-Interface aber in einer beta-Version auch schon ( http://forum.locusmap.eu/index.php?topi … 4#msg24024 ), und Locus kann dynamisch neu berechnen.

Ich selbst benutze es aber meist mit OsmAnd und einer ziemlich wackeligen Proxy-Strecke, denn OsmAnd selbst kann BRouter noch nicht direkt aufrufen.

Wa jetzt funktoniert ist, bis zu mittleren Distanzen (=30km Luftlinie Fahhrad, 50km Luftlinie Auto) einfach garnicht drüber nachzudenken, sondern einfach das Ziel in's Maptool einzugeben, und bis zu "gewöhnlichen Langstrecken (300km Fahhrad, 500km Auto) die Strecke einmalig über die BRouter-App zu berechnen (was dann 10 Minuten dauern kann), dem dann aber per Zielfürhung mit schnellen automatischen Neuberechnungen nachzufahren.

Aber wie gesagt: interessant wird das, wenn OsmAnd das kann (ich bleib dran..).

Hallo

ich habe mir mit dem BRouter Bundle 0.92 eine Desktopanwendung in Verbindung mit dem GPXCreator zusammengebaut. Das funktioniert eigentlich sehr gut, aber nur für kurze Strecken. Ich finde keine Möglichkeit das "Ende" eines Routingauftrags an BRouter zu erkennen. Nur die Abfrage ob der entsprechende File da ist scheitert, weil dieser vermutlich noch nicht vollständig generiert ist.
Eine Funktion die wartet und das Ende des Routingauftrag signalisiert wäre super.

Gibts dafür eine Lösung oder ein neues Desktop Bundle?

Wird die Dektopvariante (API) weiterhin gepflegt und unterstützt?

Derzeit wird auch im Routconverterforum über eine Integration vom BRouter in Verbindung mit dem Mapsforge-Rewrite diskutiert, dazu sollte aber die obige Funktion realisiert werden können.

Ich habe im Google Forum sinngemäß die gleiche Frage gestellt, da ich erst heute entdeckt habe.

Grüsse Achim

Ps: Ich habe mal das brouter095.jar versucht, analog zu der brouter095.jar Version, aber da wird keine Ausgabe generiert. WindosXP mit Java 1.7
Segmente und Profiles sind geladen.
Gibts für das Main Programm wieder eine Source?

Aufruf:

D:\GPS\BRouter\brouter_0_9_5>java␣-jar␣brouter095.jar␣segments2␣8.774144␣48.914457␣8.821399␣48.913996␣profiles2/trekking.brf
BRouter␣0.95␣/␣01092013␣/␣abrensch

...keine␣weiter␣Ausgabe␣und␣es␣wird␣kein␣GPX␣File␣generiert.....

womisa wrote:

ich habe mir mit dem BRouter Bundle 0.92 eine Desktopanwendung in Verbindung mit dem GPXCreator zusammengebaut. Das funktioniert eigentlich sehr gut, aber nur für kurze Strecken. Ich finde keine Möglichkeit das "Ende" eines Routingauftrags an BRouter zu erkennen. Nur die Abfrage ob der entsprechende File da ist scheitert, weil dieser vermutlich noch nicht vollständig generiert ist.
Eine Funktion die wartet und das Ende des Routingauftrag signalisiert wäre super.

Gibts dafür eine Lösung oder ein neues Desktop Bundle?

Wird die Dektopvariante (API) weiterhin gepflegt und unterstützt?

Hallo Achim,

und sorry, dass ich bisschen "mailfaul" war.

Ja, das ist genau die Idee, dem distribution-zip zukünftig immer auch die Server-Variante als jar-file beizufügen, und in der 0.95 ist's ja drin, nur leider, wie Du ja festgestellt hast, nicht ganz zuende getestet. Und leider auch nicht dokumentiert, die wenige Zeit, die ich letzte Woche hatte, hat einfach nicht gereicht und mein Focus war die Performance und dieser timeout-freie Neuberechnungsmechanismus im Service-Interface, war mir wichtig, aber eine harte Nuss.

Ich habe tatsächlich in 0.95 den asynchronen Aufruf, der Deine Probleme mit dem Abbruchkriterium verursacht, eliminiert (das war ja nur für die Android-App sinnvoll) und durch einen ganz normalen synchronen Aufruf ersetzt. Daher kommt aber der Fehler, den Du unten beschreibst, da fehlt noch eine Anpassung.

Ich bring das heute abend mal in Ordnung und schick Dir dann die passenden Sourcen.

Hallo Arndt,

gibt es schon eine "NEUE" Desktop Version mit dem synchronen Aufruf?

Grüsse Achim

womisa wrote:

gibt es schon eine "NEUE" Desktop Version mit dem synchronen Aufruf?

Ja seit eben gibt es die Version 0.96: http://brensche.de/brouter/revisions.html

Den Source-Code habe ich Dir per Email geschickt.

0.96 beinhaltet im wesentlichen Bugfixes, aber etwas interessantes ist auch dabei für die, die sich für den Algortithmus näher interessieren.

Denn erstens habe ich den bisschen beschrieben: http://brensche.de/brouter/algorithm.html

Und zweitens die "heuristischen Koeffizienten" in die Konfiguration übernommen, sodass man sie ändern kann und damit rumspielen (und z.B. die superschnellen, aber ungenauen Berechnungen herbei-patchen, von denen manche ja glauben, bei OsmAnd, Skobbler, Navit und co. könnten die Entwickler zaubern...)

Und noch was interressantes habe ich: ich hab's geschafft, OsmAnd aus den Sourcen zu bauen (in der Version ohne native Bibliotheken) und da die direkte Schnittstelle zu BRouter reingebaut. Das ganze ist noch schwebend als Pull-Request auf GitHub:

https://github.com/osmandapp/Osmand/pull/537

Aber eine Binär-Version habe ich jetzt einfach mal bei mir hochgeladen:

http://h2096617.stratoserver.net/broute … router.zip

Das ist natürlich Bastelkram, ohne die nativen Libs ist das rendering schon spürbar langsamer, und das APK ist mit dem Debug-Key signiert (man muss also eine release-version erst deinstallieren), und paar Übersetzungen musste ich auch löschen, aber die Verbindung zu BRouter funktioniert tadellos und die automatischen Neuberechnungen (auch bei langen Strecken) machen richtig Freude.

Ich denke, ich bin da mit der GPL-Lizenz von OsmAnd im reinen, habe ja den Source-Code der Änderung als Pull-Request publiziert und das ganze im beliegenden readme.txt beschrieben - wenn's jemand besser weiss wäre ich für einen Hinweis dankbar.

Ich bin guter Hoffnung, dass der Patch in die OsmAnd releases eingeht, Victor ist noch bisschen zickig und will z.B., dass man die Option in OsmAnd nur sieht, wenn BRouter bereits installiert ist, aber das krieg ich hin.

Hallo Arndt,

die neue Version mit dem sychronen Routingaufruf funktioniert jetzt bei mir sehr gut!

Vielen Dank
Achim

abrensch wrote:

Ich bin guter Hoffnung, dass der Patch in die OsmAnd releases eingeht, Victor ist noch bisschen zickig und will z.B., dass man die Option in OsmAnd nur sieht, wenn BRouter bereits installiert ist, aber das krieg ich hin.

Könnte man das nicht einfach als Plugin für OsmAnd machen, oder wäre das zu aufwendig?
Einige Features von OsmAnd sind ja eh schon als Plugin ausgelagert (Parking, Höhenprofil ...).
So wäre man etwas unabhängiger von Victor und seiner OsmAnd-Entwicklung.
Wenn der BRouter sowieso noch extern installiert werden muss, könnte man das gleich
ins Plugin bündeln.

Hallo Arndt,

ich habe mal die 096 Version auf meinem LG P700 mit Android 4.0.3 und auf einem Huawei X3 mit Android 2.3.3 installiert, das läuft soweit mit OruxMaps zusammen.

Mir ist folgendes aufgefallen:

Startet man BRouter und routet from/to kommt am Ende bei der Version 0.95. Man kann also nict erkennen ob die 0.96 installiert ist.

Ferner ist bei der Android 4.0.3 das leidige Problem mit den Pfadangaben. Routet man mit BRouter mit from/to/via1....viax/ werden die Ausgabefiles auf die interne SD Karte abgelegt.

Bei mir zB: /mnt/sdcard/oruxmaps/tracklogs

Erwartet bzw. gewünscht hätte ich mir, dass das auf der externen SD Karte liegt bei mir zB.:

/mnt/sdcard/external_sd/OruxData/tracklogs

da dieses auch das "standard" Direktory für Oruxmaps zum Laden von Tracks und Routen ist.

Ist das im Sinne des Erfinders (Bug oder Feature)?

Grüsse Achim

Zwei Fragen:

1. Gibt es in der Android-App (irgendwie) eine Möglichkeit, sich die aktive Zuordnung zwischen den Profilen und Service-Modes (als Übersicht) anzeigen zu lassen?

2. Gibt es bzw. und wenn ja wie sehen die Planungen in Richtung Sprachunterstützung aus?

Gruß Klaus

toc-rox wrote:

2. Gibt es bzw. und wenn ja wie sehen die Planungen in Richtung Sprachunterstützung aus?
Gruß Klaus

Der BRouter braucht sowieso noch eine Karten-App.
Bei OsmAnd ist die Sprachunterstützung bereits eingebaut.
Die funktioniert auch, wenn die Route nicht vom internen Router berechnet wurde,
sondern als GPX hinzugeladen wird.

Braucht BRouter auch bei der OsmAnd-Integration noch zusätzliches Kartenmaterial
zum Routenberechnen, oder greift der dann direkt auf die OsmAnd-Karten zu?

Eine allgemeine API für Routing-Provider stelle ich mir für Routing-Apps schwierig vor,
weil man ja nicht nur eine Route auf Anfrage zurückgibt (so wie bei Online-Routern),
sondern bei der Berechung auf App-Interna wie das Kartenmaterial zugreifen muss/möchte.
Je nach App haben die Karten auch verschiedene Datenformate.
Es wäre schon unpraktisch, wenn man Kartenmaterial doppelt installieren müsste,
einmal fürs Routing und einmal für die Kartenapp.

Wie ist das mit den Höhen? Könnte man die
Germany_europe_srtm_elevation_contour_lines_2.obf
von OsmAnd nicht für BRouter nutzen? Ist vielleicht schwieriger, weil es
nur die Höhenlinen sind und nicht Höhenrasterdaten wie im STRM-File.

Leider ist meine SD-Karte schon voll. Weitere Karten kann ich nicht mehr installieren.

BRouter hat seine eigenen Routing-Daten in Form von 5°x5° Quadraten, die ca. 250-300MB groß sind. Normalerweise kommt man in seiner weiteren Heimatregion mit 2, maximal 4 davon aus. In Locus kann man mittlerweile für eine geführte Navigation BRouter genauso auswählen wie andere Navigationsdienste. In OSMAND kommt das hoffentlich noch, ein Pull-Request dafür wurde vom Autor jedenfalls gemacht.
Bei OSMAND steht das natürlich in einer gewissen Konkurrenz zum eingebauten Offline-Routing, aber im Vergleich wird speziell das Fahrradrouting in OSMAND eher stiefmütterlich behandelt, Einbahnstraßen mit erlaubter Gegenrichtung werden z.B. immer noch nicht berücksichtigt.

Hi,

hier mal gebündelt Antworten zu den letzten 3 Beiträgen:

womisa wrote:

Ferner ist bei der Android 4.0.3 das leidige Problem mit den Pfadangaben
...da dieses auch das "standard" Direktory für Oruxmaps zum Laden von Tracks und Routen ist.
Ist das im Sinne des Erfinders (Bug oder Feature)?

Ja, also hellsehen kann ich nicht, und der "Sinn des Erfinders" ist tatsächlich, nach der aktuellsten Wegpunkte-Datenbank zu suchen und relativ von da das Tracks-Directory zu vermuten. Wenn in Oruxmaps was anderes konfiguriert ist, komme ich da nicht ran.

Werde aber in der nächsten Version als Workaround eine Weiterleitungs-Mechanismus hizufügen, so dass man dan im "falschen" Zielverzeichnis ein redirect-file ablegen kann, in dem der Pfad zum "richtigen" Zielverzeichnis steht.

toc-rox wrote:

1. Gibt es in der Android-App (irgendwie) eine Möglichkeit, sich die aktive Zuordnung zwischen den Profilen und Service-Modes (als Übersicht) anzeigen zu lassen?

Nein. Aber seit 0.95 liegen diese Konfigurations-Dateien auf der SD-Karte (brouter/modes) so dass man sich die Dateien anschauen könnte, wäre aber bisschen mühselig.

Ich werde in der nächsten Version nach dem Speichern der Service-Konfiguration noch einen Feedback-Dialog nachschalten, in dem die gesamte Konfig als Übersicht gezeigt wird (nur Profil-Name und Zahl der Nogos)

toc-rox wrote:

2. Gibt es bzw. und wenn ja wie sehen die Planungen in Richtung Sprachunterstützung aus?

Meinst Du Mehrsprachigkeit der App oder meinst Du Sprachausgabe?

Nein, die App weiter aufzubohren in Richtung Mehrsprachigkeit hab' ich keine Ambitionen. Deutsche Doku steht aber schon weit oben auf der Liste.

Thema Sprachausgabe ist aber spannend. Wie openzzz schon schreib, macht OsmAnd das ja schon recht ordentlich, aber auch OsmAnd kann zusätzliche Informationen vom Router verwenden, um bessere Ansagen zu machen, und Locus ist ohne solche Infos ziemlich sprachlos, also das ist natüclich Thema, diese Information zu liefern, also Sprach-Hinweise, die nicht nur aus dem Verlauf der Route abeleitet werden ("jetzt rechts"), sondern tatsächlich aud dem Netztwerk ("an der nächsten Kreuzung geradeaus").

"Hemdentaschen-Navigation", also SPrachhinweise, die so gut sind, dass man die Karte nicht mehr braucht, wäre ein coole Sache.

openzzz wrote:

Braucht BRouter auch bei der OsmAnd-Integration noch zusätzliches Kartenmaterial
zum Routenberechnen, oder greift der dann direkt auf die OsmAnd-Karten zu?

Nein, BRouter braucht immer seine eigenen (*.rd5) Dateien

Wie ist das mit den Höhen? Könnte man die Germany_europe_srtm_elevation_contour_lines_2.obf von OsmAnd nicht für BRouter nutzen? Ist vielleicht schwieriger, weil es nur die Höhenlinen sind und nicht Höhenrasterdaten wie im STRM-File.

Nein, mit sowas wird man nicht froh.

openzzz wrote:

Leider ist meine SD-Karte schon voll. Weitere Karten kann ich nicht mehr installieren.

Naja, bei < 1Euro/GB hat der eine oder andere den einen Euro für Deutschland-Abdeckung mit RD5-Files schon übrig.

abrensch wrote:

Naja, bei < 1Euro/GB hat der eine oder andere den einen Euro für Deutschland-Abdeckung mit RD5-Files schon übrig.

Meine 32 GB µSD ist voll. Die 64'er kostet 44€. Kaufe ich erst wenn es unbedingt notwendig ist, also nicht diesen Winter.
Einige Gigabytes gehen schon für die Wikipedia EN+DE drauf. Das ist offline im Urlaub ganz praktisch.
Luftbildkarten und Raster-Topo-Karten schlucken auch recht viel.

Leider brauchen die meisten Routing- und Kartenapps jeweils eigene spezielle Karten.
mapsforge können sich noch Locus und Orux teilen, aber der "MapFactor Navigator" braucht
wieder eigene. OsmAnd hat auch ein eigenes Format.

Ich hatte es schonmal angesprochen: kann man sich nicht irgendwie auf ein Vektorformat einigen,
damit man die Länder nicht doppelt und dreifach installieren muss?
Hat RD5 einen Vorteil gegenüber dem OsmAnd-Kartenformat?
Zumindest ist OsmAnd OpenSource, d.h. das Format und der Code zum Lesen und Schreiben ist publik.
Es gibt auch noch ein PC-Programm für OsmAnd zum Erzeugen der OSM-Karten.
Falls die Unterschiede zu RD5 nicht groß sind könnte man das bestimmt irgendwie verheiraten.
Vor allem brauchst du dann nicht einen eigenen Distributionszweig für RD5-Karten aufbauen.
Die OsmAnd-Karten liegen für viele Länder auf dem Downloadsever bereit (http://new.osmand.net/list.php)

Für die Höhenkarte, Ok, das ist ein anderer Fall. Die Höhenprofilkarte (Höhenlinien) kann man so nicht nehmen.

openzzz wrote:

Hat RD5 einen Vorteil gegenüber dem OsmAnd-Kartenformat?
Zumindest ist OsmAnd OpenSource, d.h. das Format und der Code zum Lesen und Schreiben ist publik.
Es gibt auch noch ein PC-Programm für OsmAnd zum Erzeugen der OSM-Karten.
Falls die Unterschiede zu RD5 nicht groß sind könnte man das bestimmt irgendwie verheiraten.
Vor allem brauchst du dann nicht einen eigenen Distributionszweig für RD5-Karten aufbauen.
Die OsmAnd-Karten liegen für viele Länder auf dem Downloadsever bereit (http://new.osmand.net/list.php)

Naja beim navigieren kommt es immer darauf an, dass die verfügbaren Tags richtig interpretiert und dann gewichtet werden. Beim navigieren kommt es ja nicht immer darauf an den kürzesten zulässigen Weg zu finden. Manchmal möchte man auch den schnellsten/schönsten Weg haben.
Und OSMAND wie auch andere Vektorkarten werten einfach nur den für sie relavanten Teilbereich der Keys aus. Möglicherweise wird dann auch gleich noch ein "Mittelwert" berechnet, um dann nicht die "ganze Arbeit" im Mobildevice zu machen.
Daher wird es schon grundlegende Unterschiede geben. Zumal sich rd5 eben gerade nicht um Darstellbarkeit und aussehen kümmert.

abrensch wrote:

toc-rox wrote:

1. Gibt es in der Android-App (irgendwie) eine Möglichkeit, sich die aktive Zuordnung zwischen den Profilen und Service-Modes (als Übersicht) anzeigen zu lassen?

Nein. Aber seit 0.95 liegen diese Konfigurations-Dateien auf der SD-Karte (brouter/modes) so dass man sich die Dateien anschauen könnte, wäre aber bisschen mühselig.
Ich werde in der nächsten Version nach dem Speichern der Service-Konfiguration noch einen Feedback-Dialog nachschalten, in dem die gesamte Konfig als Übersicht gezeigt wird (nur Profil-Name und Zahl der Nogos)

toc-rox wrote:

2. Gibt es bzw. und wenn ja wie sehen die Planungen in Richtung Sprachunterstützung aus?

Meinst Du Mehrsprachigkeit der App oder meinst Du Sprachausgabe?
Nein, die App weiter aufzubohren in Richtung Mehrsprachigkeit hab' ich keine Ambitionen. Deutsche Doku steht aber schon weit oben auf der Liste.
Thema Sprachausgabe ist aber spannend.  Wie openzzz schon schreib, macht OsmAnd das ja schon recht ordentlich, aber auch OsmAnd kann zusätzliche Informationen vom Router verwenden, um bessere Ansagen zu machen, und Locus ist ohne solche Infos ziemlich sprachlos, also das ist natüclich Thema, diese Information zu liefern, also Sprach-Hinweise, die nicht nur aus dem Verlauf der Route abeleitet werden ("jetzt rechts"), sondern tatsächlich aud dem Netztwerk ("an der nächsten Kreuzung geradeaus").
"Hemdentaschen-Navigation", also SPrachhinweise, die so gut sind, dass man die Karte nicht mehr braucht, wäre ein coole Sache.

Zu 1: Unterstützung in der nächsten Android-App ... das hört sich gut an. In welche Datei müßte man, bis es soweit ist, denn reinschauen?

Zu 2: Ja, ich meinte die Ausgabe von Sprachtexten während der Streckenführung. Du hast es aber auf den Punkt gebracht: "Hemdentaschen-Navigation, also Sprachhinweise, die so gut sind, dass man die Karte nicht mehr braucht, wäre ein coole Sache."

Ich übernehme deine Antworten (in den nächsten Tagen) mal ins Locus-Forum: http://forum.locusmap.eu/index.php?board=27.0 Die User dort sind zwar nicht so viele, aber sehr bemüht die Dinge weiter zu entwickeln.

Gruß Klaus

PS: Vielleicht hast du aber Lust dich im Locus-Forum selbst zu äußern ...

viw wrote:

Naja beim navigieren kommt es immer darauf an, dass die verfügbaren Tags richtig interpretiert und dann gewichtet werden. Beim navigieren kommt es ja nicht immer darauf an den kürzesten zulässigen Weg zu finden. Manchmal möchte man auch den schnellsten/schönsten Weg haben.
Und OSMAND wie auch andere Vektorkarten werten einfach nur den für sie relavanten Teilbereich der Keys aus. Möglicherweise wird dann auch gleich noch ein "Mittelwert" berechnet, um dann nicht die "ganze Arbeit" im Mobildevice zu machen.
Daher wird es schon grundlegende Unterschiede geben. Zumal sich rd5 eben gerade nicht um Darstellbarkeit und aussehen kümmert.

Das Wegenetz (die ganzen Knoten und Polygonzüge/Koordinatenlisten) braucht man aber für beide Zwecke. Es stehen noch ein paar Infos zur Berechnung der Pfadmetrik drin, und die Verknüpfungen der Wege, aber eigentlich lässt sich das gut verheiraten. Mit einer Datenbankstruktur (sqlite-File?) incl. Index ist auch der Datenzugriff relativ flott. Auch für eine routingfähige Display-Karte kann man viele Keys weglassen oder effektiver speichern.

Die Trennung ist natürlich dann praktisch, wenn BRouter für andere Apps als OsmAnd routet und deren Karten nicht routingfähig sind. Als OsmAnd-Plugin wäre es aber schon praktisch wenn es die vorhandenen routingfähigen Karten nutzen könnte. Die muss man sich vor einem Urlaub sorgfältig zusammenstellen, damit alles auf die SD-Karte passt. Europa gesamt wäre schon heftig. OSM hat eben viel mehr Details in der Karte als bei den kommerziellen Routing-Lösungen.

Gibt es bei den Entwicklern Interesse, einen gemeinsamen Standard für routingfähige Vektorkarten zu formulieren? So wie bei mapsforge für die nicht routingfähigen? Wäre das OsmAnd-Kartenformat ein guter Einstieg,?

Schau dir einfach mal die Diskussion zu Graphhopper an. Dort stoßen verschiedene Theorien aufeinander.

viw wrote:

Schau dir einfach mal die Diskussion zu Graphhopper an. Dort stoßen verschiedene Theorien aufeinander.

Graphhopper benutzt laut Infoseite schnellere Varianten des Dijkstra
mit vorausberechneten Daten.

Die Dateigrößen der rd5 sind ja doch recht kompakt.
Na, vielleicht passt das dann doch nicht so recht zusammen.
Man müsste schon im Detail die Datenstrukturen vergleichen.
Vielleicht hat auch OsmAnd einen kompaktierten Datensatz für das Routing
drin, der lediglich aus den Knoten und Verbindungsmetriken besteht.

Ich verstehe euer Problem: je besser sich BRouter in OsmAnd integriert
desto schwieriger wird die Unterstützung für andere Kartenapps.
Mein Favorit wäre natürlich eine Totalintegration in OsmAnd, so dass
alle dortigen Vorzüge genutzt werden, die Kartenbasis und die Möglichkeit
des Routen-Neuberechnens.

Gerade das ist mir unterwegs auf dem Rad wichtig, da ich immer wieder
mit Absicht von der Route abweiche, und vom Router verlange, dass
er das gleich berücksichtigt, ohne anzuhalten und am Gerät herumfummeln zu müssen.

Ich weiss nicht, ob die anderen Apps dafür die Voraussetzungen mitbringen.
Jedenfalls ist eine OsmAnd-Integration einfacher, weil der Sourcecode frei ist.

Jetzt fehlt nur noch das schöne Wetter zum Testen.
Als die Sonne geschienen hatte musste ich noch im Büro sitzen ...

OsmAnd und Brouter ... ob das eine Erfolgsgeschichte wird bzw. werden kann?
M.E. eher nicht ... Zuviele Köche verderben den Brei.

Gruß Klaus

Hallo Brouter Gemeinde,

ich hab mal "just for fun" den BRouter in einen Desktop-MapsforgeViewer eingebaut. Das GANZE ist "gefrickelt" und in einer frühen Beta Phase. Aber das funktioniert erschreckend gut. Ich habe als Ziel, dass ich auf einem Windows PC meine "Fahrradrouten" und "Wanderrouten" planen kann. Was mir besonders gefällt ist, dass im BRouter "vernüftige" alternative Routen berechnet werden, zumindest soweit ich das beurteilen kann.
Ich hoffe, dass BRouter nicht nur in Richtung OSMAND geht und die "Desktop-Schnittstellen" erhalten bleiben und weiterentwickelt werden. Das ist eine persönliche BITTE an Arndt.

Arbeitet daran noch jemand (Thema:Desktop-Mapsforge-Router)?

In diesem Sinne
Achim

Ps: An die Grashopper-Kenner...wie kann man Grashopper in eine DesktopAnwendung einbinden? Keine ServerVersion sondern über eine entsprechende API-Schnittstellle like BROUTER?

toc-rox wrote:

OsmAnd und Brouter ... ob das eine Erfolgsgeschichte wird bzw. werden kann?
M.E. eher nicht ... Zuviele Köche verderben den Brei.
Gruß Klaus

Zwei Meister ihres Fachs. OsmAnd hat die Kartenapp und einen mittelmäßigen Router. Brouter hat den besten Router (to be field tested), aber mangelt es an einer Karten-App. Beide ergänzen sich gut.

Welche Alternativen gibt es? OsmAnd ist die einzige gute Karten-App, die als OpenSource publiziert wird.
Ich finde auch wesentlich besser als Orux und Locus (Wikipedia-POI mit Kurztexten, Offline-Suche in POIs, Einblenden der POI,
vor allem Routing an POI-Ziele, Routing entlang GPX-Strecke, Auto/Rad/Fußgänger-Profile, Offline-Routing).
Die Waypoint-Verwaltung ist vielleicht bei anderen besser ausgereift,
aber über Favoriten doch noch machbar.

Nur wenn man als Radfahrer in der Nacht Routing-Unterstützung braucht und das dumme Teil dann
über die Gipfel steigen will, mangels Höheninformation, dann merkt man, dass noch etwa fehlt.

womisa wrote:

Ich hoffe, dass BRouter nicht nur in Richtung OSMAND geht und die "Desktop-Schnittstellen" erhalten bleiben und weiterentwickelt werden. Das ist eine persönliche BITTE an Arndt.

Und für Locus und Orux nicht vergessen, denen fehlt ja auch das Offline-Routing.

openzzz wrote:

womisa wrote:

Ich hoffe, dass BRouter nicht nur in Richtung OSMAND geht und die "Desktop-Schnittstellen" erhalten bleiben und weiterentwickelt werden. Das ist eine persönliche BITTE an Arndt.

Und für Locus und Orux nicht vergessen, denen fehlt ja auch das Offline-Routing.

...das verstehe ich nun nicht! Oruxmaps kann doch in Verbindung mit BRouter "Offline-Routing, oder habe ich da was falsch verstanden? Ich nutze das ständig.

womisa wrote:

Ps: An die Grashopper-Kenner...wie kann man Grashopper in eine DesktopAnwendung einbinden? Keine ServerVersion sondern über eine entsprechende API-Schnittstellle like BROUTER?

BRouter ist doch auch eine Art Server. Was also spricht dagegen den Graphhopper als Server zu starten und dann anzusprechen?

openzzz wrote:

Zwei Meister ihres Fachs. OsmAnd hat die Kartenapp und einen mittelmäßigen Router. Brouter hat den besten Router (to be field tested), aber mangelt es an einer Karten-App. Beide ergänzen sich gut.

Also BROUTER hat eine entscheidende Schwäche. Er kann gut Fahrradrouting und vielleicht auch für Wanderer. OSMAND hat aber auch Autofahrer als Ziel. von ÖPNV wollen wir mal gar nicht reden. Das macht wahrscheinlich derzeit noch keine offline App.

womisa wrote:

...das verstehe ich nun nicht! Oruxmaps kann doch in Verbindung mit BRouter "Offline-Routing, oder habe ich da was falsch verstanden? Ich nutze das ständig.

Meinte ich ja. Ohne BRouter würden die beiden ohne Offline-Routing-Lösung dastehen. OsmAnd hat schon eine eingebaut, mit Sprachansage. BRouter wäre nur eine Verbesserung der Routingfunktionalität für Radfahrer.

openzzz wrote:

Das Wegenetz (die ganzen Knoten und Polygonzüge/Koordinatenlisten) braucht man aber für beide Zwecke. Es stehen noch ein paar Infos zur Berechnung der Pfadmetrik drin, und die Verknüpfungen der Wege, aber eigentlich lässt sich das gut verheiraten. Mit einer Datenbankstruktur (sqlite-File?) incl. Index ist auch der Datenzugriff relativ flott. Auch für eine routingfähige Display-Karte kann man viele Keys weglassen oder effektiver speichern.

Das rd5-format ist ziemlich simpel aufgebaut:

- Koordinatensystem ist "Mikrograd positiv"

- keine NodeId's, sondern stattdessen "unifizierte Geo-IDs", also 64-Bit Zahlen aus lat-lon,
die ggf. um jeweils ein oder wenige Mikrograd verschoben wurden, um die Geo-ID eindeutig zu
machen damit sie als Schlüssel taugt.

Dreistufiger Index:

- eine Datei startet mit dem topevel-index (25*8=200 bytes) mit den start-offsets von
25 1*1 Grad Unterdateien

- eine Unterdatei startet mit dem index von 80*80*4 = 25600 bytes mit den start-offsets
von 1/80 * 1/80 Grad Kacheln

- jede dieser Kacheln enthält die Knoten sortiert nach Geo-ID, sodass ein Knoten darin
über eine binäre Suche effizient gefunden werden kann

- jeder Knoten codiert Geo-ID, Höhe, Node-Description Bitmap (64 bit) und dann die Liste der "Links"

- jeder Link codiert die Geo-ID des Target-Knoten, und dann entweder:
- die Way-Description-Bitmap (64 bit) und ggf. noch eine Liste von
"Transfer-Knoten" (mit jeweils Geo-ID und Höhe)
- oder ein Flag, dass anzeigt, dass der "Gegen-Link" am Zielknoten die Weg-Details codiert

- das ganze noch mit bisschen Pseudo-Kompression, um lat/lons ggf in 16 bit zu kodieren relativ zu irgendeinem
offset

Da fehlt schon einiges. Insbesondere die 64-Bit "Description-Bitmaps", die die OSM Tags gemaess
der "lookup.dat" Tabelle codieren, sind eine Limitierung für die Zahl der Tags, und insbesondere
der Relationen, die man da rein codieren kann, und hier müsste ein "ordentlich entwickeltes"
Format dynamischer sein (aber eben trotzdem schnell, also nicht einfach die OSM-Tags als
Text da rein schreiben...)

Gibt es bei den Entwicklern Interesse, einen gemeinsamen Standard für routingfähige Vektorkarten zu formulieren? So wie bei mapsforge für die nicht routingfähigen? Wäre das OsmAnd-Kartenformat ein guter Einstieg,?

In OsmAnds obf oder mapsforge steht schon deutlich mehr drin, und sie sind auch kompakter, also müsste eine Neuentwicklung zweifellos auf diesen Erfahrungen aufbauen. Aber ein routingfähiges Format, was (fast) keine OSM Daten wegwirft wäre schon ein interessantes Projekt.

abrensch wrote:

In OsmAnds obf oder mapsforge steht schon deutlich mehr drin, und sie sind auch kompakter, also müsste eine Neuentwicklung zweifellos auf diesen Erfahrungen aufbauen. Aber ein routingfähiges Format, was (fast) keine OSM Daten wegwirft wäre schon ein interessantes Projekt.

Du kannst das OsmAnd obf Format gerne erweitern, wenn du mehr Tags verarbeiten willst (Straßenbelagsqualität?).
Wenn das Sinn macht ist sicher auch Victor zu Änderungen bereit.
Ist halt praktischer und weniger Arbeit, auf etwas Existierendes aufzubauen.
Datenreduktion an sich halte ich schon für wichtig, um die Kartengröße noch erträglich zu halten.
Wenn da erstmal alle Straßenlaternen gemappt werden, würde es den Datensatz nur unnötig aufblähen.

Natürlich sind auf den Zweck minimierte Datenformate effizienter, aber ist die Frage ob das beim Routing so entscheidend ist.
Die meiste Zeit bei OsmAnd vergeht beim Rendern der Vektorkarte. Die Routenneuberechnung läuft nur sporadisch ab.
Ob man dann eine Sekunde mehr oder weniger warten muss spielt in der Praxis keine Rolle.

viw wrote:

womisa wrote:

Ps: An die Grashopper-Kenner...wie kann man Grashopper in eine DesktopAnwendung einbinden? Keine ServerVersion sondern über eine entsprechende API-Schnittstellle like BROUTER?

BRouter ist doch auch eine Art Server. Was also spricht dagegen den Graphhopper als Server zu starten und dann anzusprechen?

..das ist richtig, man kann den BRouter auch als Server benutzen. Das mache ich aber nicht! Wie man ja bei Oruxmaps gesehen hat, ist das Handling von zwei Programmen nicht immer problemlos zu handhaben. Dort haben erst die Intents eine spürbare Vereinfachung gebracht.

Ich rufe bei mir den BRouter nicht via Serverkommunikation auf, sondern rufe die Routingfunktion der Library direkt, unter Umgehung der Serverfunktion, auf. Also nichts mit BRouter-Server starten und dann Programm starten...und irgendwas hängt! BRouter ist somit fester Bestandteil meines Programmes und völlig transparent.
Ich hätte eben gerne eine Library (JAR) in der ich die entsprechenden Funktionen aufrufen kann, unter Umgehung des Servers.

womisa wrote:

Ps: An die Grashopper-Kenner...wie kann man Grashopper in eine DesktopAnwendung einbinden? Keine ServerVersion sondern über eine entsprechende API-Schnittstellle like BROUTER?

Man kann die Graphhopper-API jederzeit direkt ansprechen. Der Webserver ist da nur zusätzlich oben drauf gebaut.

In einer Java-Applikation kann man direkt ein Graphhopper-Objekt anlegen und benutzen.

bye, Nop

PS: Wenn Du in dieser Richtung weiterdiskutieren willst schlage ich ein eigenes Thema vor, hier geht es um BRouter, nicht um Graphhopper.

openzzz wrote:

Natürlich sind auf den Zweck minimierte Datenformate effizienter, aber ist die Frage ob das beim Routing so entscheidend ist.
Die meiste Zeit bei OsmAnd vergeht beim Rendern der Vektorkarte. Die Routenneuberechnung läuft nur sporadisch ab.
Ob man dann eine Sekunde mehr oder weniger warten muss spielt in der Praxis keine Rolle.

Ja doch, es ist entscheidend. Das ist schliesslich der Grund für den "Routing-Zoo" bei OsmAnd aus Java/C++, "precise" oder nicht.

BRouter findet hauptsaechlich deshalb bessere Ergebnisse als OsmAnd-offline, weil er mehr Knoten in der selben Zeit rechnen kann. Und auch die Precise-Alpha Version in OsmAnd rechnet weniger Knoten, weil seine Kostenfunktion in der "routing.xml" eine geringere "Spreizung" (=durchschnittliches Verhältnis Kosten zu Luftlinie, bzw. andersrum in OsmAnds inverser maxspeed-logik) hat als man das vernünftigerweise einstellen würde.

Diese Spreizung bestimmt beim A*-Algortithmus direkt die seitliche Ausdehnung der Elipse des Suchgebiets und damit die Zahl der Knoten, und solange es da eine Rückkopplung gibt zwischen der Definition der Kostenfunktion und technischen Randbedingungen ist das Ergebnis ja auch dann nicht optimal, wenn es aus algorithmischer Sicht präzise ist, also tatsächlich das Kostenminimum gemaess der Kostenfunktion findet.

Und der Höhenterm bei BRouter erhöht die Spreizung zusäzlich, was ja auch anschaulich klar ist, weil wenn man in der Lage sein will, einen Berg zu umfahren, muss man ggf. auch ziemlich weit links oder rechts das rettende Tal suchen, und das alles geht eben nur, wenn man die Knoten genügend schnell durch die Routing-Maschine jagen kann (Oder eben Contraction-Hirachies vorberechnet ala Graphhopper oder OSRM).

womisa wrote:

Arbeitet daran noch jemand (Thema:Desktop-Mapsforge-Router)?

Nicht mit Mapsforge, aber ich bin - wie schon länger geplant - an einem Web-Client dran. Vorerst mal nur in Kombination einem Standalone-Server für den Desktop. Die entsprechende Schnittstellen-Erweiterung ist bereits im brouter.jar. Ich habe vor, demnächst mal eine erste Alpha Version zu veröffentlichen.

Überschneidungen gibt es bei unseren beiden Ansätzen aber vermutlich nicht.

Gruß,
Norbert

abrensch wrote:

Ja doch, es ist entscheidend. Das ist schliesslich der Grund für den "Routing-Zoo" bei OsmAnd aus Java/C++, "precise" oder nicht.

Ich denke das war gar keine so schlechte Idee mit dem Java/C++ Mix. C++ muss leider relativ Prozessorspezifisch kompiliert werden, so dass es einige Android-Geräte gibt auf denen das nicht läuft (z.B. x86 Tablets). In Sachen Plattformunabhängigkeit des Binärcodes ist Java natürlich Spitze.

Aber Java ist auch i.d.R. langsamer als C++. Oft merkt man es nicht, aber oft eben doch. JIT kann helfen, aber es löst nicht alle Probleme. Schutzfunktionen, z.B. Bereichsprüfung beim Array, ist ja ganz nett, aber kostet Zeit. Ohne Prüfung riskiert man Abstürze, aber die Zugriffe sind dann auch locker doppelt so schnell. Das macht man durchaus wenn man selbst dafür sorgt, dass die Grenzen eingehalten werden. C/C++ kann man deutlich maschinennäher und damit schneller ausnutzen. Automatische Garbage Collection ist praktisch, aber auch nicht immer gut für die Performance. Ich vermute auch die Argumentübergabe in Java ist langsamer. In C/C++ kann man fast alles Überflüssige wegoptimieren, sogar den Funktionsoverhead selbst (inline).

Victor wollte sogar alles komplett auf C++ umstellen.

Ich hatte mal aus Versehen beim Verlinken die native Library-Apps getrasht. OsmAnd hat dann auf Java-Only umgeschaltet. War ganz schön lahm im Vergleich. Vor allem beim Kartenaufbau der Vektorkarten.

abrensch wrote:

BRouter findet hauptsaechlich deshalb bessere Ergebnisse als OsmAnd-offline, weil er mehr Knoten in der selben Zeit rechnen kann. Und auch die Precise-Alpha Version in OsmAnd rechnet weniger Knoten, weil seine Kostenfunktion in der "routing.xml" eine geringere "Spreizung" (=durchschnittliches Verhältnis Kosten zu Luftlinie, bzw. andersrum in OsmAnds inverser maxspeed-logik) hat als man das vernünftigerweise einstellen würde.

Sicher? Ich hatte gehört, dass der Speichermangel das größte Problem wäre. Ist es nicht auch bei Android so, dass wenn das RAM nicht reicht, Speicherseiten auf die SD-Karte geswappt werden? Das wäre dann natürlich superlangsam. RAM ist auf meinem Billig-Samsung recht knapp. Ich habe es noch nicht auf großen Smartphones getestet.

Ich bin kein Router Experte. Aber ich dachte der große Vorteil von BRouter wäre seine Konfigurierbarkeit und die Nutzung des Höhenprofils für die Metrik. Ich hatte nicht den Eindruck, dass OsmAnd zu viele Umwege mangels Optimierung liefert. Probleme hatte ich vor allem da gesehen, wo OsmAnd einfach andere Prioritäten setzt. OsmAnd bevorzugt Fahrradwege entlang viel befahrener Straßen. Kann man machen für die Rennradler unter uns, für sie eine gute Metrik. Ich möchte aber Ruhe und fahre bevorzugt Feldwege und noch lieber Waldwege. Aber wer berücksichtigt den Waldanteil? Ehrlich gesagt hat mir bisher noch kein Router zuverlässig aus meiner Sicht attraktive Routen geliefert. Ich priorisiere auch keine Fernradwege, wenn es ruhigere Alternativen im Wald gibt. Hoch im Kurs stehen bei mir Fluss- und Bachläufe, Mischwald, Fernsicht auf Höhenwegen etc.

Einen Nutzen erhoffte ich mir vom OsmAnd-Routing einmal als es im Wald stockdunkel war, kein Mondlicht, keine Orientierung. Die starke LED-Lampe hatte ich vergessen, konnte dann nicht einmal die Radwegebeschilderung ablesen. Ich dachte, Ok, OsmAnd führt dich nach Hause. Leider wollte es wieder zurück über die Berggipfel. Sehr lustig. Also habe ich dann versucht, mich an der Kartenpeepshow am Handy zu orientieren. Das Display ist leider zu klein, um in der Landschaft einen guten Überblick über das Wegenetz zu bekommen. So hatte ich OsmAnd auch manchmal nur unterstützend zum Routing herangezogen, weil ich keine Papierkarte dabei hatte. Naja, Routing für das Fahrrad ist schon eine sehr komplexe Materie. Da gibt es mehr zu Diskutieren als beim Automobil-Routing.

openzzz wrote:

Aber Java ist auch i.d.R. langsamer als C++.

Diese Annahme ist etwa 10 Jahre veraltet. Sieh z.B. die Benchmarks hier: http://scribblethink.org/Computer/javaCbenchmark.html

Es ist aber in Java zugegebenermaßen leichter, durch ungeschicktes Zusammenstecken der bereitgestellten Klassen ein schlechtes und langsames Programm zu schreiben.

Beispiele für extrem schnelles Java sind z.B. Graphhopper, die IDE IntelliJ oder Star Wolves, ein Spiel a la Homeworld mit 3D Vektorgrafik.

bye, Nop

openzzz wrote:

Ist es nicht auch bei Android so, dass wenn das RAM nicht reicht, Speicherseiten auf die SD-Karte geswappt werden?

Nur wenn die SD-Karte eine Swap-Partition hat und diese aktiviert ist (also wie bei einen normalen Linux). Dafür muss man allerdings fast immer das Gerät erst rooten…

openzzz wrote:

OsmAnd bevorzugt Fahrradwege entlang viel befahrener Straßen. Kann man machen für die Rennradler unter uns

Rennrad-Fahrer bevorzugen vermutlich eher radwegfreie Strassen, aber das ist ein anderes Thema…

Nop wrote:

openzzz wrote:

Aber Java ist auch i.d.R. langsamer als C++.

Diese Annahme ist etwa 10 Jahre veraltet. Sieh z.B. die Benchmarks hier: http://scribblethink.org/Computer/javaCbenchmark.html

Nein, gilt eigentlich immer noch, auch wenn die VMs besser geworden sind.

"There are lies, damn lies and Benchmarks"
http://www.freewebs.com/godaves/javabench_revisited/

Bei NestedLoop ist C++ dort 50x so schnell, aber auch sonst
bis auf eine Ausnahme immer führend.

Sicherlich gibt es auch flotte Java-Programme. Manchmal überraschend schnell.
OsmAnd fand ich aber extrem langsam, wenn es mangels Native-Libraries
auf Java zurückfällt.

In C lässt sich eben der Prozessor am besten kontrollieren, fast wie in Assembler.
Auch die neuen Prozessor-Features sind über Intrinsics bzw. Inline-Assembler ohne
Overhead nutzbar (SSE, AVX). Wichtig ist das in der schnellen Signalverarbeitung.

openzzz wrote:

Nop wrote:

openzzz wrote:

Aber Java ist auch i.d.R. langsamer als C++.

Diese Annahme ist etwa 10 Jahre veraltet. Sieh z.B. die Benchmarks hier: http://scribblethink.org/Computer/javaCbenchmark.html

Nein, gilt eigentlich immer noch, auch wenn die VMs besser geworden sind.

"There are lies, damn lies and Benchmarks"
http://www.freewebs.com/godaves/javabench_revisited/

Bei NestedLoop ist C++ dort 50x so schnell, aber auch sonst
bis auf eine Ausnahme immer führend.

Du solltest nochmal aufmerksam lesen in dem Test lese ich sun Java 1.4 und 1.5
zu Java 1.4: http://www.oracle.com/technetwork/java/ … 38567.html
und Java 1.5 entspricht wohl Java 5 welches laut Wikipedia auch schon im Jahr 2004 das Licht der Welt erblickte:
http://de.wikipedia.org/wiki/Java-Techn … ersion_5.0

Das entspricht dann in etwa den 10 Jahren die Nop hier ansprach.
Ach wenn man ganz ans Ende scrollt sieht man ja auch das Jahr 2004. Übrigens wenn du genau schaust unterscheiden sich g++ und Intel und es gibt Disziplinen das ist Java beiden überlegen.

openzzz wrote:

Aber ich dachte der große Vorteil von BRouter wäre seine Konfigurierbarkeit und die Nutzung des Höhenprofils für die Metrik. Ich hatte nicht den Eindruck, dass OsmAnd zu viele Umwege mangels Optimierung liefert.

Wenn Du 2km zum Bäcker fährst merkst Du das normalerweise auch nicht, aber bei längeren Strecken siehst Du schon den Effekt zwischen OsmAnds "ab durch die Mitte" und BRouters "vielleicht doch besser aussen rum". Obwohl ich auch bei kurzen Strecken bei OsmAnd offline oft Effekte sehe, wo man sich denkt, warum, jetzt dieser Zacken durch die Wohngebiete, der direkte Weg geht eindeutig da lang.

Zu der C++ <-> Java Diskussion, Die du da angestossen hast, äussere ich mich nicht als jemand, der mit Java sein Geld verdient, weil die Diskussion ist einfach sinnlos, in der Praxis machen die Daten-Modelle und die Algorithmen den Unterschied, die Technologie kann das nicht reissen, und insofern ist Victors Ansatz mit den nativen libs aus meiner Sicht ein Irrweg.

Nahmd,

abrensch wrote:

[…]die Diskussion ist einfach sinnlos, in der Praxis machen die Daten-Modelle und die Algorithmen den Unterschied, die Technologie kann das nicht reissen, […]

Danke, oder auf neudeutsch: +1

Du hast mir die Worte aus dem Mund genommen.

Gruß Wolf

Frei nach Churchill: Ich glaube nur den Benchmarks, die ich selber gefälscht habe.
Es lassen sich immer Probleme finden, die sich mit einer Sprache besser lösen lassen wie in einer anderen.
Auf die Spitze treiben das die Grafikkarten-Hersteller, die den Micrcode für ihre Grafikprozessoren auf die momentan gängigen Benchmarks hin optimieren, auch wenn das im Normalbetrieb eher Nachteile bringt.

Generell ist Java eine interpretierte, C/C++ eine compilierte Sprache. Daher rührten die Laufzeitunterschiede zu Beginn vor allem her. Heute gibt es JIT-Compiler zu Java, die den Code zur Laufzeit zumindest lokal auch optimieren können. Da der meiste Rechenaufwand üblicherweise in engen Schleifen verbraten wird, hat sich der Unterschied damit drastisch verringert.
Global kann aber nur eine compilierte Sprache optimieren. Welchen Anteil das an der Rechenzeit hat und ob der C++-Compiler das auch tut, ist wieder eine andere Frage.
Wenn es um Bitfieseleien geht, ist Java klar unterlegen (dafür wurde es aber auch nicht entworfen).

Die meiste Zeit drehen die üblichen Anwendungen aber sowieso Däumchen und warten auf eine Reaktion des Benutzers. Der kann dann auch nicht unterscheiden, ob die Reaktion auf einen Klick in einer Hunderstel oder Tausendstel Sekunde erfolgt.

Zusatz: Einen lausigen Algorithmus rettet auch eine "schnellere" Sprache nicht. Beim selben Algorithmus kann es aber sehr wohl Unterschiede geben. Ob die aber so groß sind, dass sich der erheblich größere Aufwand für eine "Mischtechnologie" (Einbinden von native code) lohnt, ist fraglich.
Am schnellsten wäre sicher Assembler, aber das tut sich doch wohl keiner an.

Nop hatte halt den 2004er Benchmark zitiert, und der "revisited" Benchmark war die Antwort darauf.

Es ist halt schwierig mit Benchmarks zu argumentieren. In der Praxis kommt es noch auf viele andere Dinge an.
Der Android-Kernel ist nicht umsonst in C geschrieben. Jede Sprache hat eben so ihre Anwendungsdomäne.
Java ist für bestimmte Anwendungen auch gut geeignet, z.B. da wo es auf Betriebssicherheit ankommt.
Mit C sind viele systemnahe Tricks möglich, wird gerne mit Pointern operiert und der Speicher selbst
verwaltet. Das ist gut für die Performance (wenn man es richtig macht), birgt aber das Risiko bösartiger
Crashes. Man kann in C++ auch gut ohne Pointer sauber programmieren.
Es lässt einem die totale Freiheit, entweder systemnah mit Assembler-Inlines, Intrinsics
für SSE/AVX, oder ganz abstrakt mit Objekten und Templates.

Schön in C++ ist das Overloading der mathematischen Operatoren + - *, so dass man auch
mit komplexen Zahlen, Matrizen und Vektoren einfach rechnen kann. Komplizierte Formeln
sehen dann im Programmcode so übersichtlich aus wie im Lehrbuch. Der Code wird dadurch sehr
viel leserlicher als in Java oder C. Das hat mich bisher davon abgehalten, auf Java oder Python
umzusteigen, obwohl die natürlich auch viele Vorteile bieten.
Früher waren sie immer bei ihrer mächtigen Systembibliothek überlegen. Mit
BOOST hat C++ mittlerweile gut aufgeholt. Das ist schon eine sehr komfortable
Unterstützung für viele Dinge, die man früher noch mühsam selbst programmieren musste.

Aber natürlich kann der beste Compiler oder die beste Sprache nicht helfen, wenn der
Algorithmus oder die Programmlogik nicht optimiert wird.
Das wichtigste Optimierungsorgan ist immer noch das Gehirn des Programmierers.

openzzz wrote:

Der Android-Kernel ist nicht umsonst in C geschrieben.

Meinst du damit den Linux-Kernel? Klar ist der nicht in Java geschrieben, weil es Java damals noch nicht gab (1991 vs. 1995). Ausserdem bräuchte man für eine Java-VM erstmal ein Betriebssystem darunter…
Oder meinst du Dalvik? Die lässt sich auch schlecht in Java schreiben, weil sie notwendig ist um Java-Anwendungen auszuführen. Wenn sie selbst eine Java-VM bräuchte bräuchte man sie ja nicht mehr.

Und ob C++, C, Java, Assembler oder Brainfuck "lesbarer" ist hängt ja wohl von den Wünschen des Lesenden ab.

BTT: Könnte jemand dazu eine Seite im OSM-Wiki mit ein paar Infos und einer Kurzanleitung anlegen?

seichter wrote:

Zusatz: Einen lausigen Algorithmus rettet auch eine "schnellere" Sprache nicht. Beim selben Algorithmus kann es aber sehr wohl Unterschiede geben. Ob die aber so groß sind, dass sich der erheblich größere Aufwand für eine "Mischtechnologie" (Einbinden von native code) lohnt, ist fraglich.
Am schnellsten wäre sicher Assembler, aber das tut sich doch wohl keiner an.

Dann probiere OsmAnd mal ohne die native Libs. Bei mir lief das elendig langsam.

Warum kein Assembler? In C++ kannst du in einer Hochsprache schreiben und für ein paar kritische
Dinge Inline-Assembler einschieben. Hab ich schon öfters gemacht. Nur so lassen sich inkompatible
Aufrufkonventionen fremder C++ DLLs handhaben. Besonders aufwendig ist das auch nicht.
Einige Bitschubsereien sind in Hochsprachen extrem ineffizient, selbst in C.
Außerdem, wozu hat man so tolle Prozessoren mit AVX und SSE-Vektoreinheiten, wenn
man sie brach liegen lässt? Was meinst du was da für Speedups verschenkt werden.
Das ist locker mal Faktor 10-20 drin für die schnelle Bildverarbeitung.
In C++ lässt sich das ad-hoc mit intrinsic functions einbetten. Die Möglichkeiten bietet Java nicht.

rayquaza wrote:

Meinst du damit den Linux-Kernel? Klar ist der nicht in Java geschrieben, weil es Java damals noch nicht gab (1991 vs. 1995). Ausserdem bräuchte man für eine Java-VM erstmal ein Betriebssystem darunter…

Nein, es geht auch ohne VM:
http://de.wikipedia.org/wiki/Java-Prozessor

Aber ich denke auch heute würde man den Kernel wieder in C schreiben, einfach weil die Sprache
dafür wie geschaffen ist. Es geht teilweise um sehr harte Echtzeitanforderungen, volle Kontrolle
über Speicher und System, Inline-Assembler. Womit soll denn das sonst gehen?

Wenn auf einen System-Interrupt in wenigen Taktzyklen geantwortet werden soll,
kann eine VM nicht zwischendurch gemütlich noch eine Garbage Collection machen.

So, ich glaube wird sind jetzt zu off-topic ... für BRouter ist Java natürlich eine exzellente Wahl 🙂

abrensch wrote:

Wenn Du 2km zum Bäcker fährst merkst Du das normalerweise auch nicht, aber bei längeren Strecken siehst Du schon den Effekt zwischen OsmAnds "ab durch die Mitte" und BRouters "vielleicht doch besser aussen rum". Obwohl ich auch bei kurzen Strecken bei OsmAnd offline oft Effekte sehe, wo man sich denkt, warum, jetzt dieser Zacken durch die Wohngebiete, der direkte Weg geht eindeutig da lang.

Zugegeben, auf längeren Touren (z.B. 70 km), habe ich noch keinen automatischen Router benutzt. Da stecken einfach zu viele persönliche Vorlieben drin, die eine Software nicht kennt und auch schlecht durch OSM-Tags ausgedrückt werden können. Nicht zu vergessen in der Routing-Metrik sind auch die Einkehrmöglichkeiten. Bisher hat mich noch keine Routing-App gefragt, ob ich lieber zum indischen Restaurant gehe oder doch zum Italiener (beide als OSM-POI im Kartenmaterial). Dazu kommen noch dynamische Probleme. Die Route und Einkehrmöglichkeiten werden soweit mit dem Regenradar verknüpft, dass man pünktlich zur großen Regenschauer im Lieblingsrestaurant sitzt und danach wieder trocken weiterfahren kann. Erstaunlich, aber es hatte im ersten Versuch funktioniert (auch dank der guten Regenradar-App von wetteronline). Als Routing-Engine habe ich dazu ein größeres neuronales Netz am laufen.

Meine längste geführte Radstrecke mit OsmAnd war ca. 30 km. An sich wäre die Strecke Ok gewesen, wenn es nicht wieder über die Berge gehen würde, die ich auf der Rücktour übers Tal vermeiden wollte.

Die von dir beschriebenen Zacken sind mir noch nicht aufgefallen. Aber manchmal kam es vor, dass partout ein bestimmter Weg verweigert wurde, auch als ich schon kurz davor stand. Einmal (pedestrian mode) habe ich versucht, in JOSM dafür eine Erklärung zu finden, aber es war alles richtig vernetzt, die Nodes verknüpft, der Weg als begehbarer Pfad getaggt. Keine Ahnung. Vielleicht habe ich die Verbots-Schemata nicht verstanden oder es war ein Bug in OsmAnd.

Kommt der Eindruck "vielleicht doch besser aussen rum" vielleicht durch eine andere Metrik zustande? Indem bestimmte Wege einfach bevorzugt werden? In BRouter war mir positiv aufgefallen, dass es einen langen ehemaligen Bahntrassenweg bevorzugt hatte, obwohl es ein tolerierbarer Umweg war. Eigentlich genau das, was man sich als Fahrradfahrer wünscht (wird doch in der Metrik stärker gewichtet, oder?).

openzzz wrote:

Es ist halt schwierig mit Benchmarks zu argumentieren.

Ich hab Dir auch drei konkrete Positiv-Beispiele genannt - die hast Du bloß untern Tisch fallen lassen. :-)

Bei der Grundgeschwindigkeit gibt es keinen nennenswerten Unterschied mehr. Das Problem sind nur die Programmierer, die es sich leicht machen und die teuersten Luxusklassen ohne Nachzudenken einsetzen. Java macht das einem leicht, weil es so viele schöne libs gibt. Aber in C kriegt man dasselbe z.B. mit Boost auch locker hin. Letztendlich entscheidet ob sich der Autor was dabei gedacht hat.

bye, Nop

openzzz wrote:

OsmAnd bevorzugt Fahrradwege entlang viel befahrener Straßen. Kann man machen für die Rennradler unter uns, für sie eine gute Metrik. Ich möchte aber Ruhe und fahre bevorzugt Feldwege und noch lieber Waldwege. Aber wer berücksichtigt den Waldanteil? Ehrlich gesagt hat mir bisher noch kein Router zuverlässig aus meiner Sicht attraktive Routen geliefert. Ich priorisiere auch keine Fernradwege, wenn es ruhigere Alternativen im Wald gibt. Hoch im Kurs stehen bei mir Fluss- und Bachläufe, Mischwald, Fernsicht auf Höhenwegen etc.

So etwas hätte ich auch gerne.

Erst kürzlich gab es einen Blogeintrag zu externen Datenquellen in OSRM mit ähnlicher Thematik: Biking Directions With OSRM's New External Data Support. Im Beispiel wird eine zusätzliche PostGIS Datenbank mit Imposm Schema verwendet, um Wege innerhalb oder in der Nähe eines Industriegebiets schlechter zu bewerten.

Dann noch Routing über Flächen und Arndt wird es im Winter nicht langweilig 😉

Gruß,
Norbert

ikonor wrote:

Im Beispiel wird eine zusätzliche PostGIS Datenbank mit Imposm Schema verwendet, um Wege innerhalb oder in der Nähe eines Industriegebiets schlechter zu bewerten.

Ruhige Industriegebiete sind mir aber noch lieber als stark befahrene Hauptstraßen,
auch wenn da noch so ein toller "Radfernwanderweg" durch geht oder der Fahrradweg super ausgebaut ist.
Der Straßenlärm geht mir am meisten auf die Nerven.

Weiterhin mag ich ampelfreie Routen, z.B. am Fluß entlang, wo man mal so richtig
Gas geben kann und durch nichts aufgehalten wird.

Ein Rad-Router ist deutlich komplexer als ein Automobil-Router.

Eigentlich geht es nur mit "Persönlichkeitsprofilen", also ein langes Interview
zu Beginn "fährst du gerne durch Wälder?, "wäre ein bisschen Matsch ein Problem für den Sonntagsrad?",
"brauchst du Asphalt oder hast du richtige Reifen?", "lieber die Strecke mit den hübschen Joggerinnen?" ...

Und für jede Person kann man weiter differenzieren
Profil "will schnell nach Hause", "habe Zeit für die Natur", "heute mal sportlicher" ...

Aber bei all den Fortschritten: es ist auch schön, mal ohne Karte und Navi rauszufahren
und sich überraschen zu lassen.

openzzz wrote:

ikonor wrote:

Im Beispiel wird eine zusätzliche PostGIS Datenbank mit Imposm Schema verwendet, um Wege innerhalb oder in der Nähe eines Industriegebiets schlechter zu bewerten.

Ruhige Industriegebiete sind mir aber noch lieber als stark befahrene Hauptstraßen,
auch wenn da noch so ein toller "Radfernwanderweg" durch geht oder der Fahrradweg super ausgebaut ist.
Der Straßenlärm geht mir am meisten auf die Nerven.

Weiterhin mag ich ampelfreie Routen, z.B. am Fluß entlang, wo man mal so richtig
Gas geben kann und durch nichts aufgehalten wird.

Ist ja auch nur ein Beispiel, wenn man technisch Industriegebiete vermeiden kann, kann man auch Nähe zu Hauptstraßen vermeiden und Wälder oder Nähe zu See/Fluß bevorzugen.

Deutlich einfacher umzusetzen wäre aber vermutlich ein Flag für Wanderrouten, analog zu longdistancecycleway/lcn. Zur Planung von kürzeren Touren halte ich Wanderrouten meist für einen besseren Hinweis auf schöne und ruhige Strecken als Radrouten. Sofern man geschotterte Feld- und Waldwege mag, Pfade kann man ja vermeiden.

Um schon jetzt Radwege an Hauptstraßen zu vermeiden, könnte man in einem BRouter Profil evtl. auch einfach generell track und residential gegenüber Radwegen (cycleway/bicycle) bevorzugen.

openzzz wrote:

Ein Rad-Router ist deutlich komplexer als ein Automobil-Router.

Eigentlich geht es nur mit "Persönlichkeitsprofilen", also ein langes Interview
zu Beginn "fährst du gerne durch Wälder?, "wäre ein bisschen Matsch ein Problem für den Sonntagsrad?",
"brauchst du Asphalt oder hast du richtige Reifen?", "lieber die Strecke mit den hübschen Joggerinnen?" ...

Und für jede Person kann man weiter differenzieren
Profil "will schnell nach Hause", "habe Zeit für die Natur", "heute mal sportlicher" ...

Aber bei all den Fortschritten: es ist auch schön, mal ohne Karte und Navi rauszufahren
und sich überraschen zu lassen.

Da sehe ich ja eben die Stärke von BRouter, dass man sich seine persönlichen Profile definieren und auch spontan ändern kann. Das geht dann auch schon in Richtung automatische Tourenvorschläge wie bei komoot. Und ja, das ist alles auch ein bisschen nerdige Spielerei, aber halt eben ein spannendes Thema.

Gruß,
Norbert

openzzz wrote:

Aber manchmal kam es vor, dass partout ein bestimmter Weg verweigert wurde, auch als ich schon kurz davor stand. .... Vielleicht habe ich die Verbots-Schemata nicht verstanden oder es war ein Bug in OsmAnd.

Nein, OsmAnd kann keine verschachtelten access-regeln, es ist dieses Thema hier:

http://code.google.com/p/osmand/issues/detail?id=1380

ich kenne den Effekt gut, wenn ich am Rhein den R6 langfahre und am Kernkraftwerk Biblis vorbeikomme. Da ist der R6 als access=private, bicycle=yes getagged, was völlig korrekt ist (es ist ja ein Privatweg auf dem Kraftwerksgelände), aber OsmAnd schickt Dich einmal um das Kraftwerksgelände rum.

openzzz wrote:

Kommt der Eindruck "vielleicht doch besser aussen rum" vielleicht durch eine andere Metrik zustande? Indem bestimmte Wege einfach bevorzugt werden? In BRouter war mir positiv aufgefallen, dass es einen langen ehemaligen Bahntrassenweg bevorzugt hatte, obwohl es ein tolerierbarer Umweg war. Eigentlich genau das, was man sich als Fahrradfahrer wünscht (wird doch in der Metrik stärker gewichtet, oder?).

Bahntrassen-Radwege sind ja nicht speziell getagged, sondern sind einfach track/grade1 oder cycleway, aber hier hilft vielleicht auch die relative grosse "Winkelstrafe" in den BRouter-Profilen, die gerade Wege bevorzugt und zumindest bergab auf der Höhenterm, der sanfte Abfahrten bevorzugt.

openzzz wrote:

Aber wer berücksichtigt den Waldanteil? Ehrlich gesagt hat mir bisher noch kein Router zuverlässig aus meiner Sicht attraktive Routen geliefert.

Die Landuse-Polygone auszuwerten und als Pseudo-Tags für die Routing-Profile zugänglich zu machen (forest=yes) scheint mir jetzt tatsächlich nicht unmöglich.

Da bin ich dann aber wieder bei dem Thema des 64-bit limits im der "Way-Decsription-Bitmap" - ich hab da einfach keine Bits mehr frei und wüsste also nicht, wo ich das forest=yes bit hinschreiben sollte. Also noch ein Grund mehr, diese Datenstruktur umzubauen um dieses Limit aufzuheben, denn da fehlen ja noch ganz andere Infos, wie zum Beispiel die Wander-Relationen, die Turn-Restrictions oder die Wheelchair-Tags. Das reicht dann auch erstmal, soviel lange Winterabende gibts ja auch nicht...

abrensch wrote:

Bahntrassen-Radwege sind ja nicht speziell getagged, sondern sind einfach track/grade1 oder cycleway, aber hier hilft vielleicht auch die relative grosse "Winkelstrafe" in den BRouter-Profilen, die gerade Wege bevorzugt und zumindest bergab auf der Höhenterm, der sanfte Abfahrten bevorzugt.

Hmm, schade. Das sollte man ändern. Ein neues Tag/Attribut dafür?
Bahntrassen haben einen ganz besonderen Character, die sie von anderen Radwegen unterscheidet.
Die sind eben nicht entlang der Hauptstraßen, sondern mitten in der Landschaft.
Steigungen im Mittelgebirge werden durch Tunnel und Viadukte unterdrückt.

Die Attraktivität für Radfahrer ist also besonders hoch, gerade wenn man noch einen Kinderanhänger ziehen muss.

Meinst du den BRouter könnte man als Plugin in OsmAnd integrieren,
so dass er wie der eingebaute Router fungiert ?
Also incl. Routen-Neuberechnen, wenn man mit Absicht von der berechneten Route abweicht
(bei mir sehr typisch).

Damit kann man sich im Android-Market auch noch ein paar Euros dazuverdienen.
Du wirst schon reich, wenn nur ein Bruchteil der weltweiten Population (1 Mrd.?)
mit Android-Smartphone und Fahrrad jeweils ein paar Euros für das Plugin geben würden.
Sehr viel Konkurrenz hast du bei Profil "Rad" nicht. Man muss nur eben besser sein.
Fürs Auto ist mein kommerzielles Navi besser und darum nutze ich das dort exklusiv.

openzzz wrote:

Meinst du den BRouter könnte man als Plugin in OsmAnd integrieren, so dass er wie der eingebaute Router fungiert ? Also incl. Routen-Neuberechnen, wenn man mit Absicht von der berechneten Route abweicht (bei mir sehr typisch).

Genau das hab ich längst gemacht und so benutze ich das auch fast täglich:

abrensch wrote:

Und noch was interressantes habe ich: ich hab's geschafft, OsmAnd aus den Sourcen zu bauen (in der Version ohne native Bibliotheken) und da die direkte Schnittstelle zu BRouter reingebaut. Das ganze ist noch schwebend als Pull-Request auf GitHub:

https://github.com/osmandapp/Osmand/pull/537

Aber eine Binär-Version habe ich jetzt einfach mal bei mir hochgeladen:

http://h2096617.stratoserver.net/broute … router.zip

Das ist natürlich Bastelkram, ohne die nativen Libs ist das rendering schon spürbar langsamer, und das APK ist mit dem Debug-Key signiert (man muss also eine release-version erst deinstallieren), und paar Übersetzungen musste ich auch löschen, aber die Verbindung zu BRouter funktioniert tadellos und die automatischen Neuberechnungen (auch bei langen Strecken) machen richtig Freude.

Bei dem Pull-Request bin ich mir aber mittlerweile nicht mehr so sicher, ob Victors Bedenken wirklich technisch motiviert sind oder ob er einfach nicht will.

Hallo

ich habe den BRouter mit dem MapsforgeSwingMapviewer "verheiratet". Ein Tester hat den Router jetzt mal in den Schweizer Alpen "vergewaltigt". Routet man jetzt auf einer Bergstrecke in kurzen Abschnitten geht der Router irgenwann zurück auf eine "weit" abliegende Nebenstrasse....

Meine Frage ist nun: Läßt sich der BRouter auch so konfigurieren (vergewaltigen?) dass er auch auf Wanderpfaden (Bergpfaden) die kürzeste Route sucht. Egal welche Wege/Pfad Beschaffenheit vorhanden ist. Ich weiß, e soll ja ein Fahrradrouter sein. Ich bin in dieser Richtung auch zufrieden.

Zusammenfassung: Ist es möglich,den BRouter so zu konfiguriern dass er den kürzesten Wegt such unabhängig von Steigung und Wegbeschaffenheit ?
Hintergrund: WanderRouten in den Bergen.......

Das sollte mit dem shortest Profil schon jetzt ohne weiteres funktionieren, wenn man nicht auch Privatwege und gesperrte Wege benutzen will.

Hallo schiki,

leider nicht! Hab ich schon probiert. Auf meinem Testpfad routet die ReitWanderKarte diesen Pfad problemlos....

Hallo womisa,

das wäre dann ein Fall für eine Rückmeldung im OSM-Android-Bike-Routing Forum bei Google. Evtl. sind auch nur die Routing-Daten veraltet.

womisa wrote:

Routet man jetzt auf einer Bergstrecke in kurzen Abschnitten geht der Router irgenwann zurück auf eine "weit" abliegende Nebenstrasse....

Ich hab' das mal in den östereichichen Alpen gesehen, dass eine Wintersperre für den Pass als access=no für ein kurzes Stück der Passstrasse eingetragen war. Was dann natürlich dazu führt, dass der Router irgendwelche noch unpassierbareren Wanderrouten findet.

Sowas kann man patchen, indem man access=no einfach rausnimmt, also aus "or access=private access=no" einfach nur "access=private" macht

Hallo

vielen Dank für die Antworten. Ich habe mal ein Snapshot gemacht (Zentrum ca. 46.53;8.37) geroutet wurde vom 1. roten Punkt zum 2. roten Punkt und dann sollte zum 3 . roten Punkt geroutet werden, aber dann kommt die Blaue Nebenlinie ohne roten Endpunkt.....
Ich habe den "shortest.brf" genommen und die Routingdateien sind neu.

siehe da: http://augilabs.de/swingmapViewer/bilder/Oberwald.jpg

Wie schon beschrieben die http://www.wanderreitkarte.de/ routet das problemlos. Die Kartenbasis (OSM) müßte doch gleich sein, oder?.

ich habe das geändert:

zeile 23: switch or access=private acces=no geändert: switch or access=private
zeile 65: switch or access=private acces=no geändert: switch or access=private

dan kommt aber ein Fehler:

Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: ParseException at line 30: assign operator within expression
at btools.expressions.BExpressionContext.parseFile(BExpressionContext.java:470)
at btools.router.RoutingEngine.<init>(RoutingEngine.java:78)
at womisa.brouter.BRouter.findROUTE(BRouter.java:25)
at org.mapsforge.map.swing.controller.MouseEventListener.mouseClicked(MouseEventListener.java:119)
at java.awt.Component.processMouseEvent(Component.java:6508)
at java.awt.Component.processEvent(Component.java:6270)
at java.awt.Container.processEvent(Container.java:2229)
at java.awt.Component.dispatchEventImpl(Component.java:4861)
at java.awt.Container.dispatchEventImpl(Container.java:2287)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4501)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
at java.awt.Container.dispatchEventImpl(Container.java:2273)
at java.awt.Window.dispatchEventImpl(Window.java:2719)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:694)
at java.awt.EventQueue$3.run(EventQueue.java:692)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.awt.EventQueue$4.run(EventQueue.java:708)
at java.awt.EventQueue$4.run(EventQueue.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

abrensch wrote:

openzzz wrote:

Meinst du den BRouter könnte man als Plugin in OsmAnd integrieren, so dass er wie der eingebaute Router fungiert ? Also incl. Routen-Neuberechnen, wenn man mit Absicht von der berechneten Route abweicht (bei mir sehr typisch).

Genau das hab ich längst gemacht und so benutze ich das auch fast täglich:

abrensch wrote:

Und noch was interressantes habe ich: ich hab's geschafft, OsmAnd aus den Sourcen zu bauen (in der Version ohne native Bibliotheken) und da die direkte Schnittstelle zu BRouter reingebaut. Das ganze ist noch schwebend als Pull-Request auf GitHub:

https://github.com/osmandapp/Osmand/pull/537

Aber eine Binär-Version habe ich jetzt einfach mal bei mir hochgeladen:

http://h2096617.stratoserver.net/broute … router.zip

Das ist natürlich Bastelkram, ohne die nativen Libs ist das rendering schon spürbar langsamer, und das APK ist mit dem Debug-Key signiert (man muss also eine release-version erst deinstallieren), und paar Übersetzungen musste ich auch löschen, aber die Verbindung zu BRouter funktioniert tadellos und die automatischen Neuberechnungen (auch bei langen Strecken) machen richtig Freude.

Bei dem Pull-Request bin ich mir aber mittlerweile nicht mehr so sicher, ob Victors Bedenken wirklich technisch motiviert sind oder ob er einfach nicht will.

Na, ich wollte meine Original-Version nicht deinstallieren. Die ist mittlerweile bei Version 1.6.5 und dein
Binary wäre ein Downgrade auf 1.6.1. Dazwischen hat sich laut Release-Notes das Format der Kartendateien geändert.
Die kommen jetzt auch von einem neuen Server (hatte ich schon bei mir aufgespielt):
http://new.osmand.net/list.php

Die Java-Version läuft auf meinem billigen Samsung-Smartphone (lahme CPU, wenig RAM) extrem langsam.
Mit den native Libs (C++) ist das erträglicher. Der Kartenaufbau könnte natürlich flotter sein, aber es sind
eben auch viele Objekte drin (Detailmodus ist aktiviert). Einmal hatte ich aus Versehen die Java-Version drauf,
da wegen Speichermangel die "Link to SD-Card" Funktion fehlerhaft war, OsmAnd dann die native Libraries
wohl nicht finden konnte. Mein interner Flash-Speicher ist nur 150 MB. Darum muss ich alles auf eine
ausgelagerte Partition der 32 GB µSD-Karte verlinken.

Also Brouter benimmt sich dann genauso wie der Interne Router? Der merkt relativ schnell, wenn ich der Route nicht folge,
und berechnet dann ohne Nachfrage oder Benutzerinteraktion gleich die neue Route.

Soll das denn wirklich ein OsmAnd-Plugin werden? Die stehen unter "Zusatzmodule".
Dein Download ist ja kein Plugin, sondern eine gepatchte Version von OsmAnd selbst.
Der Unterschied beim Plugin wäre, dass man immer die Updates der Originalversion bekommt,
auch wenn sich das BRouter-Plugin nicht geändert hat.

womisa wrote:

Hallo
ich habe den BRouter mit dem MapsforgeSwingMapviewer "verheiratet". Ein Tester hat den Router jetzt mal in den Schweizer Alpen "vergewaltigt". Routet man jetzt auf einer Bergstrecke in kurzen Abschnitten geht der Router irgenwann zurück auf eine "weit" abliegende Nebenstrasse....

Interessant. Willst du den zum Download anbieten?

Ich suche schon länger eine Offline-OSM-Karte, z.B. für den Laptop, wenn man mal kein Netz hat.
Am liebsten hätte ich den OsmAnd auf dem Laptop, aber das geht bisher nur umständlich in einer Android VirtualBox.
Eben mit den Funktionen, nach POI auf der Karte zu suchen oder Routen berechnen zu lassen.
Kann man mit dem Mapsforge Viewer auch nach POI suchen? Die Kombination ist sehr praktisch
("kürzester Weg zur nächsten Pizzeria" oder so).

Hallo

das ist aus verschiedenen Tools mit "heißer Nadel" und nicht all zu vielen Java Kenntnissen zusammengestrickt. Suchen nach POIS lokal wüßte ich derzeit nicht wie man das machen sollte......?
Nehme da aber gerne Anregungen entgegen.
Das GANZE ist noch sehr BUGGY und bei der Bedienung nicht stabil genug für "Jedermann" und die "Inbetriebnahme" an Randbedingungen wie Karten, RenderThemes, Routingfile etc. geknüpt, deshalb möchte ich das nicht publizieren. Außerdem weiß ich nicht wie das mit den Urheberechten von Mapsforge, BRouter, GPXCreator ist.
Mein Beitrag dabei ist kein Geheimnis. Ich bin aber selbst erstaunt, wie man mit Klick,Klick,Klick eine Route auf eine Vektorkarte via BRouter (Mapsforge,Openandromap, Freizeitkarte) erstellen kann.
Gedacht ist das für meine Routenplanungen auf dem Desktop um dies dann auf das Smartphone zu übertragen. Ich verwende derzeit Oruxmaps.

Ok. Verstehe ich. Kannst du denn andere Offline OSM-Kartenprogramme empfehlen?
Ich suche schon länger nach einer Alternative zu Google Earth auf OSM-Basis,
zum schnellen Anschauen der Karte (Earth ist bei mir viel flotter und flüssiger als WWW-basierte Apps),
und zum Annotieren (drübermalen von Polygonen, Tracks, Fähnchen, Textkommentar, Flächen markieren,
Austausch der Overlay-Objekte via KML-Datei, etc.).

"Marble" sieht auf dem ersten Blick ganz gut aus, läuft aber nicht mit den Vektorkarten
und hat keine Annotierungsmöglichkeit.

Basecamp?

Gruß Klaus

openzzz wrote:

Ok. Verstehe ich. Kannst du denn andere Offline OSM-Kartenprogramme empfehlen?

...NEIN! Deshalb habe ich mich auf den Weg gemacht auf dem Desktop ein Tool zu schaffen, mit dem ich meine Mapsforge basierenden Vektorkarten anschauen kann. Dazu war das Mapsforge Rewrite mit dem Desktop SwingMapViewer eine Steilvorlage und ein Grund zum Einstieg in diese Thematik.

Weiterhin kam hinzu, dass der BRouter leicht zu integrieren war. Somit habe ich eine vertraute Umgebung für meine Android / Oruxmaps Karten/ und BRouterwelt auf dem Desktop. Somit habe ich auch auf dem Desktop einen "grafische" Routenerstellungsmöglichkeit, ohne Onlineverbindung. Karten und Routen sind 1:1 austauschbar.

Wenn sich das Ganze stabilisiert hat kann man eventuell auch über eine Weitergabe auch nachdenken.....aber dazu bedarf es einer vernünftigen Doku bzw. Infoseite und das machen Entwickler sehr ungern.

Ps.: Nebenbei eine Frage an NOP.:

Ich weiß ich soll einen eigenen Thread aufmachen, aber weiter oben habt Ihr weit ab vom Thema diskutiert....

Welcher Router steckt hinter der "wanderreitkarte" und wo könnte man Infos für eine lokale Integration und Konfiguration finden?

womisa wrote:

siehe da: http://augilabs.de/swingmapViewer/bilder/Oberwald.jpg

Wie schon beschrieben die http://www.wanderreitkarte.de/ routet das problemlos. Die Kartenbasis (OSM) müßte doch gleich sein, oder?.

Es ist eine Schwäche im Wegpunkt-Matching von BRouter. Ich durchsuche für den Match (=nächste Entfernung zu einem in diesem Profil routbaren Weg) nur in 4 1/80-Grad Kacheln, also einem Gebiet von ca 2,5km*2,5km. Ein solcher Wanderweg, der kilometerweit keine Verzweigung hat, kann mir dabei entgehen. Ich werde das nochmal verbessern, also z.B. das Suchgebiet vergrössern, wenn der Match so weit danebenliegt oder lange Wegabschnitte unterteilen. Danke für den Hinweis.

womisa wrote:

ich habe das geändert:
zeile 23: switch or access=private acces=no geändert: switch or access=private.

Das "or" hätte noch weg gemusst, sonst ist die Hirarchie des Ausdrucks kaputt. Aber wie gesagt, access=no ist hier ja nicht das Problem.

openzzz wrote:

Also Brouter benimmt sich dann genauso wie der Interne Router? Der merkt relativ schnell, wenn ich der Route nicht folge,
und berechnet dann ohne Nachfrage oder Benutzerinteraktion gleich die neue Route.

Ja zu schnell, wie ich finde, die Schwelle liegt bei 30m. Ja, die Funktion ist fast völlig identisch, nur dass BRouter keine Strassennamen liefert (also wenn Du Strassennamen hörst, hast Du den falschen Router eingestellt...) und bei Langstrecken ist das Verhalten anders: BRouter hat einen Timeout von 60 Sekunden, OsmAnd-Intern hat keinen Timeout, verschluckt sich aber irgenwann am Memory-Limit. BRouter kann aber "timeout-freie" Neuberchnungen, wenn zu dem selben Zielpunkt schon eine Route berechnet wurde, und diese Vorberechnung kann man alternativ auch über die BRouter-App machen, so dass man auch Langstrecken mit automatischen Neuberchnungen über OsmAnd (oder Locus..) abfahren kann.

openzzz wrote:

Soll das denn wirklich ein OsmAnd-Plugin werden?

Nein, OsmAnds Plugins sind ja nur eine Mogelpackung, mit modularer Software hat das nichts tu tun. Ich hab' den Patch als Pull-Request in Guthub eingestellt und erwarte eigentlich, dass Victor ihn "merged", und dann ist es ganz normaler Bestandteil der Releases.

abrensch wrote:

womisa wrote:

siehe da: http://augilabs.de/swingmapViewer/bilder/Oberwald.jpg

Wie schon beschrieben die http://www.wanderreitkarte.de/ routet das problemlos. Die Kartenbasis (OSM) müßte doch gleich sein, oder?.

Es ist eine Schwäche im Wegpunkt-Matching von BRouter. Ich durchsuche für den Match (=nächste Entfernung zu einem in diesem Profil routbaren Weg) nur in 4 1/80-Grad Kacheln, also einem Gebiet von ca 2,5km*2,5km. Ein solcher Wanderweg, der kilometerweit keine Verzweigung hat, kann mir dabei entgehen. Ich werde das nochmal verbessern, also z.B. das Suchgebiet vergrössern, wenn der Match so weit danebenliegt oder lange Wegabschnitte unterteilen. Danke für den Hinweis.

Hallo Arndt,

in diesem Zusammenhang ein Vorschlag für zukünftige Versionen?

Sollte der gefundene Routen-Endpunkt xxx m vom vorgegebenen Zielpunkt oder yyy m Höhe entfernt sein wird die gefunden Route verworfen. Im Extremfall "keine" Route gefunden.
Möglichkeit der Vorgabe der Maximalen Alternative Routen und der Router gibt die Anzahl der gefundenen Routen (tmp Files) zurück.

Das ist im Falle von Bergwanderrouten wichtig: Worst Case..Es führt genau 1 Weg zum Gipfel, aber es wird ein Routenendpunkt 500m entfernt aber 1000m tiefer gefunden....

Wie denkst du darüber?

abrensch wrote:

openzzz wrote:

Also Brouter benimmt sich dann genauso wie der Interne Router? Der merkt relativ schnell, wenn ich der Route nicht folge,
und berechnet dann ohne Nachfrage oder Benutzerinteraktion gleich die neue Route.

Ja zu schnell, wie ich finde, die Schwelle liegt bei 30m. Ja, die Funktion ist fast völlig identisch, nur dass BRouter keine Strassennamen liefert (also wenn Du Strassennamen hörst, hast Du den falschen Router eingestellt...) und bei Langstrecken ist das Verhalten anders: BRouter hat einen Timeout von 60 Sekunden, OsmAnd-Intern hat keinen Timeout, verschluckt sich aber irgenwann am Memory-Limit. BRouter kann aber "timeout-freie" Neuberchnungen, wenn zu dem selben Zielpunkt schon eine Route berechnet wurde, und diese Vorberechnung kann man alternativ auch über die BRouter-App machen, so dass man auch Langstrecken mit automatischen Neuberchnungen über OsmAnd (oder Locus..) abfahren kann.

Ok. Prima. Dann wird das sicher bald meine bevorzugte Routing-Engine. Meistens, so wie heute, benutze ich OsmAnd nur informativ als Karte und als GPS-Logger. Wahrscheinlich komme ich erst wieder im Frühjahr zu längeren Touren in unbekannte Gebiete. Im Winter fahre ich nicht gerne. Bis dahin ist BRouter dann hoffentlich schon in der Release-Version von OsmAnd drin. Meinst du das funktioniert mit Victors Plänen zur C++-Umstellung? Ich kann mir nicht vorstellen, dass die App komplett nach C++ umgestellt wird. Geht das überhaupt bei Android? Ich dachte die App-APIs sind in erster Linie in Java ausgelegt und C++ hat dann im Prinzip nur die Linux-Betriebssystem-APIs zur Verfügung. Ich sehe den Mix verschiedener Programmiersprachen nicht so kritisch. Bei mir nutze ich oft mathematischen Code aus Fortran, der über DLLs angebunden wird. Fast alle Supercomputer machen das so für HPC. Bei klar definierten Schnittstellen und unabhängigen Modulen ist das kein Problem. Auch der Mix von Python und C++ ist sehr beliebt in der OpenSource-Welt.

Also hatte ich das vorher richtig eingeschätzt, dass das Memory-Limit die größte Einschränkung beim Routing ist, oder? Mein Billig-Samsung hat nur ca. 150 MB RAM. Das ist nicht viel.

Dass du dein Wegenetz konsequent auf Routing-Performance optimiert hast ist verständlich. Aber ist das so stark reduziert, dass du keine Referenz (ID, Index, Pointer) mehr zur OsmAnd-Vektorkarte herstellen kannst? Da stehen die Straßennamen schon drin.

abrensch wrote:

openzzz wrote:

Soll das denn wirklich ein OsmAnd-Plugin werden?

Nein, OsmAnds Plugins sind ja nur eine Mogelpackung, mit modularer Software hat das nichts tu tun. Ich hab' den Patch als Pull-Request in Guthub eingestellt und erwarte eigentlich, dass Victor ihn "merged", und dann ist es ganz normaler Bestandteil der Releases.

Ok, so hatte ich das auch ursprünglich verstanden. Dann muss ich wohl auf die nächste Release warten.

Aber was ist das Problem mit den Plugins aka "Zusatzmodule" ? Die werden im Android-Market separat zum Download angeboten (Parking-Plugin, STRM-Plugin etc.) Oder sind die alle schon im Hauptprogramm vorhanden, werden quasi durch den Extra-Download nur freigeschaltet? Ein modulares Plugin-Konzept ist natürlich schwieriger zu realisieren. Ein Routing-Plugin würde Zugriff auf interne Datenstrukturen benötigen, z.B. auf die Kartendaten, die in OsmAnd geladen werden.

seichter wrote:

Generell ist Java eine interpretierte, C/C++ eine compilierte Sprache. Daher rührten die Laufzeitunterschiede zu Beginn vor allem her. Heute gibt es JIT-Compiler zu Java, die den Code zur Laufzeit zumindest lokal auch optimieren können. Da der meiste Rechenaufwand üblicherweise in engen Schleifen verbraten wird, hat sich der Unterschied damit drastisch verringert.
Global kann aber nur eine compilierte Sprache optimieren. Welchen Anteil das an der Rechenzeit hat und ob der C++-Compiler das auch tut, ist wieder eine andere Frage.

in dem Zusammenhang eine interessante Meldung:

Dalvik-Nachfolger: Google lädt zum Testen der neuen Android-Runtime ein
http://www.heise.de/newsticker/meldung/ … 41644.html

Man kann Java natürlich auch normal zum Maschinencode statt Bytecode compilieren. In GCJ gibt es das schon länger (wohl nicht so gut optimiert). Google will das jetzt auch für Android umsetzen. Maschinencode ist einfach vom Prinzip her schneller als Bytecode. Bytecode ist für ARM und x86 immer ein Fremdkörper, der in virtuellen Maschinen emuliert werden oder übersetzt werden muss. Nur spezielle Java-Prozessoren können den ausführen. Bytecode hat sicherlich Vorteile, ist aber nie performance-optimal.

seichter wrote:

Zusatz: Einen lausigen Algorithmus rettet auch eine "schnellere" Sprache nicht. Beim selben Algorithmus kann es aber sehr wohl Unterschiede geben. Ob die aber so groß sind, dass sich der erheblich größere Aufwand für eine "Mischtechnologie" (Einbinden von native code) lohnt, ist fraglich.

Verschiedene Sprachen geben aber verschiedene Möglichkeiten, einen Algorithmus zu optimieren. Java und Python leiden darunter, dass man die Speicherbytes durch Pointer nicht so gut unter Kontrolle hat. Das wird der ART-Compiler von Google auch nicht lösen können. Das ist sprachinhärent.

Es kann durchaus sein, dass es für das Routing-Problem keine so große Rolle spielt, denn die Speicherverwaltung im dynamischen Routing-Graphen würde man vermutlich auch in C++ nicht manuell übernehmen.

Einen Unterschied gibt es auch bei den Datentypen. Bei Java wird immer eine virtual table für Objekte benötigt (richtig?). Wenn massenweise Datenobjekte verwaltet werden (z.B. in Vektoren und Matrizen), ist das deutlich weniger effizient als C++-Objekte ohne virtual tables.

Hallo Arndt,

der BRouter verhält sich an vielen Stellen sehr seltsam. Am Kartenmaterial kann es beinahe nicht liegen, da das Graphhopper problemlos packt.

Exemplarisch 1 Beispiel:

BRouter ==> http://www.gpswandern.de/gpxviewer/tvan … shortest_0

Graphhopper ==> http://graphhopper.com/maps/?point=48.7 … cale=de-de

Viele Grüsse
Achim

womisa wrote:

Hallo Arndt,der BRouter verhält sich an vielen Stellen sehr seltsam. Am Kartenmaterial kann es beinahe nicht liegen, da das Graphhopper problemlos packt.

Hi Achim

oh ja, passiert immer dann, wenn start- und endpunkt auf dem gleichen wegabschnitt liegen, da findet er den zielpunkt nicht und durchsucht dann den rest der welt. Danke für den Hinsweis.

War noch nie ganz richtig an der Stelle, nur bisher war es so, dass dann der Zielpunkt falsch gemappt wurde (auf die nächste Kreuzung, nur irgendwann (wird wohl die 0.95 gewesen sein) hab' ich's dann wohl verschlimmbessert.

Wird wohl Zeit für die 0.97... muss nur erst paar andere, langweilige Dinge (wie Steuererklärung...) vom Tisch kriegen bevor ich mich wieder rein vertiefen kann.

Gruss, Arndt

Hallo Arndt,

erstmal Danke für den Brouter, Dank dir kann ich den Frühling kaum erwarten :-)
Bis vor kurzem hatte ich den Router nur ab und zu mal testweise genutzt (in Locus), aber es war mir auf Dauer zu umständlich mit den from/to Wegpunkten und dem Öffnen des Tracks.
Jetzt mit der Android-Schnittstelle und der dazu passenden Implementierung in Locus macht das schon viel mehr Spaß! Ich hab auch mal angefangen an einem MTB-Profil zu basteln, welches meinen Anforderungen entspricht, und das sieht jetzt schon ganz vielversprechend aus! Is echt toll dass man die Profile selbst anpassen kann!

Nun meine Frage: Ist es in der aktuellen Version möglich, AlternativRouten im Server-Modus über die Intents-Schnittstelle zu bekommen?

Mit Locus scheint das bei mir nicht zu funktionieren. Ich hab es versucht, indem ich mehrmals hintereinander Navigation mit exakt den gleichen Start- und Zielpunkten ausgeführt habe. Die Punkte waren dabei POIs aus meiner Datenbank, d.h. die Koordinaten sollten zwischen den Aufrufen wirklich genau gleich gewesen sein. Ich erhalte aber immer die gleiche Route.

Über den manuellen Aufruf der Brouter-App (from/to Wegpunkte gesetzt) funktioniert das Berechnen von Alternativrouten problemlos.

Ich hätte zwei Ideen:

1. Locus macht irgendwas bei den Intents falsch. In diesem Fall würde ich im Locus Forum weiter fragen.

2. Da du ja im Server-Modus schnelle partielle Neuberechnung unterstützen möchtest, funktionieren Alternativrouten in dem Modus nicht mehr. Bei der zweiten Berechnung findet eine schnelle Neuberechnung der Route statt (da gleicher Zielpunkt), aber keine Alternativ-Berechnung.

Oder ist es doch was anderes?

Gruß und Danke!

aw_stl wrote:

Nun meine Frage: Ist es in der aktuellen Version möglich, AlternativRouten im Server-Modus über die Intents-Schnittstelle zu bekommen

Nein. Ich könnte den Parameter "Alternativ-Index" zwar in der Schnittstelle exponieren, aber ich wüsste kein Maptool, was das Konzept kennt.

Beim Aufruf der Brouter-App geht das Triggern von Alternativ-Berechnungen über einen Dateivergleich: wenn er die Ergebnisdatei mit exakt dem gleichen Ergebnis überschreiben würde, macht er stattdessen eine neue Runde für die nächste Alternative. Also wenn sich irgendwas an den Parametern ändert, was das Routing-Ergebnis beeinflusst, fängt er wieder von vorne an.

Aber es gibt auch eine "Alternative zu den Alternativen"... wenn mir eine Route nicht passt, erzwinge ich die Alternative normalerweise über Sperrpunkte. Und die wirken auch beim Aufruf über die Schnittstelle, wenn sie in einen Routing-Modus hineinkonfiguriert wurden. Und an der Stelle denke ich tatsächlich drüber nach, ob man das nicht vereinfachen kann, also einen neuen Sperrpunkt aktivieren einfach indem man ihn als Wegpunkt anlegt, ohne anschliessend extra nochmal die BRouter-App starten zu müssen.

abrensch wrote:

aw_stl wrote:

Nun meine Frage: Ist es in der aktuellen Version möglich, AlternativRouten im Server-Modus über die Intents-Schnittstelle zu bekommen

Nein. Ich könnte den Parameter "Alternativ-Index" zwar in der Schnittstelle exponieren, aber ich wüsste kein Maptool, was das Konzept kennt.

Ok das stimmt. Ich dachte nur, ich kann es "herbeitricksen", indem ich die gleiche Strecke mehrmals berechnen lasse, was ja beim standalone-brouter so geht.

abrensch wrote:

Beim Aufruf der Brouter-App geht das Triggern von Alternativ-Berechnungen über einen Dateivergleich: wenn er die Ergebnisdatei mit exakt dem gleichen Ergebnis überschreiben würde, macht er stattdessen eine neue Runde für die nächste Alternative. Also wenn sich irgendwas an den Parametern ändert, was das Routing-Ergebnis beeinflusst, fängt er wieder von vorne an.

Die Methode erklärt natürlich, warum das über den Intent nicht geht. Da wird keine Datei "überschrieben", sondern das Ergebnis direkt an die aufrufende App zurückgegeben. Danke für die Erklärung!

abrensch wrote:

Aber es gibt auch eine "Alternative zu den Alternativen"... wenn mir eine Route nicht passt, erzwinge ich die Alternative normalerweise über Sperrpunkte. Und die wirken auch beim Aufruf über die Schnittstelle, wenn sie in einen Routing-Modus hineinkonfiguriert wurden. Und an der Stelle denke ich tatsächlich drüber nach, ob man das nicht vereinfachen kann, also einen neuen Sperrpunkt aktivieren einfach indem man ihn als Wegpunkt anlegt, ohne anschliessend extra nochmal die BRouter-App starten zu müssen.

Das klingt auch gut! Das momentane Verfahren ist mir auch zu umständlich. Brouter lässt sich zwar relativ komfortabel aus Locus heraus starten, aber dann kommt ja noch die Profil-Auswahl, die Auswahl der Via- und Nogo-Punkte und am Ende die Zuordnung des Routenprofils. Das dauert doch alles relativ lange...
Wie würdest du das genau umsetzen? So dass einfach alle gefundenen nogo-Punkte verwendet werden? Weil einen zusätzlichen Auswahldialog in der Kartenapp gibt es ja dafür nicht.

abrensch wrote:

ich wüsste kein Maptool, was das Konzept kennt

...ok! Umgekehrt wird ein Schuh daraus. Es gibt kein Tool das dieses Feture unterstützt, weil es keine (?) Router gibt die "Alternativen" generieren. Eine "GROSSE BITTE" an dich, gebe bitte das Feature der Alternativen-Routen-Generierung nicht auf. Zumindest in der Desktop Version.
Derzeit generiere ich für jeden "Routing-Abschnitt" eine GPX Datei in die ein Wegpunkt und mehre TrackSegmente, die dem Wegpunkt und seinem Vorgänger zugeordenet sind. Die entgültige Route kann ich mir dann aus dieser GPX Datei zusamenstellen durch Auswahl welche Routingsegment mir passt (Steigung,Länge ..etc).

Oder denkst du darüber nach dieses Feature ganz aufzugeben?

aw_stl wrote:

Wie würdest du das genau umsetzen? So dass einfach alle gefundenen nogo-Punkte verwendet werden? Weil einen zusätzlichen Auswahldialog in der Kartenapp gibt es ja dafür nicht.

Ich weiss es nicht, ich darf da nicht zuviel Heuristik reinbasteln, weil sonst versteht es keiner mehr und dann ist es nutzlos. Aber die Anforderung scheint zu sein, dass, wenn ich vor einem Hindernis stehe, dafür eine nogo-Wegpunkt anlege und dann die Route neu berechne, dass dieser Nogo-Punkt dann automatich aktiv ist, weil warum hätte ich ihn sonst eingetragen. Gleiches gilt dann auch für's Löschen von Nogo-Punkten.

Dafür muss ich aber das Konfigurationskonzept bisschen ändern.

Hm ja, ist alles ein bisschen kompliziert, wenn die Maptools nur simples Routing von A nach B unterstützen. Aber vielleicht sollten die da auch irgendwann mal weiter denken. Kommerzielle Navi-Apps bieten ja z.B. auch mehrere Alternativrouten an.
Aber dafür dann einen Konsens zu finden, den dann alle nutzen wird wahrscheinlich auch schwierig.
Die Idee mit den nogo-Punkent wäre aber auch schon nicht schlecht. So wie es jetzt ist, sind die nogo-Punkte für mich relativ nutzlos, da sie nicht schnell genug konfigurierbar sind.

Was anderes:
Ich hätte mal noch eine Frage zu den Routingprofilen. Was genau bewirkt "uphillcutoff" bzw. "downhillcutoff"? So wie ich das bis jetzt verstanden habe, hat es wohl was mit den Anstiegen zu tun, aber was genau bedeutet ein Wert von z.B. 1.5?

aw_stl wrote:

Was anderes:
Ich hätte mal noch eine Frage zu den Routingprofilen. Was genau bewirkt "uphillcutoff" bzw. "downhillcutoff"? So wie ich das bis jetzt verstanden habe, hat es wohl was mit den Anstiegen zu tun, aber was genau bedeutet ein Wert von z.B. 1.5?

Kurzgesagt: downhillcutoff = 1.5 heisst 1,5% Gefälle sind "gratis", führen also nicht zu Strafpunkten in der Bewertungsfunktion. Das ist einerseits funktional begründet, weil man bei leichtem Gefälle seine Energie zurückbekommt und nicht in die Wind- oder Bremsreibung steckt. Andererseits stabilisiert es aber auch die Berechnung, man kanns also auch nicht einfach weglassen, ohne komische Effekte zu riskieren.

Die lange version ist in diesem Thread hier: https://groups.google.com/forum/#!topic … oB5h4bI1vg

Danke, dann hatte ich es richtig verstanden.

Habe heute die Version 0.97 von BRouter online gestellt, siehe http://brensche.de/brouter/revisions.html

Da sollten jetzt wirklich alle Issues behandelt sein, die hier in diesem Thread besprochen wurden und wo ich irgendwann mal gesagt habe, dass ich es in der nächsten Version ändern werde. Sollte ich irgendjemanden vergessen haben, dann bitte ich um einen Hinweis.

Das Thema mit den Sperrpunkten in der Service-Schnittstelle habe ich glaubich ganz gut gelöst, indem ich die Logik invertiert habe, ein Routing-Modus speichert jetzt also nicht mehr die Liste der aktiven Sperrpunkte, sondern die, die de-selektiert wurden, also die Veto-Liste. Auf diese Weise kann man jetzt im Maptool einfach Sperrpunkte anlegen und löschen, und das ist immer sofort wirksam.

Und das man jetzt Wegpunkte auch in der BRouter-App aus der Liste aller verfügbaren Wegpunkte wählen kann ist für die meisten Fälle eine echte Vereinfachung. to/from/via Punkte sind damit im Normallfall nicht mehr nötig.

Ich hab mich wirklich auf diese Bugfix-Themen beschränkt, um jetzt den Kopf freizubekommen für echte Erweiterungen, da steht auch schon wieder einiges auf Liste, Fahrzeit-Berechnung, Voice-Navigation-Hints, Foolprof-Installer-App... aber nächstes Jahr ist ja auch noch Zeit. Jetzt erst mal feiern gehen, Euch allen guten Rutsch, und nochmal Danke für den vielen Feedback, den Ihr in 2013 zu BRouter geliefert habt und durch den das Projekt wohl ein ganzen Stück vorangekommen ist.

Ich hab mal im OSM-Wiki gesucht:

Haben wir eigentlich noch keine eigene Seite dort für BRouter?

Mein Schnittstellen-Patch zu OsmAnd wurde von Victor jetzt übernommen, er ist jetzt also im Nightly-Build enthalten:

http://download.osmand.net/latest-night … efault.apk

bisher zwar nur Nightly-Build und kein Release-Build, aber das ist ja jetzt nurnoch eine Frage der Zeit, auch bis es in Google-Play ankommt. Ist aber auch schon gleich ein fieser Fehler drin bei der Konfiguration der Navigations-Dienste: offenbar bezieht sich eine Änderung des Navigationsdienstes zu einem Modus (car/bike/foot) jetzt nicht mehr auf den Modus, den man in diesem Dialog auswählt, sondern auf den Default-Modus, den man woanders eingestellt hat. Verwirrend, aber wenn man's weiss kommt man zurecht.

Damit ist BRouter jetzt auch in OsmAnd gut integriert.

Und eine neue Version (0.98) mit paar Bugfixes habe ich auch online gestellt:

http://brensche.de/brouter/revisions.html

Zu der Frage mit dem OSM-Wiki: ich pflege nur den Eintrag in der Router-Vergleichsmatrix, aber eine (deutsche) Doku, die bisschen die Möglichkeiten und die Alleinstellungsmerkmale beschreibt gibt es in der Tat nicht. Es gibt bisschen was im deutschen Locus-Forum. Meine eigene (englische) Web-Page ist mittleirweile als Doku auch nicht mehr wirklich gut, weil sie historisch gewachsen ist und die eigentlich wichtigen Anwendungsfälle nicht wirklich klar werden.

Hallo Arndt,

vielen Dank für die neue Version!

Jetzt funktionieren auch meine Problemfälle auf dem gleichen (langen) Wegsegment mit meinem Mapsforge-Rescue Mapviewer auf dem Desktop.

Irgendwann (brouter_092_bundle) war mal BRouter.java dabei. Kannst du das zukünftig wieder ins Paket mit aufnehmen?

Vielen Dank
Achim

Hallo,

Danke auch nochmal von mir! Das neue Handling der nogo-Punkte funzt super, hat mir letztes WE im Wald schon geholfen :-)

Eine Frage: wie oft aktualisierst du eigentlich die Routing-Files?

aw_stl wrote:

Eine Frage: wie oft aktualisierst du eigentlich die Routing-Files?

Es sollte jetzt jeder neue Planet-Dump verarbeitet werden, also wöchentlich, wobei da aber ab und zu einer ausfällt, aber in letzter Zeit scheint's stabil zu laufen. Mein Skript schaut einmal täglich nach einer neuen (PBF-) Version und braucht dann ca 6 Stunden für die Verarbeitung.

Ich hab' allerdings noch eine Leiche im Keller beim Routing über Files aus verschiedenen Präprozessor-Läufen, das wird technisch nicht verhindert und kann auch funktionieren, kann aber auch schiefgehen, wenn an den Rand-Knoten editiert wurde. Also besser nicht so häufig aktualisieren, aber wenn dann alle Files ersetzen.

womisa wrote:

Irgendwann (brouter_092_bundle) war mal BRouter.java dabei. Kannst du das zukünftig wieder ins Paket mit aufnehmen?

Dieses "bundle" war nur eine Notlösung, um Integration zu ermöglichen ohne Zugriff auf die Quellen.

Jetzt sind die Quellen öffentlich (und GPL-ed ):

https://github.com/abrensch/brouter

und Da findest Du auch die gesuchte Java-Datei (unter brouter-server/src/main/java/btools/server )

Gruss, Arndt

Hallo Arndt,

vielen Dank. Mein Ziel ist es ein Jar zu generieren. Ich bin keine großer Maven Kenner aber Mapsforge etc. kann ich übersetzen.

Leider schaffe ich das mit Brouter noch nicht. Hast du mir da einen Tipp?

Viele Grüsse
Achim

Nachtrag: Ich habe die depency im pom File von JUNIT auf 4.11 geändert dann gehts.......? wie bringt man das mit 4.12 zum gehen?

mvn -DskipTests clean install

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.828s
[INFO] Finished at: Sun Jan 19 17:17:58 CET 2014
[INFO] Final Memory: 11M/31M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project brouter-util: Could not resolve depend
encies for project org.btools:brouter-util:jar:0.98: Could not find artifact jun
it:junit:jar:4.12 in central (http://repo.maven.apache.org/maven2) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/disp … ndencyReso
lutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command

abrensch wrote:

Jetzt sind die Quellen öffentlich (und GPL-ed ):

https://github.com/abrensch/brouter

Sehr schön, freut mich. Danke.

Gruß,
Norbert

womisa wrote:

Ich bin keine großer Maven Kenner aber Mapsforge etc. kann ich übersetzen.

Da haben wir was gemeinsam, ich bin da auch noch in der Lernkurve

womisa wrote:

Nachtrag: Ich habe die depency im pom File von JUNIT auf 4.11 geändert dann gehts.......? wie bringt man das mit 4.12 zum gehen?

Eigentlich schon krass, dass Maven, dessen Stärke ja gerade die Handhabung von Dependencies ist, bei den eigenen Dependencies so zickig ist.

Also ich benutze maven-3.05 mit android plugin 3.6.0 und Android SDK platform 10 und Junit 4.11 und es geht auch nur genau in der Kombination (weil ich mir zur Zeit keine neuere Android SDK Plattform installieren will). Ich hatte den Pull-Request zum pom.xml übernommen weil ich dachte ich bin einfach out-of-date mit meinen Tools.

Aber nur um das Jar-file zu bauen (nicht das APK) ist das alles schon mit Kanonen auf Spatzen, man kann's auch einfach compilieren:

javac -d . brouter-util/src/main/java/btools/util/*.java
javac -d . brouter-expressions/src/main/java/btools/expressions/*.java
javac -d . brouter-mapaccess/src/main/java/btools/mapaccess/*.java
javac -d . brouter-core/src/main/java/btools/router/*.java
javac -d . brouter-server/src/main/java/btools/server/*.java brouter-server/src/main/java/btools/server/request/*.java
javac -d . brouter-map-creator/src/main/java/btools/mapcreator/*.java
jar cf brouter.jar btools

Oder in einen Eclipse Workspace importieren...

Hi Arndt,

vielen Dank für die Antwort. Ich übersetze das zur zeit so:
...

set M2_HOME=D:\apache-maven-3.1.1
set JAVA_HOME=C:\Programme\Java\jdk1.7.0_40
set ANDOID_HOME=D:\_AndroidSDK\adt-bundle-windows-x86-20131030\sdk

set Path=d:\apache-maven-3.1.1\bin;%Path%
set Path=D:\gradle-1.9\bin;%Path%

rem mvn -DskipTests=true clean install assembly:single
rem mvn -DskipTests clean install
mvn clean install
rem mvn clean package
rem gradle clean build

mit gradle übersetze ich das Mapsforge-Rescue Framework. Wie schon geschrieben JUNIT habe ich im pom File auf 4.11 gesetzt....

....

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] brouter ........................................... SUCCESS [6.562s]
[INFO] brouter-util ...................................... SUCCESS [11.484s]
[INFO] brouter-expressions ............................... SUCCESS [3.657s]
[INFO] brouter-mapaccess ................................. SUCCESS [4.390s]
[INFO] brouter-core ...................................... SUCCESS [4.485s]
[INFO] brouter-map-creator ............................... SUCCESS [10.593s]
[INFO] brouter-server .................................... SUCCESS [6.454s]
[INFO] brouter-routing-app ............................... SUCCESS [22.140s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:18.921s
[INFO] Finished at: Mon Jan 20 10:40:30 CET 2014
[INFO] Final Memory: 25M/62M
[INFO] ------------------------------------------------------------------------

Der Brouter und auch Graphhopper funktionieren jetzt in meiner DesktopAnwendung mit dem MapsforgeRescue sehr gut...

Vielen Dank
Achim

Ps.: Ich habe das in IntelliJ importiert, aber das bilden des JAR klappt (noch) nicht..... OK. Jetzt auch

....noch ne Frage zum Jar bilden...woher und wie kommt der Manifest File ins JAR? ====>ERROR: kein Hauptmanifestattribut, in brouter.jar

OK so scheint es zu gehen: jar cfm brouter.jar MANIFEST.txt btools

Weiß jemand welche brouter rd5 Dateien von http://h2096617.stratoserver.net/brouter/segments2/ man für die Alps Karte von http://www.openandromaps.org/downloads/europa braucht? Hier die Kartenabdeckung als Bild http://www.openandromaps.org/wp-content … e/Alps.jpg

yow wrote:

Weiß jemand welche brouter rd5 Dateien von http://h2096617.stratoserver.net/brouter/segments2/ man für die Alps Karte von ... braucht?

Die Kollegen im Locus-Forum wissen sowas:

http://forum.locusmap.eu/index.php?topi … 1#msg26601

Hi yow,

falls du MOBAC hast ist das ganz einfach. Setze den Haken bei WGSGrid GITTER und "Every 5 degrees" und der linke Kreuzungspunkt ergibt die RD5 Datei.

In Deinem Fall solltest du mit denen klar kommen:

E5_N45.rd5
E5_N40.rd5
E10_N45.rd5
E10_N40.rd5

Hallo,
ich habe auf meinem Samsung Galaxy SII OsmAnd+ 1.6.5 beta und BRouter 0.9.1 installiert. Ich möchte jetzt BRouter auf 0.9.8 updaten.
Muß ich dazu die Version 0.9.1 zuerst deinstalieren und dann die Version 0.9.8 neu installieren oder kann ich die entpackten Dateien von 0.9.8 einfach vom PC auf das Handy über die 0.9.1-Dateien drüber kopieren ?
Im voraus Danke für Eure Hilfe.

Gruß
Peter

PT-53 wrote:

Hallo,
Muß ich dazu die Version 0.9.1 zuerst deinstalieren und dann die Version 0.9.8 neu installieren oder kann ich die entpackten Dateien von 0.9.8 einfach vom PC auf das Handy über die 0.9.1-Dateien drüber kopieren ?

Sollte beides gehen. NAch De-Installation muss man das base-directory neu eingeben, das ist der einzige Unterschied. Auf der SD-Karte wird durch De-Installation nichts gelöscht.

Übrigens: mit einer aktuellen ("nightly build") Version von OsmAnd kannst Du BRouter direkt als Navigations-Dienst wählen - so wird ein Schuh draus - mit 1.6.5 geht das noch nicht. Dazu aber zur Sicherheit gleich nochmal mein Kommentar von oben (vom 12.1.):

"Ist aber <im nightly build> auch schon gleich ein fieser Fehler drin bei der Konfiguration der Navigations-Dienste: offenbar bezieht sich eine Änderung des Navigationsdienstes zu einem Modus (car/bike/foot) jetzt nicht mehr auf den Modus, den man in diesem Dialog auswählt, sondern auf den Default-Modus, den man woanders eingestellt hat. Verwirrend, aber wenn man's weiss kommt man zurecht."

abrensch wrote:

http://forum.locusmap.eu/index.php?topi … 1#msg26601

Danke! Dann sollten e5n45 e10n45 und e15n45 passen. Siehe http://postimg.org/image/44jr7p749/

womisa wrote:

Hi yow,

falls du MOBAC hast ist das ganz einfach. Setze den Haken bei WGSGrid GITTER und "Every 5 degrees" und der linke Kreuzungspunkt ergibt die RD5 Datei.

Mobac habe ich nicht. Aber danke für den Hinweis.

In Deinem Fall solltest du mit denen klar kommen:

E5_N45.rd5
E5_N40.rd5
E10_N45.rd5
E10_N40.rd5

Weil sich die Angaben oben und hier teilweise widersprechen habe ich sicherheitshalber folgende Dateien runtergeladen:
E10_N40.rd5
E10_N45.rd5
E15_N45.rd5
E5_N40.rd5
E5_N45.rd5

Und in den Ordner /mnt/sdcard/brouter/segments2 kopiert. Dazu alles von http://brensche.de/brouter/profiles2/ in den Ordner /mnt/sdcard/brouter/profiles2

Dann in Orux zwei Wegepunkte mit Namen from und to erstellt, dann Route suchen gewählt und dort die Optionen zu Fuß, kürzeste und BRoute (offline) gewählt. Das ganze mit dem blauen Haken bestätigt. Dann kommt die Meldung "Fehler: Mindestens zwei Punkte notwendig".

Hi Yow,

E15_N45.rd5 ist Östlich Wien Graz...habe ich vergessen...SORRY

Das "from" "to" müßte eigentlich gehen wenn du das richtig installiert hast

...aber das war früher: Jetzt kannst du in OruxMaps Unter dem Icon Autobahn==>Route suchen Options (Klappboxen)==>{Auto/zuFuß/Fahrrad}==>{kürzeste/schnellste} ==> BROUTER (Offline) anwählen

dann mit +Waypoints eingeben(Mehrere möglich...Kreuz auf der MAP) dann den Haken anwählen und es wird geroutet......

Falls du auf dem Desktop Brouter unter Java testen willst schick mir ne Mail....

Ich glaube mein Fehler war das ich die Wegepunkte in Orux oben im Menü erstellt habe. Wenn ich direkt Route suchen wähle und dann mit dem Pluszeichen die Wegepunkte erstelle kommt allerdings die Meldung brouter config service not found oder so ähnlich.

Eventuell mußt du Brouter Standolone starten und am Ende irgenwie Service am Ende auswählen,..nur einmal....

Nachdem ich brouter manuell gestartet, ein Profil gewählt, anschließend den Server Mode gewählt und dann wiederum ein Profil, aber ein anderes (irgendwas mit foot) aktiviert habe funktioniert es.

Wie kann ich brouter als Standard in Orux setzen?

yow wrote:

Wie kann ich brouter als Standard in Orux setzen?

..geht leider nicht! Habe ich im OruxForum schon mehrmal angefragt ob das eingebaut wird zu konfigurieren........

Ikonor's Leaflet Client für BRouter ist ja seit einiger Zeit auf Github:

https://github.com/nrenner/brouter-web

Der war hier in diesem Thread bei Kommentar#117 schonmal Thema und ist, obwohl immer noch "alpha", seitdem deutlich erwachsener geworden. Speziell die Fähigkeit, interaktiv Sperrkreise zu setzen und damit die berechnete Route zu "schubsen" find ich klasse. Das Höhendiagramm mit Positions-Feedback auf den Track ist auch nicht von schlechten Eltern.

Ich habe den jetzt auch mal auf meinen Server geschoben mit einem Serverseitigen Router-Prozess:

http://h2096617.stratoserver.net/brouter-web/

Ich weiss noch nicht, ob dieser Serverprozess standhält, er benutzt auch wieder eine Priorieserung gemäss "neue Anfragen killen die alten", diesmal aber mit einem Threadpool von 5 und (vorerst) mit einem Timeout von 60 Sekunden. Mal schauen, wenn das Ding überrannt wird muss ich mir was besseres überlegen. Wem das zu instabil ist kann natürlich auch, wie von Ikonor eigentlich vorgesehen, den Router auf dem eigenen PC laufen lassen.

Viel Spass damit!

Hallo Arndt,

wie kann man bei der Standolone Version (Brouter.java) die "nogos" bzw. "Sperrkreise" übergeben?

Vielen Dank
Achim

womisa wrote:

wie kann man bei der Standolone Version (Brouter.java) die "nogos" bzw. "Sperrkreise" übergeben

Hi Achim,

in BRouter.java wird das nicht durchgeschleift. Wenn Du in Deinem Client Sperrpunkte setzen willst, musst Du die Funktionalität aus BRouter.java in Deinen Code übernehmen und da die Liste der Sperrpunkte direkt an "RoutingContext" übergeben.

Vorlage ist entweder so, wie es der Leaflet-Client macht:

https://github.com/abrensch/brouter/blo … ndler.java

oder der Android-Service:

https://github.com/abrensch/brouter/blo … orker.java

Gruss, Arndt

Hallo Arndt

vielen Dank für die Links.

Was macht eigentlich der AlternativeIndex ?

rc.setAlternativeIdx(Integer.parseInt(params.get( "alternativeidx" )));

Ich habe zwischenzeitlich die Möglichkeit eingebaut die Alternativen von Brouter anzuzeigen. Diese kann man genauso wie die dahinderliegend MAP Ein und Ausblenden.

Behälst du die Möglichkeit der "Alternativen Routengenerierung" zukünftig bei?

Vielen Dank für Brouter Standalone
Achim

BRouter auf Google-Play!

war fleissig am Wochenende und habe meinen Download-manager für BRouter zuende gestrickt.

Zusammen mit paar anderen Usability-Sachen (bessere Vorschläge für Base-Directory,
Default-Installation für profiles und routing-modes) sollte das die Plug&Play Installation sein, die man auf Google-Play braucht, um nicht sofort niedergemacht zu werden.

Ist ganz frisch freigeschaltet und ich freu mich über early-access Feedback, wo's klemmt, was unklar ist oder was so garnicht geht (negativen Feedback aber bitte nur hier und nicht bei Google!)

Ich werde das dann zeitnah (=am kommenden WE) bereinigen.

Gleichzeitig ist das jetzt auch die Github Head-Revision, d.h. eigentlich die Version 0.99, auch wenn ich's noch nicht so genannt habe.

Der Signier-Schlüssel ist ein neuer (weil der alte debug-key nicht auf Google-Play funktioniert), man muss daher eine alte Installation von BRouter explizit de-installieren.

Es wird aber auch das gewohnte distribution-zip geben zur 0.99, was dann auch wieder ohne den Internet-Zugriff daherkommt wie es sich für eine echte Offline-App gehört.

Gruss, Arndt

Hallo Arndt,
hab's mir sofort runtergeladen, aber komme nicht klar.
Gibt es irgendwo eine Step-by-step-Bedienungsanleitung?
Grüße Klaus

KK-O wrote:

hab's mir sofort runtergeladen, aber komme nicht klar.
Gibt es irgendwo eine Step-by-step-Bedienungsanleitung?

Jain, weil das alles so schnell veraltet. Also es gibt natuerlich von mir das README in englisch ( http://www.brensche.de/brouter/readme.txt ) und es gibt für Locus und Oruxmaps jeweils Installationsanleitungen in verschiedenen Sprachen.

Im Locus-Forum gibt es z.B. eine Step-By-Step Anleitung als PDF-Dokument, aber Achtung: das PDF als Attachment sieht man nur, wenn man sich dort eingeloggt hat, sonst ist es verwirrend: http://forum.locusmap.eu/index.php?topi … 0#msg24780

ABER:

Es geht da ja um die (bisher relativ komplizierte) Installation, wenn es mal läuft benutzt man im wensentlichen ja nurnoch das jeweilige Map-Tool (also Locus, OruxMaps oder OsmAnd), und die BRouter-App muss man garnicht mehr starten, sondern sie stellt einen Dienst zur Verfügung, der von den anderen Programmen benutzt wird.

Und genau diese komplizierte Installation soll die Google-Play Version mit dem Download-Manager ja drastisch vereinfachen, also hier die *NEUE* Step-By-Step Anleitung:

1.) Maptool Installieren:

- OruxMaps oder Locus-Maps in den Release-Versionen (z.B. aus Google-Play)
- oder OsmAnd in Version 1.7 (von http://download.osmand.net/releases/, in Google-Play ist noch 1.6.5)

2.) Smartphone in einem WiFi-Netzwerk anmelden

3.) BRouter installieren aus Google-Play

4.) BRouter starten, Vorschlag für Base-Directory bestätigen (die grosse, externe SD-Karte)

5.) Warnung-Dialog bzgl. Daten-Volumen durch Download Manager bestätigen

6.) Die angezeigte Weltkarte mit 2 Fingern auf-zoomen und auf Europa zentrieren. Dann erscheint ein grünes Gitter

7.) In diesem Gitter die benötigten Quadrate durch Antippen selektieren, am besten erstmal nur eins.

8.) .. zweimal tippen für weniger Download-Volumen (nur "full" Dateien, kein "carsubset" )

9.) unten rechts den "Start Download" Butten drücken

10.) Warten bis der Download fertig ist (Deswegen erstmal nur ein Quadrat und ohne Carsubset, sonst
dauert das über eine Stunde mit dem eingebauten Tempolimit von 200kB/s )

11.) Jetzt ist BRouter als "Hintergrund-Dienst" betriebsbereit und kann von den Maptools genutzt werden

12.) Bei OsmAnd und Locus muss man den Routing-Dienst in der Konfiguration ändern von den voreingestellten
Diensten ("OsmAnd offline" bzw. "Mapquest") nach "BRouter". Bei Oruxmaps wählt man das pro Routenberechnung.

13.) mindestens dreimal schlafen

14.) und dann irgendwann doch noch das README lesen für das nächste Level (Langstrecken, Sperrpunkte, ...)

abrensch schrieb:

...
13.) mindestens dreimal schlafen
...

Genau da hast du bei mir ins Schwarze getroffen. War zu ungeduldig.

Inzwischen habe ich auch die Readme gefunden. Und alles andere auch erledigt.
Die erste Testnavigation über 10 km Luftlinie ging dann auch noch daneben. Der Zielpunkt lag in einer für Radfahrer gesperrten Straße, wäre aber zu Fuß (Rad schieben) von der erlaubten Straße über 50 m erreichbar gewesen.

Als ich das raus hatte, gelang mir eine Navigation in LocusPro über 100 km quer durch das Saarland. Und Hut ab vor der Strecke! Ist zwar nicht genau die, die ich immer gefahren bin, sieht aber trotzdem sehr gut aus.

Werde es in nächster Zeit mal live testen. Wenn man mal drin ist, macht die Navigation selbst einen guten Eindruck.

Danke für das Tool.

Grüße Klaus

Hallo!
Ich teste gerade begeistert die brouter-osmand integrastion. Super routen! Was ich aber noch nicht kapier, ist wie ich bei der integrierten lösung das routingprofil auswähle, also trekking oder safety oder fast usw... mag mir da wer einen tipp geben?
Danke! Maria.

korula wrote:

Was ich aber noch nicht kapier, ist wie ich bei der integrierten lösung das routingprofil auswähle, also trekking oder safety oder fast usw... mag mir da wer einen tipp geben?

Hi Maria,

die Voreinstellung geht über den "Server-Mode" Button, den Du angeboten bekommst nach Profil-Auswahl (+ evtl. Sperrzonen-Auswahl + evtl. Routenberechnung).

Wenn Du den drückst, bekommst Du noch einen Dialog mit der Auswahl der 6 möglichen Modi (Car/Bike/Foot*fast/slow), wovon 2 vorausgewählt sein sollten. Für die Auswahl, die Du da triffst, wird die zuvor gewählte Konfiguration hinterlegt.

In OsmAnd ist die fast/slow Unterscheidung schwer handhabbar (weil irgendwo im Menue versteckt), daher ist es bei OsmAnd besser, fast+slow immer gleich zu belegen (wie es ja auch vorgeschlagen wird) und stattdessen auch den "Auto" und "Fussgänger" Modus mit Fahrrad-Profilen zu belegen.

Über den Server-Mode Button wird übrigens nicht nur das Profil hinterlegt, sondern auch die Liste der abgewählten Sperrzonen und ggf. die zuvor berechnete Route als "Referenztrack". Letzteres erlaubt es, auch lange Strecken, die sonst in OsmAnd auf den 60-Sekunden Timeout laufen würden, über die Dienste-Schnittstelle abzufahren. Er rechnet dann so weit er kommt innerhalb der 60 Sekunden und nimmt das entfernte Ende der Route dann aus dem Referenztrack.

Gruss, Arndt

Hallo Arndt,

danke! Jetzt hab ich's kapiert und kann ganz viel ausprobieren ;-)

Gruß,
Maria.

PS:
Seit dem letzten OsmAnd-Update ist übrigens die fast/slow-Auswahl direkt beim Profilwechsel über ein Häkchen verfügbar... So ist es möglich, 6 verschiedene Profile recht bequem zu belegen und auszuwählen (mach ich grade zum probieren, was die verschiedenes tun und welches mir am liebsten ist).
Maria.

Hallo,
ich habe gerade versucht die App BRouter über Google play auf meinem Handy (Sony Xperia L) zu installieren. Die Installation hat auch geklappt, aber ich kann die Weltkarte dann nicht zoomen, ich habe die App dann auch auf mein Tablet installiert und hier funktioniert es. Liegt es an meinem Handy,oder mache ich etwas falsch?

Über das Tablet habe ich es jetzt hinbekommen und meine erste Strecke navigiert, aber auf dem Handy ist es leider nicht möglich.

Wo finde ich das Read me?

Gruß Sabrina

brina81w wrote:

Hallo,
ich habe gerade versucht die App BRouter über Google play auf meinem Handy (Sony Xperia L) zu installieren. Die Installation hat auch geklappt, aber ich kann die Weltkarte dann nicht zoomen, ich habe die App dann auch auf mein Tablet installiert und hier funktioniert es. Liegt es an meinem Handy,oder mache ich etwas falsch?

Über das Tablet habe ich es jetzt hinbekommen und meine erste Strecke navigiert, aber auf dem Handy ist es leider nicht möglich.

Hi Sabrina,

ich hab' erstmal keine Erklärung dafür, aber der Teufel steckt ja bekanntlich im Detail. Hat er denn die Verzeichnisstrukturen (../brouter, ../brouter/segments2,..) unterhalb des Basisverezcihnisses anlegen können? Kannst Du mal nachschauen mit einem Datei-Manager?

Wenn ja: Du kannst die routing-data-files auch irgendwie anders in das segments2 verzeichnis kopieren, ohne den Download Manager zu benutzen.

Wenn nein: kannst Du es mal mit der anderen (also der internen) Speicherkarte versuchen?

Wo finde ich das Read me?

Das readme ist nicht mehr ganz taufrisch, weil da vom Downloadmanager noch nichts steht:

http://www.brensche.de/brouter/readme.txt

Gruss, Arndt

PS: Ich habe gelesen, dass es bei Android 4.4 zustätzliche Beschränkungen gibt beim Zugriff aus einer App auf die externe Speicherkarte. Hat damit schon jemand Erfahrung? Das Xperia L hat meines Wissens aber Android 4.2 ?

Hallo Arndt,

Im Datei-Manager ist folgende Verzeichnisstrukur angelegt: brouter -> segments2 -> carsubset
Was muss ich jetzt tun um die Routing-data-files in das segments 2 zu kopieren. (Bin in diesen Dingen nicht so bewandert.)
Mein Xperia L hat Android 4.2.2.

Ich habe auf dem Tablet jetzt mal eine Strecke von Twistringen nach Syke, Clues berechnen lassen und er fährt an der Bundesstraße 51 lang. Gibt es eine Einstellungsmöglichkeit, dass über Land und nicht an der Bundesstraße langgefahren wird?
Ich nutze OsmAnd.
Wenn ich unter BRouter ein routing profile auswählen möchte (trekking) kommt folgender Hinweis: Select Action: no from/to Found (coordinate-source:/storage/emulated/o/Locus) : Select from und Server-Mode. Wenn ich dann auf Server-Mode gehe ist hinter bicycle_short und bicycle_fast ein Haken. Muss ich hier noch etwas verstellen? Oder kann/muss ich in OsmAnd noch Einstellungen vornehmen?
Sorry für die blöden Fragen aber ich bin in diesen Dingen und in Englisch leider nicht so bewandert, aber diese App interessiert mich wahnsinnig, da wir gerne und viel Fahrrad fahren.

Gruss Sabrina

Hallo Arndt,

was mir schon länger aufgefallen ist, ist dass beim Routen einige "Sack-Stücke" dabei sind. Bei den Alternativen ist das besonders ausgeprägt. Im Darm nennt man das Divertikel oder Ausstülpungen. Ist das ein Bug oder ein Feature.

Viele Grüsse
Achim

brina81w wrote:

Im Datei-Manager ist folgende Verzeichnisstrukur angelegt: brouter -> segments2 -> carsubset
Was muss ich jetzt tun um die Routing-data-files in das segments 2 zu kopieren. (Bin in diesen Dingen nicht so bewandert.)

Du kannst ja mit dem Tablet vergleichen, welche Dateien das sind. Aber für diese Weltgegend brauchst Du eigentlich nur eine, nämlich E5_N50.rd5 im Verzeichnis brouter/segments2. Am einfachsten geht es, die SD-Karte des Androiden an einem PC über die USB-Verbindung als Laufwerk zu mounten und dann mit dem PC die Dateien zu kopieren. Entweder vom Tablet oder auch direkt von meinem Server unter http://h2096617.stratoserver.net/brouter/segments2/

Ich habe auf dem Tablet jetzt mal eine Strecke von Twistringen nach Syke, Clues berechnen lassen und er fährt an der Bundesstraße 51 lang. Gibt es eine Einstellungsmöglichkeit, dass über Land und nicht an der Bundesstraße langgefahren wird?

Ich hab' mir das angesehen, da ist die B51 durchgängig mit einem separatem Radweg getagged (highway=path, bicycle=designated), und das ist im "trekking" Profil einfach ein guter Weg, auch wenn manche Leute das anders sehen. Man könnte zwar die Datei trekking.brf entsprechend ändern, ist aber keine gute Idee, denn es hat sich ja bewährt, um eben nicht im Gestrüpp zu landen.

Die bessere Lösung für sowas sind daher die Sperrzonen. Ich hab's probiert, wenn Du die Brücke über die Delme bei Binghausen mit einer Sperrzone blockierst, hat der Spuk ein Ende und Du bekommst einen ganz anderen Weg.

Mit der "neuen" Brouter-Online Version kannst Du das auch online testen, die kann nämlich Sperrzonen:

http://h2096617.stratoserver.net/broute … lon=8.6084

In OsmAnd geht das so, dass Du einen Wegpunkt mit Namen "nogo50 Delme Brücke" anlegst.

Ich nutze OsmAnd. Wenn ich unter BRouter ein routing profile auswählen möchte (trekking) kommt folgender Hinweis: Select Action: no from/to Found (coordinate-source:/storage/emulated/o/Locus) : Select from und Server-Mode. Wenn ich dann auf Server-Mode gehe ist hinter bicycle_short und bicycle_fast ein Haken. Muss ich hier noch etwas verstellen? Oder kann/muss ich in OsmAnd noch Einstellungen vornehmen?

Mit der allerneusten OsmAnd Version (1.7.4) kann man die "schnell/kurz" Unterscheidung gut auswählen beim Planen einer Router, Du kannst dann also einen der Haken (bicycle_short oder bicycle_fast) abwählen und so nur den jeweils anderen Modus konfigurieren.

Natürlich musst Du in OsmAnd auch BRouter als NAvigationsdienst auswählen. Geht ab OsmAnd 1.7, wenn BRouter installiert ist, und findet sich irgendwie tief im Menu. Du erkennst, dass wirklich BRouter rechnet und nicht der OsmAnd interne Router daran,. dass aus BRouter keine Fahrzeit-Prognosen kommen und dass BRouter, wie oben dargelegt, auf Sperrzonen reagiert.

Sorry für die blöden Fragen aber ich bin in diesen Dingen und in Englisch leider nicht so bewandert, aber diese App interessiert mich wahnsinnig, da wir gerne und viel Fahrrad fahren.

Gibt da keine blöden Fragen, das Zeugs ist leider etwas kompliziert und nicht gut dokumentiert, und so furchtbar viele Benutzer, die mit Sperrzonen navigieren gibts glaubich auch noch nicht.

womisa wrote:

was mir schon länger aufgefallen ist, ist dass beim Routen einige "Sack-Stücke" dabei sind. Bei den Alternativen ist das besonders ausgeprägt. Im Darm nennt man das Divertikel oder Ausstülpungen. Ist das ein Bug oder ein Feature.

Das glaub ich nicht so richtig, bzw. solche Artefakte erwarte ich nur dann, wenn man die Höhenparameter des Routingprofils ("downhillcost" etc.) drastisch verändert in einen instabilen Bereich. Hast Du dran gedreht? Wenn nicht, kannst Du so ein Beispiel posten? Am besten als Permalink aus der "alten" BRouter-Online-Version:

http://h2096617.stratoserver.net/brouter/online.html

Danke und Gruss,

Arndt

PS: nochmal der Link auch auf die "neue" BRouter-Online-Version, die ist viel schöner und kann Sperrzonen, aber eben (noch) keine Permalinks auf Routen und keinen Profil-Upload:

http://h2096617.stratoserver.net/brouter-web/

Hallo Arndt,

habe die Dateien jetzt vom Tablet über den PC auf das Handy kopiert. Jetzt läuft es auch auf dem Handy.

Ich habe BRouter auch als Navigationsdienst ausgewählt (Einstellungen -> Navigation -> Navigationsdienst -> BRouter).
Er zeigt mir jedoch trotzdem eine Ankunftszeit und Fahrzeit an. Heißt das, es wird nicht mit BRouter gerechnet?

Noch eine Frage zu den Sperrzonen. Heißt Wegepunkte anlegen, als Zwischenziel unter den Favoriten mir dem Namen "nogo50 Delme Brücke" speichern oder wie ist das gemeint?

Ist es eigentlich relevant ob ich unter OsmAnd Fahrrad, Auto oder Fußgänger wähle oder zählt nur die Einstellung unter BRouter. (Die Kartendarstellung als Fußgänger ist nämlich optisch eine andere und gefällt mir persönlich besser)

Ich habe jetzt auch mal Locus heruntergeladen und finde dies von der Darstellung besser als OsmAnd, habe jedoch noch Probleme mit der Handhabung. Ich habe noch nicht rausgefunden, wie man Zwischenziele anlegt.

Zu welcher App kannst du raten? Welche funktioniert mit BRouter besser bzw. ist einfacher oder ist dies nur eine Ansichtssache?

Vielen Dank für deine Hilfe.

Gruß Sabrina

brina81w wrote:

Ich habe BRouter auch als Navigationsdienst ausgewählt (Einstellungen -> Navigation -> Navigationsdienst -> BRouter). Er zeigt mir jedoch trotzdem eine Ankunftszeit und Fahrzeit an. Heißt das, es wird nicht mit BRouter gerechnet?

Sorry, unklar ausgedrueckt, ich meinte die Ansage direkt nach Neuberechnung, per Sprache und über das "Fähnchen", da kommt beim internen Router "Route neu berechnet, Entfernung 4,5 km, Zeit 20 Minuten", und bei BRouter fehlt die Zeit (weil BRouter keine Zeit ausrechnet)

Die Restzeit und Ankunftszeit, die während der Navigation angezeigt werden (wenn konfiguriert), berechnet OsmAnd sich aber dann selbst aus pauschalen Geschwindigkeiten (Auto 60km/h, Fahrrad 20km/h, Fuss 6km/h).

Noch eine Frage zu den Sperrzonen. Heißt Wegepunkte anlegen, als Zwischenziel unter den Favoriten mir dem Namen "nogo50 Delme Brücke" speichern oder wie ist das gemeint?

Einfach als "Favorit" anlegen unter diesem Namen. Zwischenziele sind in OsmAnd was anderes. Mindestens "nogo50" als Namen (kleingeschrieben), die Ergaenzung ist optional und nur wichtig, um später noch zu wissen, was das für ein Wegpunkt ist. Die 50 sind der Radius in Metern, da kann also auch eine andere Zahl stehen. Und nicht "vergessen" die Sperrpunkte, sondern auch irgendwann wieder löschen, aktive Sperrpunkte, an die man nicht mehr denkt spielen böse Streiche.

Ist es eigentlich relevant ob ich unter OsmAnd Fahrrad, Auto oder Fußgänger wähle oder zählt nur die Einstellung unter BRouter. (Die Kartendarstellung als Fußgänger ist nämlich optisch eine andere und gefällt mir persönlich besser)

Für die Wegberechnung ist nur das Profil in BRouter relevant. Beachte aber, dass Du den Navigationsdienst in OsmAnd 3 mal einstellen musst (Auto/Fahhrd/Fuss), es gilt immer nur für einen Modus.

Für die Anzeige der Restzeit/Ankuftszeit macht es aber einen Unterschied, und für das Timing der Sprachansagen und für die Neuberechnungsschwelle bei Weg-Abweichungen auch.

Zu welcher App kannst du raten? Welche funktioniert mit BRouter besser bzw. ist einfacher oder ist dies nur eine Ansichtssache?

Ich kann da keinen Rat geben, es hängt neben dem persönlichen Geschmack auch vom Anwendungsfall ab. Für OruxMaps und Locus spricht, dass sie schönere Vector-Karten anzeigen können (z.B. die openandromaps). Ein Höhenprofil zeigt OsmAnd garnicht an, für Bergtouren nicht ganz unwichtig. Auch tausend andere Funktionen wie z.B. ein Lineal um Entfernungen zu messen fehlen einfach in OsmAnd.

Trotzdem benutze ich persönlich meist OsmAnd, einfach weil ich damit gut zurechtkomme, sowohl mit der Handhabung auch als mit dem Farbschema der Karte bei schwierigem Licht (bei Sonnenschein oder Nachts). Die Handhabung ist in OsmAnd 1.7.x m.E. noch etwas besser geworden und um spontan ein Zeil einzugeben und loszufahren ist das glaubich unschlagbar, während das für längere Touren vielleicht nicht so wichtig ist.

abrensch wrote:

womisa wrote:

was mir schon länger aufgefallen ist, ist dass beim Routen einige "Sack-Stücke" dabei sind. Bei den Alternativen ist das besonders ausgeprägt. Im Darm nennt man das Divertikel oder Ausstülpungen. Ist das ein Bug oder ein Feature.

Das glaub ich nicht so richtig, bzw. solche Artefakte erwarte ich nur dann, wenn man die Höhenparameter des Routingprofils ("downhillcost" etc.) drastisch verändert in einen instabilen Bereich. Hast Du dran gedreht? Wenn nicht, kannst Du so ein Beispiel posten? Am besten als Permalink aus der "alten" BRouter-Online-Version:

http://h2096617.stratoserver.net/brouter/online.html

Danke und Gruss,

Arndt

PS: nochmal der Link auch auf die "neue" BRouter-Online-Version, die ist viel schöner und kann Sperrzonen, aber eben (noch) keine Permalinks auf Routen und keinen Profil-Upload:

http://h2096617.stratoserver.net/brouter-web/

Hallo Arndt,

derzeit bringe ich das nicht mehr dargestellt. An den Parametern habe ich nichts gedreht. War wohl in einer älteren Version?

Also Sorry und vielen Dank für Deinen Brouter

Achim

Hallo Arndt,

eine absurde Frage (?): Kann man von der BRouter API die Höhe eines einzelnen Geo)-Punktes holen OHNE zu routen?

Viele Grüsse
Achim

Ps: Klar die entsprechenden Segmente sind vorhanden

womisa wrote:

eine absurde Frage (?): Kann man von der BRouter API die Höhe eines einzelnen Geo)-Punktes holen OHNE zu routen?

Hi Achim,

so absurd ist das garnicht, ich hatte auch schonmal drüber nachgedacht. Prinizipiell sind die brouter-datenfiles (rd5) dafür aber schlechter geeignet als die originalen SRTM-Files, weil in den rd5's ja die höhe nur an Wegknoten steht und es da kein vollständiges Gitter gibt. Aber um einen vorhanden GPX-track mit höhendaten zu versehen reicht das ja. Sag bescheid, wenn es da einen bedarf gibt.

Gruss, Arndt

Hallo Arndt,

vielen Dank für Deine Antwort.
Der Hintergrund meiner Frage ist, wenn man eine eigene Anwendung schreibt und zB.: BRouter, Graphhopper....... verwendet, bringt jeder seine Höhendaten mit. So werden auch bei RC die SRTM(3) Daten mit. Graphopper läd diese in einer zukünftigen Version runter.
Schön wäre halt, man hätte dies SRTM3 Höhendaten nur einmal zentral für ALLE Anwendungen welche die Höhendaten beötigen. Dafür sollte es dann ein einheitliches Api geben, das man auch als Nutzer verwenden kann.

Schon wäre es auch schon, wenn man über Dein API schon mal die Höhendaten zum nächstligenden Wegknoten holen könnte, das wäre schon mal ein Anfang in dieser Richtung.

Viele Grüsse
Achim

Ps: Was ist wenn BRouter für die Höheninformation auch heruntergeladen SRTM-Datenfiles verwendet di noch anderweitig verwendet werden?

womisa wrote:

Ps: Was ist wenn BRouter für die Höheninformation auch heruntergeladen SRTM-Datenfiles verwendet di noch anderweitig verwendet werden?

Aus dem gleichen Grund, aus dem ich nicht einfach die PBF-Dateien zum Routen verwenden kann: sie sind nicht für den random-access zugriff gemacht, man muss sie sequentiell (also komplett) lesen, um die gesuchte Information zu finden. Ein indiziertes Format für Höhendaten kenne ich nicht. Deswegen muss ich sowohl die OSM/PBF als auch die SRTM Daten im Präprozessor verarbeiten und nicht zur Laufzeit.

Gruss, Arndt

abrensch wrote:

womisa wrote:

Ps: Was ist wenn BRouter für die Höheninformation auch heruntergeladen SRTM-Datenfiles verwendet di noch anderweitig verwendet werden?

Aus dem gleichen Grund, aus dem ich nicht einfach die PBF-Dateien zum Routen verwenden kann: sie sind nicht für den random-access zugriff gemacht, man muss sie sequentiell (also komplett) lesen, um die gesuchte Information zu finden. Ein indiziertes Format für Höhendaten kenne ich nicht. Deswegen muss ich sowohl die OSM/PBF als auch die SRTM Daten im Präprozessor verarbeiten und nicht zur Laufzeit.

Gruss, Arndt

HalloArndt,

das ist aus meiner Sicht und meinem Kenntnisstand nicht ganz richtig. Auf die SRTM-Datenfiles kann man doch mit dem "Random Access" auf den erforderlichen (Integer)-Wert zugreifen. Eventuell muß man 2 Werte holen und dazwischen interpolieren. Was ich mir vorstellen kann ist, dass das beim Routen eventuell zu langsam ist ohne zu cachen.

Oder liege ich da daneben?

Zum Beispiel hat das Routeconverter und ich glaube auch Graphhopper so eingebaut.

Viele Grüsse
Achim

womisa wrote:

Auf die SRTM-Datenfiles kann man doch mit dem "Random Access" auf den erforderlichen (Integer)-Wert zugreifen. Eventuell muß man 2 Werte holen und dazwischen interpolieren. Was ich mir vorstellen kann ist, dass das beim Routen eventuell zu langsam ist ohne zu cachen.

Oder liege ich da daneben?

stimmt wohl, es gibt die ".hgt" Dateien als "Rohformat", aber das ist ja völlig unkomprimiert und da hat der Welt-Datensatz >60 GB, ist also nur solange random-access fähig, bis man es komprimiert.

Der BRouter Prä-Prozessor braucht für den Weltdatensatz zur Zeit ca 5 Stunden, davon das meiste zum De-Komprimieren der SRTM Files, deswegen bin ich schon bisschen auf der Suche nach einem Format, was sowohl kompakt als auch schnell ist (so wie PBF eben)

Zum Beispiel hat das Routeconverter und ich glaube auch Graphhopper so eingebaut.

Bei Graphhopper drücken sie sich ziemlich unklar aus, was die Trennung zwischen Präprozessor (oder Parser oder wie auch immer man das nennt) und Runtime angeht, also glaube ich das erstmal nicht, dass sie zur Laufzeit Random-Access in die HGT Dateien machen. Kann auch nicht performant sein, denn für eine Interpolation muss man da 4 Zahlen lesen aus mindestens 2 Datenblöcken.

Hi Arndt,

vielen Dank für die Erklärung. Ich habe das für ein "begrenztes" Gebiet gesehen und nicht für die ganze Welt. Bei mir liegen nur 4 SRTM Dateien mit ca 3 MB. Leider laden da die einzelnen Utilities jeweils ihre eigenen SRTM Dateien runter.

Wenn man die Höheninformation bei BRouter vom nächsten Wegeknoten holen könnte ohne zu routen, würde mir schon mal was nützen....... da ich Brouter sowieso nutze und nicht nochmals die Höhendaten holen möchte.

Warum ohne zu Routen? Funktion ist eine Luftlinien Entfernung mit Höheninfo. Natürlich kann man auch dazwischen routen und nur den Anfangs und Endpunkt nehmen.

Viele Grüsse
Achim

Hallo Arndt,

Kann ich mit dem in osmand integrierten brouter auch in osmand direkt zwischenziele auswählen? Also mit klick auf die karte und position verwenden als...? Wenn ich das versuche, ignoriert der router meine zwischenziele konsequent... das finde ich sehr schade.

Gruß,
Maria.

korula wrote:

Kann ich mit dem in osmand integrierten brouter auch in osmand direkt zwischenziele auswählen? Also mit klick auf die karte und position verwenden als...? Wenn ich das versuche, ignoriert der router meine zwischenziele konsequent... das finde ich sehr schade.

Ich auch... danke für den Hinweis, ich kümmer mich bei Gelegenheit drum (Bei YOURS und OpenRouteService geht's aber auch nicht..)

PS: noch ein Grund mehr, mit Sperrzonen statt mit Zwischenpunkten zu arbeiten...

Ja, sperrzonen machen schon sinn, wenns darum geht, von a nach b zu kommen und dabei einen bestimmten weg zu vermeiden. Aber wenn ich beispielsweise eine tagestour plane, erst zu dem see da und dann da noch zu dem Hügel und abends dort ankommen, oder eine rundtour oder so... da helfen mir sperrzonen nicht weiter, da muss ich dann immer einzelne wegStücke neu navigieren... oder halt die route extern erstellen und gpx laden... naja, dann also erstmal weiter mit workarounds...
Danke! Maria.

Hallo,

Aber wenn ich beispielsweise eine tagestour plane, erst zu dem see da und dann da noch zu dem Hügel und abends dort ankommen, oder eine rundtour oder so... da helfen mir sperrzonen nicht weiter, da muss ich dann immer einzelne wegStücke neu navigieren

da kann ich Maria zustimmen. Um eine Route oder Tagestour zuplanen wäre es toll, wenn man Zwischenziele auswählen könnte.

LG Sabrina

Hallo,

ich bin ein neuer BRouter user und habe leider schon bei der Installation Probleme. Bei der Berechnung eines Tracks erhalte ich immer die Fehlermeldung "from-position not mapped". Ich habe BRouter schon mehrfach über den Play Store neu auf die ext SD-Karte installiert. Die rd5 Dateien E5_N45, E5_N50, E10_N45 und E10_E50 für DE liegen im Verzeichnis /storage/extSdCard/brouter/segments2. Locus liegt auch im Verzeichnis /storage/extSdCard. Ich habe im Netz schon fast alles über den Fehler gelesen, leider konnte ich ihn bis jetzt nicht beseitigen. Ich nutze BRouter 1.0 zusammen mit Locus Pro 2.20.2. Brauche unbedingt eure Hilfe!

LG Digi

digital4me wrote:

Bei der Berechnung eines Tracks erhalte ich immer die Fehlermeldung "from-position not mapped". Ich habe BRouter schon mehrfach über den Play Store neu auf die ext SD-Karte installiert.

Ich vermute mit den Dateien ist alles in Ordnung, aber der Startpunkt kann darin nicht mapped werden. Er muss innerhalb 250m zu einem routbaren Weg passen. Vielleicht mal den Startpunkt in der Onlineversion testen

Mit der Online Version klappen die Routenberechnungen, ich habe mehrere versucht. Scheint doch an meiner Instaltion auf dem Samsung S II Plus zu liegen. Was kann ich noch versuchen? Möchte unbedungt auf dem Rad und per Pedes mit Locus offline routen können. Schon jetzt, vielen Dank für die Unterstützung.

Gruß Digi

(doppel-post gelöscht)

Hallo Digi,

dummerweise erzeuge ich die gleiche Fehlermeldung in beiden Fällen, egal ob die passende RD5-Datei nicht da ist oder ob in einer solchen Datei kein passender Weg für den Startpunkt gefunden wird - ich werde da die Fehlermeldungen nochmal verbessern müssen.

Du bekommst diese Meldung ("from position not mapped") aber nicht, wenn er garkeine RD5-Datei findet, könnte aber trotzdem sein, dass er in einem anderen Verzeichnis sucht (z.B. auf er internen SD-Karte) und es da auch irgendeine RD5 Datei gibt - also nochmal den Download-Manager aufrufen und den abgedeckten Bereich anschauen, und nochmal mit einem Dateimaneger nach anderen "brouter" Verzeichnissen suchen und die ggf. löschen.

Dann weiss ich nicht, wie Du BRouter aufrufst, es gibt da ja mittlerweile viele Wege: über die Dienste-Schnittstelle direkt aus Locus, über die BRouter-App mit "from" und "to" Wegpunkten in Locus angelegt, oder über die BRouter-App ohne "from" und "to" Wegpunkte.

Probiere mal letzteres, dann hast Du den direktesten Feedback, dass auch tatsächlich der Startpunkt verwendet wird, den Du meinst, also:

- "from" und "to" Wegpunkte in Locus ggf. löschen, wenn Du solche anegelgt hast.
- Deinen Start- und Endpunkt neu anlegen unter irgendwelchen Namen
- die Brouter-App starten: er sagt (nach Profilauswahl) dann: "no from/to found, corrdinate source=..." und dann kannst Du über "Select from" und anschliessend über "Select to/via" Deinen Start- und Zielpunkt aus der Locus-Wegpunktedatenbank wählen
- wenn Du dann über "Calc Route" die Strecke berechnest, dast er dann immer noch "from posution not mapped" ?

Gruss, Arndt

Hallo Arndt,

ich habe alle deine Vorschläge durchgeführt. Da der Download-Manager mir die bei mir auf der SD vorhandenen rd5 Dateien anzeigte, musste der Pfad ja richtig für broiuter gesetzt sein. Die von mir gewählten "froms" lagen alle auf routbaren Hauptstrassen und mit der Online Version von Brouter wurde auch gut geroutet. Dann kam mir der Gedanke doch mal in der Nähe von Stuttgart zu routen und siehe da, Brouter routete offline plötzlich einwandfrei. Meine E5N50 scheint defekt zu sein, mit E5N45, E10N50 und E10N45 kann ich sauber routen. Ich lade mir gerade die E5N45 (mein Heimatbereich) nochmal herunter. Ich möchte mich sehr für deine Hilfe und natürlich für das tolle Programm bedanken.

Gruß Digi

Hallo Arndt,

ich beschäftige mich seit ein paar Tagen mit BRouter (in Verbindung mit Locus Pro) und hätte Fragen zu den Routing-Optionen (Fastbike):

Ich fahre zwar kein Rennrad oder S-Pedelec o.ä., sondern ein schnelles Velomobil und frage mich, ob & wie ich folgende Streckenbestandteile "abschalten" bzw. runterstufen kann, damit diese möglichst selten geroutet werden:

- keine Radwege
- keine größeren Städte

Prinzipiell will ich möglichst fahren auf:

- Kreisstraßen (K<Nummer>)
- Straßen mit Seitenstreifen

Gibt es in der Richtung Möglichkeiten, die Routing-Optionen zu "optimieren"?

+++

Weiterhin ist mir aufgefallen, dass bei längeren Strecken (300 - 400 km ausprobiert) es doch eine ganze Weile dauert, bevor BRouter die Route in zwei Durchläufen ermittelt hat und das dabei relativ breit Punkte auf dem Display gesetzt werden. Mir ist einigermaßen klar, welcher Aufwand dahintersteckt, aber wäre nicht eine Option denkbar, die bspw. in einem Korridor von x km (einstellbar) der Luftlinie sucht? Also Punkt A und B durch Luftlinie verbinden und die Route muss innerhalb eines Korridors von 10 km von dieser Luftlinie verlaufen.

Danke,

Gruß: - Reinhard -