Messages

ich bitte um eine verständliche Erklärung added turncost as start-direction bias (locus only) am besten an einem Beispiel

Menion hat in die Aufrufschnittstelle zwei neue Parameter eingebaut, mit denen erreicht werden soll, dass eine dynamische Neuberechung mehr "nach vorne" geht und nicht schon veraltet ist in dem Moment, wo sie angezeigt wird:

- direction
- noManveuverTime

Nur ist das so zu Zeit nicht machbar, weil würde einige der strukturellen Änderungen erfordern, die auch für Abbiegebeschränkungen notwendig sind.

Aber das, was ich leicht tun kann, hab' ich gemacht: ich benutze die aktuelle Start-Richtung und rechne für den ersten Wegschritt die Winkelkosten relativ zu dieser Startrichtung genau, wie jeden anderen Winkel auch.

Dadurch rückt der Punkt, ab dem die Vorwärtslösung gewinnt, um "turncost/costfactor" Meter nach vorne man bekommt also in mehr Fällen schon bei der ersten Neuberechnung die Vorwärtslösung.

Aber wie gesagt, nur ein leichter Bias, noch kein Navi mit künstlicher Intelligenz, das raten kann, was man vorhat.

.. but in this example it´s only one forest path leading left i have to go and  not a  multi-lane highway.

There's a grade5 track going to the east, maybe it's not really visible:

http://brouter.de/brouter-web/#zoom=19&lat=48.919378&lon=8.867397&layer=OpenStreetMap&lonlats=8.866785,48.919824|8.867989,48.919198&nogos=&profile=trekking&alternativeidx=0&format=geojson

Only grade1 tracks get a higher "priority classifier",  your grade2 and this grade5 are considered equal-priority, and therefore you get the keep-right hint.

arrow on map "keep left" thats ok, but top left icon advice me to go right ?

It's the other way round: go left but keep right. It's perfectly reasonable to go left but keep right, if there are two close-by choices on the left side. Unfortunatly, a navigation command can only express one aspect so sometimes you have to decide and in a complex situation there are cases where it's confusing

Auf das debug-log von fxp-freak kann ich mir keinen Reim machen - es sagt, dass eine Position nur ca 10m  von der fehlerhaften weg vorher gematched hat, gegen das gleiche Profil. Weil sich diese Berichte häufen über "to-position not mapped" werde ich nochmal eine Runde drehen und die letzten Änderungen  am Profil-Cache besser testen. Selbst bin ich aber noch auf keinen Fehler gestossen.

Den anderen Fehler, dass Locus eine Navigation zu einem weit entfernten Zielpunkt nicht mehr beenden kann und in einer Endlos-Timeout Schleife feststeckt, habe ich auch im den aktuellen Prod- und Betas gwfunden, also da muss Menion noch mal ran.

Woran könnte das liegen? Oder ist das normal?

Ja das ist normal, die Rechenzeit steigt quadratisch mit der Entfernung und irgendwo ist da bei 60 Sekunden Timeout eine Grenze.

Du kannst aber nach dem Timeout die BRouter-App starten und über den "<repeat timeout>" Shortcut die Berechnung zuende rechnen.

Wenn Du danach aus Locus herraus nochmal die gleiche Anfrage machst (exakt gleicher Zielpunkt, ungefähr gleicher Startpunkt) dann geht diese Anfrage schnell und gibt keinen Timeout mehr. Und alle nachgelagerten Neuberechnungen auch nicht.

Ich kann natürlich auch stückweise routen - aber das ist ja nicht so gewollt, denke ich.

Um anfänglich die Routen-Idee zu gewinnen muss man schon komplett rechnen, weil mit Zwischenpunkten legt man sich ja zu früh fest. Aber wenn man die Idee mal hat würde ich das Routing schon auf Tagesetappen begrenzen, das macht das Handling einfacher.

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.

Meines Wissens sind POI, was ja die übergebenen "via"-Punkte sind, im GPX auch nur einfache Wegpunkte <wpt>

Ja genau, ein von BRouter generiertes GPX (egal ob das als brouter0.gpx gespeicherte oder das über die Service-Schnittstelle zurückgelieferte) enthält keinerlei Information mehr über die Zwischenpunkte, die zu seiner Berechnung genutzt wurden.

Da "nogo" Areas bei der Neuberechnung aber korrekt behandelt werden, scheint die Übergabe dieser Daten eine Angelegenheit des Service-Interface (API) zu sein.

Die Nogo's werden von Locus nicht im Service-Interface übergeben, sondern ich suche sie bei jedem Request selbst in der Wegpunkte-Datenbank von Locus ( Locus/data/database/waypoints.db )

Ich arbeite zwar dran, Menion zu überzeugen, ein explizites Konzept für Nogo's in Locus einzuführen, sie also auch als Sperrkreise darzustellen und über die Schnittstelle zu senden, aber das ist eher in weiter Ferne.

Generell ist das Thema Neuberchnung mit Zwischenzielen ja nicht so einfach, ich hab' da zumindest kein Konzept für. Man könnte es natürlich so machen, einen Zwischenpunkt "abzuhaken", wenn man ihm nah genug (? wie na ist das) gekommen ist. So macht es OsmAnd, aber auch da beschweren soch ja die Nutzer, das das mit dem Abhaken wohl nicht so funktioniert wie sie das erwarten, und man dann fummeln muss, um den Router zu überzeugen, das nächste Zwischenziel anzusteuern.

Deswegen gefällt mir die Lösung besser, Routen-Präferenzen über Nogo's zu erwzingen, weil da gibt es keine konzeptionellen Probleme.

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

Hallo, ich geb' hier mal eineFrage weiter, die mich per email erreicht hat, aber mehr Locus als BRouter betrifft und die ich als Locus-Legasteniker nicht wirklich beantworten kann. Ich schick dem Frager noch den Link nach hier.

Gruss, Arndt

==============================================================

Hallo

Ich wähle den direkten Weg, da es mir seit Tagen nicht gelingen will mich bei http://forum.locusmap.eu zu registrieren.

Folgendes Problem ist aufgetreten:

In Locus definiere ich eine Strecke abseits meiner derzeitigen Position mittels START -> VIA -> ZIEL mit "Punkt schnell einfügen".
Danach wird über die angelegte Locus-Verknüpfung die BRouter App gestartet, welche die Berechnungen ausführt.
Diese verlasse ich über "SERVER-MODE" -> "EXIT".

Jetzt öffne ich in Locus die soeben erstellte brouter0.gpx, welche auch korrekt angezeigt wird und wähle, durch antippen der Route und öffnen des Untermenü über den kleinen Pfeil, "Navigieren". Nach einer kurzer Neuberechnung, ich befinde mich ja noch immer abseits der Route, werde ich sofort zum Endpunkt der Route geführt, sämtliche Zwischenziele werden dabei ignoriert.

Die Einstellung für "Automatisch neu berechnen" steht auf "Endpunkt Priorität", ein Wechsel zu "Strecken Priorität" brachte auch kein anderes Ergebnis.
Apropos "Strecken Priorität":
In anderen Situationen erhielte ich bei  beim Verlassen der Route merkwürdige Anweisungen, welche mich immer wieder zurück auf einen bereits in Fahrtrichtung hinter mir liegenden, für mich aber nicht erklärbaren Punkt führen wollte ("Strikte Routen-Navigation" ist deaktiviert). Aus meiner Sicht funktioniert die Navigation bei START -> ZIEL und "Endpunkt Priorität" am perfektesten.

Aber nun zurück zum eigentlichen Problem.
Definiere ich die gleiche Strecke, mit den gleichen Punkten (Start/Via/Ziel) und meiner noch immer gleichen, abseitigen Position in Locus direkt über "Navigieren" erfolgt das Routing genau entsprechend der Vorgaben (mit Zwischenzielen).
Das dumme ist nur, dass auf diesem Weg nur 2 Zwischenziele möglich sind.

Aufgefallen ist mir die Sache als ich einen zuvor erstellten Rundkurs abfahren wollte, die Route aber schon nach kurzer Fahrt verlassen habe und durch die nachfolgend erfolgte Neuberechnung bereits nach wenigen Kilometer wieder nach Hause fahren sollte=-O.
Falls es hilft kann ich Ihnen die entsprechenden Screenshots zusenden, obwohl ich meine, das es ein allgemeines Problem ist da ich es auf verschiedenen Geräten getestet habe.
Hier noch meine Locus-Einstellungen die Navigation.
   
Quelle:    BRouter -> Fastbike
Automatisch neu berechnen: Endpunkt Priorität
Abweichung ab der neu berechnet wird: 100m
Abweichung Info: "EIN"
Strikte Routen-Navigation: "AUS"
Erlaubte Abweichung: 10km
Auf Strecke fixieren: "AUS"

Haben Sie eine Erklärung?

balloni, sorry, I have no idea, all seems to be identical .

I do not get what you guys are talking about.

The balloni-screencast shows that for walk/custom-off = "shortest" you get the shortest way. Nothing wrong.

With Libors hiking profile you get the way along the river. Also nothing wrong, because that's the whole idea of that stuff to get a nice hike instead of the shortest way.

The original bug issue was that there were differnt results for custom mode=off whether you use the "measurement tool" or "navigate-to". This cannot be confirmed from the screencast or screenshots.

Or is it mixed with the issue of having car-mode in recalculation? I also encountered ths, but this is fixed in the new beta.

There's a log-option in brouter that can be enabled by placing en empty file "debug.txt" in it's base directory. This file could help to clarify such issues, or see if the cost calculation was just on the edge and the way flipped just because the destination point was a little bit different.

Danke Gynta,

Leider gab's nach 10 Minuten Animationsfilm dennoch einen Fehler. Der Weg nach Rom war wohl doch zu lange...

Der "ups?"-fehler war eine endlos-scheifen check nach 10.000 Runden, vielleicht gab's auf dem Weg nach Rom wirklich ein Wegsegment mit 10.0000 Zwischenpunkten, vielleicht war's auch ein echter Fehler, hab' den Check jedenfalls entschärft.

Das Thema steht auf auf meiner Liste: die zu intensiv gemappten Zwischen-Punkte bereits im Präprozessor bereinigen und ausdünnen, weil die machen sowohl die rd5-dateien fett und kosten rechenzeit in der ganzen Verarbeitungskette.

Aber.. Warum möchte BRouter jetzt einen "from" Punkt haben nachdem ich "Exit" gewählt habe?

Dummer Fehler von mir, ist in der nächsten Version behoben.

[BETA version 3.18.9.1]

New BETA version 3.18.9.1

- BRouter configuration ...  hope this will be usable compromise for all . At least till I return at 20. 9. from small vacation ... feedback is anyway welcome.

thanx, yes I think I can get used to it

But here are my bug-reports so far:

- error messages are (still) hidden by the navigation panel, as Gynta pointed out already
  These are not just timeouts, but also the "Island" error messages
  ( "no track found" for startpoint island or "target island detected" ) and waypoint-matching failures
  (  "from-position not mapped in existing datafile" )

  To subtitle them all with "Maybe another service works" is of course not what I want to read there

- you seem to replace the start- and endpoint of the calculated track by the start- and endpoint of the routing request
  this is wrong. It replaces the first and last section of the way by "offroad" sections

- When starting navigation, the voice-announcement ("navigation is started") does not contain the transportmode anymore ( "in bike mode" ). I could not yet test what mode effectivly determines the distances and timings of the voice commands.

- However, you are maybe better of to the the mode from the gpx-response ( "locus:rteComputeType" )
I derive that from the attributes "validForBikes", "validForCars" etc in the profiles. And I would prefer to have it back in the voice announcement.

- After changing the mode via long-press on "recalculate", I get back to the screen containing the "recalculate" button.
  Howver, I had expected to return to navigation directly

ja. möglich ist es.

Banausen...

Schon klar, timeouts sind doof, aber keine Timeouts sind noch doofer, wenn sie zu Deadlocks und Blockaden führen. Komischerweise gibt's bei sowas auf der grünen Wiese immer viel mehr Architekten, als zu der Zeit, wenn man die Brocken ans laufen bringen muss

Mit Timeouts spielt man nicht, und klar, wenn das gesamte Bedienkonzept passt, mit einem modalen Lock und einer Abbruchfunktion, dann kann man das verbessern. Aber wer sowas fordert, der muss doch uch mal begründen. warum das nötig ist!

Und wenn ich dann das Gefühl habe, dass die, die das fordern, nicht mal verstanden haben, was eine timeout-freie Neuberechnung ist, dann bin ich frustriert...

@abrensch: I'm currently sending "maxRunningTime" set to value 120, does it have any effect on this time-out? Because from what other write, seems that still default 60 seconds is used.

type mismatch. Expecting "String" but getting "Integer"

Im Moment klappt das Ganze nicht. Ich konnte eben Dein Fehlerbild reproduzieren.
Nach dem timeout kehrt Locus einfach wieder in die Navigationsmaske zurück - ohne Fehlermeldung.

Doch, klappt.

Man sieht nur die Timeout-Fehlermeldung nicht in der aktuellen Locus-Version.

Einfach mal Probieren: nach dem "kehrt Locus einfach wieder in die Navigationsmaske zurück" (=Timeout) die BRouter-App (1.4.4) starten, in der Profil-Auswahl "<repeat timeout>" drücken, und nach Beendigung des (animierten) Routings wieder zu Locus wechseln und in der Navigationsmaske nochmal den Start-Button drücken -> dieser zweite Veruch funktioniert dann ohne Timeout.