BRouter Version 1.5.5

[zossebart]

@gynta: Arndt ist wirklich nicht der richtige Ansprechpartner für diese Frage!

Der "iswet"-Parameter ist einfach nur eine Variable in den Profilen von Poutnik. Brouter selbst kennt diese Variable nicht (es ist kein eingebautes Schlüsselwort wie zum Beispiel "costfactor", "uphollcostfactor" oder "initialcostfactor"). Die Variable steuert in Poutnik's Profilen einfach nur die Gewichtung verschiedener Wegtypen. Je nach Gewichtung kommt dann ein anderer costfactor heraus. Brouter sucht dann einfach die Route mit dem geringsten costfactor (ein bisschen vereinfacht ausgedrückt).

Ich finde es eine gute Idee, diesen Parameter über das Userinterface von Locus umschaltbar zu machen. Ich selbst habe so einen (ähnlichen) Parameter in meinem eigenen MTB-Profil auch eingebaut, muß aber im Moment auch noch zwei unterschiedliche Profile daraus erstellen (einmal mit gesetztem "iswet"-flag und einmal ohne). Aufgrund der 5 zur Verfügung stehenden Profilzuordnungen in Locus habe ich die iswet-Variante aber nie verwendet, da ich alle Slots mit anderen Profilen belegt habe. Mit dem neuen Interface wäre das schnell umschaltbar und mit nur einem Profil realisierbar.
Die Erklärung zu einzelnen Parametern wie "iswet" muss aber jeder Profil-Ersteller selbst geben, da es sich nicht um einen allgemeinen Brouter-Parameter handelt. Aus diesem Grund ist Poutnik's WIKI der einzig richtige Ort, um sich über die Bedeutung des Flags in seinen Profilen zu informieren. Ich finde seine WIKI-Dokumentation zu dem Flag meiner Meinung nach mehr als ausreichend (mehr als nötig sein sollte). Er hat sich da wirklich viel Mühe gegeben! Im Allgemeinen hat er viel Arbeit in diese Profil-Templates gesteckt. Er ist vermutlich der einzige, der für mehrere Fortbewegungsarten so ausgefeilte und parametrisierbare Profile erarbeitet hat. Deshalb hat Menion sicher auch seine Profile für den Einbau in Locus ausgewählt (zu Recht wie ich finde).

Für mein eigenes MTB-Profil würde ich den iswet-Parameter wie folgt erklären (ähnlich zu Poutnik's Variante):
Der Sinn in meinem Fall ist einfach, dass ich als Mountainbiker Straßen, welche durch KFZ befahren werden, meide (man könnte sogar fast sagen, ich habe eine starke
Abneigung gegen laute, stinkende Fahrzeuge). Mein "normales" MTB-Profil bevorzugt deshalb vor allem Wald/Feldwege bergauf und schmale Pfade bergab.
Wenn ich aber kurz nach einem (starken) Regen eine Runde fahren will, sind mir einige dieser Pfade zu gefährlich (auch ein noch so grobstolliger Reifen kommt irgendwann an seine Grenzen). Mit dem iswet-Parameter kann ich die Routenberechnung eher weg von potenziell schlüpfrigen/glatten/klebrigen Wegen (zum Beispiel mit Oberfläche Gras oder Erde) mehr in Richtung gut ausgebauter Wald/Feldwege verschieben. Ich werde dann immer noch eher über Felder und durch Wälder geroutet, aber eben eher nicht mehr über potenziell (wegen der Nässe) gefährliche Pfade.
Das heißt aber nicht, dass solche Wege ganz umgangen werden, sie werden nur mit einer höheren "Strafe" belegt als sonst. Wenn ein Umweg um einen solchen Weg herum viel zu lang wird, würde der Router trotzdem noch diesen Weg wählen.

Gruß,
Zossebart

[ppiter]

@gynta: Arndt ist wirklich nicht der richtige Ansprechpartner für diese Frage!

Der "iswet"-Parameter ist einfach nur eine Variable in den Profilen von Poutnik. Brouter selbst kennt diese Variable nicht (es ist kein eingebautes Schlüsselwort wie zum Beispiel "costfactor", "uphollcostfactor" oder "initialcostfactor"). Die Variable steuert in Poutnik's Profilen einfach nur die Gewichtung verschiedener Wegtypen. Je nach Gewichtung kommt dann ein anderer costfactor heraus. Brouter sucht dann einfach die Route mit dem geringsten costfactor (ein bisschen vereinfacht ausgedrückt).

Ich finde es eine gute Idee, diesen Parameter über das Userinterface von Locus umschaltbar zu machen. Ich selbst habe so einen (ähnlichen) Parameter in meinem eigenen MTB-Profil auch eingebaut, muß aber im Moment auch noch zwei unterschiedliche Profile daraus erstellen (einmal mit gesetztem "iswet"-flag und einmal ohne). Aufgrund der 5 zur Verfügung stehenden Profilzuordnungen in Locus habe ich die iswet-Variante aber nie verwendet, da ich alle Slots mit anderen Profilen belegt habe. Mit dem neuen Interface wäre das schnell umschaltbar und mit nur einem Profil realisierbar.
Die Erklärung zu einzelnen Parametern wie "iswet" muss aber jeder Profil-Ersteller selbst geben, da es sich nicht um einen allgemeinen Brouter-Parameter handelt. Aus diesem Grund ist Poutnik's WIKI der einzig richtige Ort, um sich über die Bedeutung des Flags in seinen Profilen zu informieren. Ich finde seine WIKI-Dokumentation zu dem Flag meiner Meinung nach mehr als ausreichend (mehr als nötig sein sollte). Er hat sich da wirklich viel Mühe gegeben! Im Allgemeinen hat er viel Arbeit in diese Profil-Templates gesteckt. Er ist vermutlich der einzige, der für mehrere Fortbewegungsarten so ausgefeilte und parametrisierbare Profile erarbeitet hat. Deshalb hat Menion sicher auch seine Profile für den Einbau in Locus ausgewählt (zu Recht wie ich finde).

Für mein eigenes MTB-Profil würde ich den iswet-Parameter wie folgt erklären (ähnlich zu Poutnik's Variante):
Der Sinn in meinem Fall ist einfach, dass ich als Mountainbiker Straßen, welche durch KFZ befahren werden, meide (man könnte sogar fast sagen, ich habe eine starke
Abneigung gegen laute, stinkende Fahrzeuge). Mein "normales" MTB-Profil bevorzugt deshalb vor allem Wald/Feldwege bergauf und schmale Pfade bergab.
Wenn ich aber kurz nach einem (starken) Regen eine Runde fahren will, sind mir einige dieser Pfade zu gefährlich (auch ein noch so grobstolliger Reifen kommt irgendwann an seine Grenzen). Mit dem iswet-Parameter kann ich die Routenberechnung eher weg von potenziell schlüpfrigen/glatten/klebrigen Wegen (zum Beispiel mit Oberfläche Gras oder Erde) mehr in Richtung gut ausgebauter Wald/Feldwege verschieben. Ich werde dann immer noch eher über Felder und durch Wälder geroutet, aber eben eher nicht mehr über potenziell (wegen der Nässe) gefährliche Pfade.
Das heißt aber nicht, dass solche Wege ganz umgangen werden, sie werden nur mit einer höheren "Strafe" belegt als sonst. Wenn ein Umweg um einen solchen Weg herum viel zu lang wird, würde der Router trotzdem noch diesen Weg wählen.

Gruß,
Zossebart

Hallo zossebart,

die Beschreibung von deinem MTB Profil klingt sehr interessant.  Würdest du es zur Verfügung stellen?  Entweder als PM oder direkt hier. Habe selbst mal mit eigenen Profilen experimentiert bin aber nicht weit gekommen.

Poutnikl MTB Profil nutze ich dagegen gerne. Besten Dank dafür!

[gynta]

Ich wollte keineswegs in den Raum stellen, daß dieses Profilflag generell sinnlos ist. Einzig für mich(!) pers. als User hatte ich einfach noch zu wenig Infos über das Verhalten (und die Sinnhaftigkeit) - in meinem Anwendungsbereich. Auch für all jene Nutzer die mit der englischen "Beschreibung" hier nichts anfangen können, waren Deine Zeilen hilfreicher als zig andere (gut gemeinte) postings.

Wenn ich aber kurz nach einem (starken) Regen eine Runde fahren will, sind mir einige dieser Pfade zu gefährlich (auch ein noch so grobstolliger Reifen kommt irgendwann an seine Grenzen). Mit dem iswet-Parameter kann ich die Routenberechnung eher weg von potenziell schlüpfrigen/glatten/klebrigen Wegen (zum Beispiel mit Oberfläche Gras oder Erde) mehr in Richtung gut ausgebauter Wald/Feldwege verschieben. Ich werde dann immer noch eher über Felder und durch Wälder geroutet, aber eben eher nicht mehr über potenziell (wegen der Nässe) gefährliche Pfade.
Das heißt aber nicht, dass solche Wege ganz umgangen werden, sie werden nur mit einer höheren "Strafe" belegt als sonst. Wenn ein Umweg um einen solchen Weg herum viel zu lang wird, würde der Router trotzdem noch diesen Weg wählen.

Genau darum ging es mir in meiner Fragestellung. (s. hier)

Diese (möglichst) zu vermeidenden Wege sind also normalerweise vorher trocken und normal befahrbar.
Es geht hier nicht um Wege die sich ohnehin schon auf sumpfigen morastigen Gelände befinden.

Dies zwei Zeilen hätten mir als Antwort genügt... 
Danke dafür.

[abrensch]

(Eine Redewendung - falls google hierbei hängt )

"Schuster, bleib bei Deinen Leisten", fällt mir da ein, und ist Spezialisierung nicht der Motor des Fortsschritts?

Ich verwende aktuell nicht viel Zeit, Routing Profile zu tunen oder zu reviewen.

Aber dass man bei Regenwetter anders routen muss als bei trockenem war mir immer klar, und im "fastbike" Profil steht ja auch im Header, dass es auch als Fallback gedacht ist für Regenwetter oder nachts.

Ich bin mir aber nicht sicher, ob es bei diesem neuen Profil-Mapping in Locus einen wirklichen Unterschied gibt zwischen "Schnell" und "Kurz +  isWet". Weil nur, wenn man diesen Unterschied erklären kann macht es Sinn, beides zu pflegen. Für MTB hat Zossebart ja gerade erkärt, dass es diesen Unterschied gibt.

Was mir noch fehlt bei den Optionen sind die klassischen, objektiven Flags wie "keine Treppen", "keine Fähren" etc. Die sind auch alle im "trekking" Profil drin, wäre wirklich schön, wenn man die auch in die Locus-Konfiguration rein bekommt.

Und was mich bisschen stört bei diesem diesem neuen Profil-Mapping ist, dass das Default Profil für Fahrrad, also das, was ein Benutzer verwenden soll, der nie darüber nachgedacht hat, mehr Rechenzeit braucht als mein "trekking" Profil, einfach weil es einen grösseren durchschittlichen Kostenfaktor hat, und ich glaube nicht, dass es dafür einen wirklichen Grund gibt. Und ich möchte nicht die Diskussion über Performance und Timeouts führen, wenn an dieser Stelle wieder Performance verschenkt wird.

[zossebart]

Was mir noch fehlt bei den Optionen sind die klassischen, objektiven Flags wie "keine Treppen", "keine Fähren" etc. Die sind auch alle im "trekking" Profil drin, wäre wirklich schön, wenn man die auch in die Locus-Konfiguration rein bekommt.

Darüber lässt sich sicher mit Menion reden.

Eine andere Idee wäre eventuell, bestimmte, zur Änderung über das User-Interface gedachte Parameter im Profil irgendwie als solche zu markieren. Locus könnte dann automatisch eine Liste mit Optionen generieren und im UserInterface als an/ausschaltbar anzeigen. Natürlich müßte man die Anzahl beschränken, und der Anzeigename bzw. die Übersetzung ist damit auch nicht geklärt. Aber vielleicht könnte man ja mal darüber nachdenken, ob es da eine Lösung gäbe? Oder geht die Überlegung zu weit?

[poutnikl]

Aber dass man bei Regenwetter anders routen muss als bei trockenem war mir immer klar, und im "fastbike" Profil steht ja auch im Header, dass es auch als Fallback gedacht ist für Regenwetter oder nachts.

Google translated
Aus meiner Sicht kann FASTBIKE zuviel des Guten sein, während Trekking-nass noch die Trekking Natur der Fahrt zu halten versucht.
Aber beachten Sie, dass meine Profile sollen den Standard einer Ergänzung, nicht als bessere zu ersetzen.
Ich habe in keiner Weise geschoben Menion Standardprofile verzichtet werden kann. :-)

In my view, Fastbike may be an overkill, while Trekking-wet still tries to maintain the trekking nature of the ride.
But note that my profiles are intended to complement the standard one, not to replace them as better ones.
I have by no means pushed Menion to omit standard profiles. :-)

Ich bin mir aber nicht sicher, ob es bei diesem neuen Profil-Mapping in Locus einen wirklichen Unterschied gibt zwischen "Schnell" und "Kurz +  isWet". Weil nur, wenn man diesen Unterschied erklären kann macht es Sinn, beides zu pflegen. Für MTB hat Zossebart ja gerade erkärt, dass es diesen Unterschied gibt.

Inselchen ist als Flag-Parameter bestimmt und verschiebt sich die Präferenz speziell Wetterbedingungen , mit fest codierten Verschiebungswerte bzgl.

Trekking-Fast ist als eigenständiges Profil bestimmt, abgesehen von einigen anderen, mit fest einprogrammiert bestimmten Wert von MTB_factor numerischen Parameter. Der Faktor verschiebt Präferenzen mit Stämmen auf einer Seite der figürlichen Linie Kippen und Pfade auf der anderen Seite.

Ähnliche Wirkung hat Faktor smallpaved, das macht Biegen.

BTW, ich frage mich, wenn niemand außer Zossebart liest mein GitHub Wiki überhaupt ....

Iswet is intended as flag parameter and shifts the preference specifically wrt weather conditions, with hardcoded shift values.

Trekking-Fast is intended as independent profile, aside of several others, with hardcoded particular value of MTB_factor numerical parameter. The factor shifts preferences by tilting of figural line with trunks at one side and paths at the other.

Similar effect has smallpaved factor, that makes bending.

BTW, I wonder, if nobody but Zossebart reads my GitHub wiki at all....

Was mir noch fehlt bei den Optionen sind die klassischen, objektiven Flags wie "keine Treppen", "keine Fähren" etc. Die sind auch alle im "trekking" Profil drin, wäre wirklich schön, wenn man die auch in die Locus-Konfiguration rein bekommt.

Nun, ich unterstütze , dass diese Optionen zur Verfügung stehen sollten. Aber es ist es wert, dass die Nachfrage zu berücksichtigen Treppe von Fähren zu vermeiden, gering sein kann. So können die Flags nicht sehr nützlich sein für die meisten Benutzer, und sie können besser durch die alternative Profile bedient. In eingehenden Locus Version wird ein Benutzer in der Lage sein, in Locus abzubilden jedes Profil, wie er jetzt im brouter kann.

Well, I support that these options should be available. But it is worthy to consider that demand to avoid stairs of ferries may be minor. So the flags may not be very useful for most of users and they may be better served by the alternative profiles. In incoming Locus version, a user will be able to map in Locus any profile as he can in BRouter now.

Und was mich bisschen stört bei diesem diesem neuen Profil-Mapping ist, dass das Default Profil für Fahrrad, also das, was ein Benutzer verwenden soll, der nie darüber nachgedacht hat, mehr Rechenzeit braucht als mein "trekking" Profil, einfach weil es einen grösseren durchschittlichen Kostenfaktor hat, und ich glaube nicht, dass es dafür einen wirklichen Grund gibt. Und ich möchte nicht die Diskussion über Performance und Timeouts führen, wenn an dieser Stelle wieder Performance verschenkt wird.

Nun, Arndt, sorglos zu sprechen, haben Sie mich in Vergangenheit betrogen und jetzt beklagen Sie, dass ich den Köder ... :-D geschluckt haben

Ich habe kein Problem, noch würde ich fühle mich beleidigt, wenn Standard Brouter Profile standardmäßig in der Locus Brouter Konfiguration zugeordnet sind.

Beim Start meine Profile zu entwickeln, habe ich fragen Sie ausdrücklich über die Leistung und wenn ich lieber etwas anspruchs Code vermeiden sollte structures.You haben mir gesagt, dass die Verarbeitung von Profilen ist sehr effizient, und die Kosten sind gering, im Vergleich zu anderen Aktivitäten.
So hatte ich dies im Auge behalten. :-)

In Bezug auf Leistung, wäre es wert sein Auswertung von Ausdrücken Variablen zugewiesen zu implementieren, werden nur dann, wenn ihre Variablen genannt. Wie ich mich erinnere Sie mir gesagt haben, ist es nicht so gemacht. (Ich bin nicht sicher richtige Begriff für eine solche Skriptverarbeitung so, ich denke Rückzieher. Begriff wurde zum Beispiel in AviSynth Videoverarbeitung Skripte)

Denn jetzt, denke ich Coder freundlich variable System effizienter, aber weniger Aussicht freundlich variableless man sactifice.

Schließlich, ich schätze alles, was Sie harte Arbeit auf brouter wirklich, ich hoffe nur, dass ich irgendein Stück wothy Beitrag leisten.

Well, Arndt, light-hearted speaking, you have cheated me in past and now you complain I have swallowed the bait...  :-D 

I have no problem nor I would feel offended if standard Brouter profiles are assigned by  default in the Locus Brouter configuration.

When starting to develop my profiles, I have explicitly ask you about performance and if  I should rather avoid some demanding code structures.You have told me that processing of profiles is very efficient and the cost is minor, compared to other activities.
So I had this in mind.  :-)

Regarding performance, it would be worthy to implement  evaluation of expressions assigned to variables only if their variables are called. As I remember you have told me it is not done this way.  ( I not sure about proper term for such a script processing way, I guess backtracking. term was used  e.g. in AviSynth video processing scripts)

For now, I am thinking to sactifice coder friendly variable system to more efficient but less view friendly variableless one.

Finally, I really appreciate all you hard work on BRouter, I just hope I provide some piece of wothy contribution.

[poutnikl]

[...]
Eine andere Idee wäre eventuell, bestimmte, zur Änderung über das User-Interface gedachte Parameter im Profil irgendwie als solche zu markieren. Locus könnte dann automatisch eine Liste mit Optionen generieren und im UserInterface als an/ausschaltbar anzeigen. Natürlich müßte man die Anzahl beschränken, und der Anzeigename bzw. die Übersetzung ist damit auch nicht geklärt. Aber vielleicht könnte man ja mal darüber nachdenken, ob es da eine Lösung gäbe? Oder geht die Überlegung zu weit?

Arndt bereits erwähnt, eine allgemeine Bemerkung basierte Idee, die ich sehr mag.

Wie anstelle von

Code Select Expand

assign parameter value
zu haben, so etwas wie

Code Select Expand

assign parameter value # %Parameter% Locus_GUI_name | Locus_GUI_description

Ich denke, Locus sollte nur ersten 3-4 Parameter (AFAIK MapQuest hat 4).


Arndt mentioned earlier a general comment based idea I like very much.

Like instead of

Code Select Expand

assign parameter value
to have something like

Code Select Expand

assign parameter value  # %parameter%   Locus_GUI_name|Locus_GUI_description

I guess Locus should consider only first 3-4 parameters ( AFAIK MapQuest has 4 ),.

[zossebart]

[...]
Eine andere Idee wäre eventuell, bestimmte, zur Änderung über das User-Interface gedachte Parameter im Profil irgendwie als solche zu markieren. Locus könnte dann automatisch eine Liste mit Optionen generieren und im UserInterface als an/ausschaltbar anzeigen. Natürlich müßte man die Anzahl beschränken, und der Anzeigename bzw. die Übersetzung ist damit auch nicht geklärt. Aber vielleicht könnte man ja mal darüber nachdenken, ob es da eine Lösung gäbe? Oder geht die Überlegung zu weit?

Arndt bereits erwähnt, eine allgemeine Bemerkung basierte Idee, die ich sehr mag.

Wie anstelle von

Code Select Expand

assign parameter value
zu haben, so etwas wie

Code Select Expand

assign parameter value # %Parameter% Locus_GUI_name | Locus_GUI_description

Ich denke, Locus sollte nur ersten 3-4 Parameter (AFAIK MapQuest hat 4).


Arndt mentioned earlier a general comment based idea I like very much.

Like instead of

Code Select Expand

assign parameter value
to have something like

Code Select Expand

assign parameter value  # %parameter%   Locus_GUI_name|Locus_GUI_description

I guess Locus should consider only first 3-4 parameters ( AFAIK MapQuest has 4 ),.

That's exactly what I thought of! Where is this mentioned by Arndt, I think I missed this?
Is there a corresponding idea in Locus Helpdesk already?

[poutnikl]

That's exactly what I thought of! Where is this mentioned by Arndt, I think I missed this?
Is there a corresponding idea in Locus Helpdesk already?

http://forum.locusmap.eu/index.php?topic=5199.msg44479#msg44479

Beachten Sie, dass ich bereits dieses System zu einigen Flaggen in Autoprofilvorlage implementiert Pre.
( Note that I have already pre implemented this system to some flags in Car profile template.)

Edit:   http://help.locusmap.eu/topic/dynamic-brouter-profile-configuration

[zossebart]

Hallo ppiter,

Hallo zossebart,

die Beschreibung von deinem MTB Profil klingt sehr interessant.  Würdest du es zur Verfügung stellen?  Entweder als PM oder direkt hier. Habe selbst mal mit eigenen Profilen experimentiert bin aber nicht weit gekommen.

Poutnikl MTB Profil nutze ich dagegen gerne. Besten Dank dafür!

Eine (sehr alte) Version meines MTB-Profils gibt es hier: https://groups.google.com/forum/#!searchin/osm-android-bikerouting/brouter$20mtb$20profile$20/osm-android-bikerouting/ACQWNUsEsEM/rNsJJQpL60wJ
Da habe ich in der Zwischenzeit schon wieder einiges verändert (u.a. Treppen-Handling, Einbeziehung von abgeschätzter Verkehrsdichte und Maxspeed bei großen Straßen, Aktivierung von Abbiegehinweisen).

Ich müßte das aber alles nochmal in Ruhe überarbeiten, wozu ich noch nicht gekommen bin :-(
Danach veröffentliche ich vielleicht auch mal die neuere Version.

Im Übrigen lautet der isWet-Parameter bei mir "slippery_muddy_penalty" und ist nicht auf Werte zwischen 0 und 1 begrenzt. In der Regen-Variante des Profils verwende ich aber den Wert 2. Das könnte man also auch einfach mit einem zusätzlichen Parameter umschaltbar machen.

[ppiter]

Hallo zossebart,

vielen Dank werde ich mir mal anschauen

[FXP_Freak]

Hallo, ich bräuchte mal eure Unterstützung da ich selbst nicht mehr weiter weiss wo das Problem liegt.
Und zwar bin ich momentan in Österreich um zu wandern, aber mit Brouter klappt es nicht.

Ich wollte zb vom Parkplatz (N47 26.335 E11 50.807 ) zur Bayreuther Hütte ( N47 26.699 E11 49.250 ) wandern, aber Brouter kann mir keine Strecke berechnen. Kommt nur das Berechnungsfenster und irgendwann ist das Fenster ohne Meldung weg.
Als ich dann vorhin unterwegs war, hab ich es nochmal probiert. Im Fußgänger Modus hat es wieder nicht geklappt, allerdings im Fahrrad Schnell Modus ( allerdings auch nur in diesem ), wobei da ständig diese Timeout 60 Meldung kommt wie auf dem Foto zu sehen.  Aber die Berechnung teilweise war nicht ganz sinnfrei, da mich Brouter ein Umweg laufen lassen wollte. Siehe Fotos im Anhang.

Ganz hoch zum See auf dem Berg ( N47 27.819 E11 48.770 ) hat die Berechnung überhaupt nicht hingehauen. Egal was ich probiert habe.

Wäre schön wenn mir jemand bei meinen Problemen helfen könnte diese zu beseitigen. Da ich schon gerne wegen meinem Hund im vorraus wissen würde wieviel Km und Hm es sind.

Würde nun gerne wissen was ich anstellen muß damit ich die Entfernung von 2 Wegpunkten berechnen kann auf kürzestem Weg und wie ich vermeiden kann das Brouter mich auf Umwegen zum Ziel navigieren will.

Schonmal Danke für eure Tipps :-)

[Christian]

Wahrscheinlich hast Du eine Unordnung in der Zuordnung der Profile in Brouter (Server mode). Bei mir routet er erwartungsgemäß. Sind 7,73km / 1335hm bis auf den Latschberg.

Viel Spaß beim Wandern.

[abrensch]

Wäre schön wenn mir jemand bei meinen Problemen helfen könnte diese zu beseitigen. Da ich schon gerne wegen meinem Hund im vorraus wissen würde wieviel Km und Hm es sind.

Hab' das heute morgen im Zug getestet, und natürlich, in Bayern alles prima, aber als ich dann ausgestiegen bin und wollte die letzten 5km an mein Ziel radeln (dass ich im Zug schon eingegeben hatte, vor dem GPX-Fix), da hätte ich das Ding an die Wand schmeissen können und war genauso frustiert wie Du.

Zufällig hatte ich das debug-log aktiv und kann sehen, was passiert war: Locus wollte partout nach Bayern! Hat auch so eine gestrichelte Linie gemalt mit 383km, und auch wenn ich "Navigation beenden" und neue Zieleingabe gemacht habe, wollte der immer noch nach Bayern.

Alles, was geholfen hat war, Locus richtig zu beenden (also nicht nur in den Hintergrund drücken) und neu starten.

Passiert ist das mit Version 3.18.7

Wenn Du solche Effekte hast, einfach mal den Request, der den Timeout gemacht hat, mit der BRouter-App nachrechnen ( "<repeat timeout> shortcut in der aktuellen Version BRouter 1.4.5 ). Dann sieht da ja sofort, wo Locus Dich hinschicken wollte.

Oder, wenn Du die Bordmittel dazu hast, auch mal das debug-log aktivieren: dazu eine leere Datei mit Namen "debug.txt" in das Basisverzeichnis von BRouter legen. Und wenn nach so einem Fehler dann da was drinsteht, diese Datei hier anhängen.

[Hans_55]

Hallo alle,
es ist bei mir nicht möglich, längere Routen als ca. 80 Km mit dem BRouter zu routen; sonst immer timeout.
Gerät Samsung TabS 10.5 LTE
aktuelle BRouter-Version
aktuelle Infrastrukturdaten
aktuelle Version Locus pro
Erstellung der Wegbeschreibung ist abgestellt, weil zusätzliches Problem

Woran könnte das liegen? Oder ist das normal?
Ich kann natürlich auch stückweise routen - aber das ist ja nicht so gewollt, denke ich.

Danke und Gruß
Hans