Messages

Persönlich ist es schwierig, eine Person mit Wetter indepenedent Weise Vorlieben, aber harter Kern MTB Biker vorstellen.

Personally, it is difficult to imagine a person with weather independent way preferences but hard core MTB bikers.

Thanks Libor, really appreciate your help with this task.

Preference for "hiking route" sounds logical for me. Other two parameters, not sure about it. Hard to say how much longer route people are willing to go. Maybe we will see based on some feedback from usage?

The point is, there is wide range of need from no preference at all for city walking, to exclusive walking on marked routes in national parks or similar protected areas. Stronger the preference, longer possible detours.
All topic is similar to already long established route preferencing in standard and my bicycle profiles.
( Edit> with exception there is no hard restriction to bicycle routes only )

Ich komme mit der Profil-Idee "Wet surface" innerhalb Locus noch immer nicht ganz klar:


Darum nochmal nachgehakt um dann auch bei der Übersetzung die richtigen Worte zu finden.

Wenn also mit iswet=1 flag berechnet wird...
Was macht BRouter, wenn es dann nur einen elends weiten Umweg um den matschigen/glatten Weg gibt? bzw. was passiert wenn sich ein zu vermeidender Steckenabschnitt an den anderen reiht? Führt der vereimeintlich beste Weg dann über Afrika?
Wie sind diese Wege denn in OSM gekennzeichnet?
Sind diese Straßen/Wege nur bei Schlechtwetter Regen/Schnee nicht gut zu befahren oder handelt es sich bei diesen Pfadtypen einfach nur um natürliche Bodeneigenschaften (Moorwege, Sumpfgelände)?

Google Traslation to English by Poutnik:

I'm still not quite clear with the profile-idea "Wet surface" within Locus:

Therefore again nachgehakt then to be found in the translation, the right words.

is calculated flag So if with iswet = 1 ...
What makes brouter if it then is only one misery wide detour around the muddy / slippery path? or what happens when an inevitable resulting Insert section follows the other? then leads the vereimeintlich best way to Africa?
How are these paths because in OSM?
Are these roads / paths rain / snow to ride not only good in bad weather or simply is it with these types of paths only to natural soil characteristics (trackways, swamps)?

Iswet = 1 hat keine Beziehung zu jedem OSM Wetter spezifischen bedingten Tagging. Weder es forbides jede Straße, im Gegensatz zu avoid_motorways oder avoid_tolls.All die Flagge hat eine andere Gruppe von costfactors'priorities Anwendung. für verschiedene Kombinationen von OSM Wege und Oberflächen. Das führt zu verschobenen Entscheidungspunkt , welche Art und Weise zu nehmen.

Alles ist in brouter in letzter Schritt als eine äquivalente Länge ausgedrückt und Brouter immer für die kürzeste äquivalente Länge zu suchen. Die "rohe Art und Weise äquivalente Länge" = "Weg Länge" * costfactor. Es gibt Ergänzungen wie initialcost, turncost und Elevation äquivalente Länge.

Kleines Beispiel (insbesondere Zahlen sind nur zur Veranschaulichung)

Lassen Sie nehme an, es ist
asphaltierte Strecke mit einer Länge von 5 km, mit costfactor 1,0 (am besten)
Erde / Boden / Bodenbahnlänge 3 km, mit costfactor 1.3
5 * 1> 3 * 1.3 so brouter nimmt Bodenspur.

mit Inselchen = 1, hat der Bodenspur höher costfactor. z.B. 2.5
jetzt, 5 * 1 <3 * 2.5, so brouter nimmt asphaltierten Weg.

Aber wenn der Boden Strecke war nicht mehr als 3 km lang, aber nur 1,9 km,
als 5 * 1> 1.9 * 2.5, als 5> 4,75
und BRoute würde immer noch den Boden Spur nehmen.

BTW - wie der Autor des Profils (me) nicht deutsch sprechen, wäre es gut, wenn die aufgeworfenen Fragen EN Variante auch auf DE Forum haben würde.

Original EN answer
iswet=1 has no relation to any OSM weather specific conditional tagging. Neither it forbides any road, in contrary to avoid_motorways or avoid_tolls.All the flag does is applying a different set of costfactors ´priorities. for various combinations of OSM ways and surfaces. That leads to shifted decision point what way to take.

Everything is in BRouter expressed in final step as an equivalent length and Brouter always search for the shortest equivalent length. The "raw way equivalent lenght"  = "way length" * costfactor. There are additions like initialcost, turncost and elevation equivalent length.

Small example ( particular numbers are just illustrative )

Let suppose there is
paved track of length 5 km, with costfactor 1.0 ( the best )
earth/ground/soil track  length 3 km, with costfactor 1.3
5 * 1 > 3 * 1.3  so BRouter takes soil track.

with iswet=1, the soil track has higher costfactor. e.g. 2.5
now, 5 * 1 < 3 * 2.5, so BRouter takes paved track.

BUT if the soil track was not 3 km long, but just 1.9 km,
than 5*1 > 1.9 * 2.5, as 5 > 4.75
and BRoute would still take the soil track.

BTW - as the author of the profile (me) does not speak German, it would be fine if the raised questions would have EN variant even on DE forum.

.... Das Keep-Alive-ping könnten einige (auch sehr) grobe Schätzung der verbleibenden Zeit zur Verfügung stellen, so dass die andere Anwendung wie Locus den Fortschritt überwachen könnte, wenn alles in Ordnung ging, oder könnte ein Timeout-Ereignis zu machen, wenn Pings wie das Ergebnis sah werden nicht erhalten werden.
Persönlich bin ich zufrieden mit den aktuellen Lösung in v1.4.4, aber ich habe im Kopf-Nutzer, die herausgefordert fühlen, wenn sie mit Router arbeiten.

Original:
....That keep alive ping could provide some ( even very ) rough estimation of remaining time, so the other application like Locus could monitor the progress if all went OK, or could make a timeout event, if pings looked like the result will not be obtained.
Personally I am satisfied with current solution in v1.4.4, but I have in mind users that may feel challenged when working with Brouter.

If you consider just a car navigation/routing, evaluate also alternative GPS navigation software , dedicated to cars, having fully offline solution. E.g. MapsFactor Navigator.

For bike and foot naviagtion, BRouter as a 3rd party offline routing service can be better choice than online sources or general offline navigation software. As they often do not consider bicycle specifics, while BRouter does so a lot.

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

Ich bin nicht sicher, so frage ich ... Wäre es eine Implementierung sinnvoll , wenn Locus-brouter API eine Art von Keep-Alive Ping hatte "noch die Berechnung ..."? Brouter könnte Schwelle zu einem bestimmten Start-End-Abstand intern schalten frei Berechnung Timeout, regelmäßig am Leben Ping Senden halten und dann die Route berechnet, als ob bereit, von Locus das zweite Mal mit timout freien Daten genannt wurde.

Original:
I am not sure, so I ask... Would it make an implementation sense, if Locus-BRouter API had some kind of keep alive ping "still computing..." ? BRouter could at some start-end distance threshold internally switch to timeout free calculation, regularly sending keep alive ping and then calculated the route as if was called by Locus the second time with timout free data ready.

Hmm, and why do you think you should be able to do any Locus LoMaps routing when off-line ?

I originally missed the off-line mode in your  first post, thinking you had just troubles with online routing service.
In off-line mode you obviously cannot access any network servers.

Do you have installed and properly configured any 3rd party off-line router, like BRouter or GraphHopper ?

As Locus does not have any off-line routing capabilities itself.
It does not have any own routing engine.
Additionally, used format of MapQuest vector map and Mapquest map manipulation libraries
do not allow using the LoMaps vector data for routing.

[Translated]

Translated
@poutnikl, nach der Installation die meisten oder sogar alle Ihre Profile (btw. vielen Dank für Ihre Arbeit) Ich bin ein wenig verwirrt. ; D

Das ist ein großer Fehler :-). Sie sollen nur die Profile zu wählen, die Sie wollen. Der Profilgenerator wurde in erster Linie zu faul mir gemeint, als mehrere Modifikation der wenigen Werte manuell in der Vorlage ändern machen sehr langweilig ist.
Das Profil gemeint sind einfach dafür, dass praktisch, wenn Sie ihre Parameterwerte wollen.
Als allgemeine Richtlinie verwendet werden kann,
https://github.com/poutnikl/Hiking-Poutnik/wiki
https://github.com/poutnikl/Trekking-Poutnik/wiki
https://github.com/poutnikl/Brouter-profiles/wiki,
lesen Sie schließlich über https://translate.google.com

So will ich sie zu reduzieren
ein. Einfache Wanderungen (meist auf Wegen oder Spuren auf den Straßen nur, wenn keine andere Möglichkeit,
b leichte Tour fahren (auf gepflasterten kleinen Straßen, Ungebahntem, wenn keine andere Möglichkeit.
Welche Ihrer Profile würden Sie empfehlen? Vielen Dank im Voraus

A / Hiking-SAC2, schließlich mit modifizierten hiking_routes_preference 0.20-> 0.00 (ignorieren Wanderrouten), 0,60 (Folgen Routen Wandern) oder 20 (Halten Sie sich an Wanderwegen. Diese Änderungen sind noch nicht unter den erzeugten profies würde Suffix IHR / FHR haben / SHR. Die Standardeinstellungen von Wander SAC2 hat nur leichte Wanderstrecke bevorzugt 0,20 (6 km Wanderstrecke als etwa gleich lang wie 5 km von ansonsten identischen Weise genommen wird, die nicht Weg ist das Wandern)

B / Trekking-Dry, schließlich Trekking-SmallRoads,  mit stärkeren Vermeidung von Hauptstrassen und unbefestigten. Das Smallroads Profil wurde speziell auf die Nachfrage nach einer Gruppe multiday Trekking Ereignis disigned.

Original:

@poutnikl, after installing most or even all your profiles (btw. many thanks for your work) I´m a bit confused. 

That is a big mistake :-). You are supposed to choose only the profiles that you want. The Profile generator was meant primarily to lazy myself, as making multiple modification of few values manually at the template change is very boring.
The profile are meant just for being handy if you want their parameter values.
As a general guide can be used
https://github.com/poutnikl/Hiking-Poutnik/wiki
https://github.com/poutnikl/Trekking-Poutnik/wiki
https://github.com/poutnikl/Brouter-profiles/wiki.

So I want to reduce them to
a. easy hiking (mostly on paths or tracks, on roads only if no other possibility
b  easy tour biking (on paved small streets, unpaved ways if no other possibility.
Which of your profiles would you recommand?  Thanks in advance

A/  Hiking-SAC2, eventually with modified hiking_routes_preference  0.20-> 0.00 ( ignore hiking routes ), 0.60 ( Follow hiking routes ) or 20 ( Stick to Hiking routes. these modifications are not among the generated profies yet, would have suffix IHR / FHR / SHR. The default settings of Hiking-SAC2 has just mild hiking route preference 0.20 ( 6 km of hiking route is taken as equally long as 5 km of otherwise identical way that is not hiking route )

B/  Trekking-Dry, eventually Trekking-SmallRoads, with stronger avoiding mainroads and unpaved. The Smallroads profile was especially disigned on demand for a group multiday trekking event.

@poutnikl: Generally I think that BRouter over Locus currently use limited number of active users and when I need some feedback, it's usually best to take this risk and publish a  not-yet-perfectly-finished feature directly in public version.

Thanks for extra description for "Foot" profiles. I'll improve it based on your description to next version, that should also solve issue that had @balloni55 with his 2 or 3 option.

I would like to stick with boolean parameters as long as possible. We will see. Is there anything you consider as essential that is currently missing in parameters and that should be easily added?

Yes, I do understand the reason for publishing to get wider user base. :-)
Sticking to booleans if fine, as the chosen numerical values can be sticked to a boolean as well.

For now, for foot context, I think about hiking router preference management, expressed in the profile by default parameter
assign hiking_routes_preference  0.20 ( 5 km of marked route = 6 km of the same, but non route ) what means a mild penalty for a way not being a hiking route.

I think about 2 booleans, that may be in outdoor Hiking context even more important than iswet parameter.
One boolean would set strong route preference, e.g. 0.60-1.0 ( 5 km of marked route = 8-10 km of the same, but non route )
the other boolean would mean stick to routes, restricting to routes only.

Beachten Sie, dass halte ich für eine interaktive Batch zu erstellen, die ein einzelnes Profil von meinem Profil Vorlagen erzeugen würde, die auf der Benutzereingabe basieren würde.

Es könnte drei Vorteile:

- Ein Benutzer nicht von einer Flut von Profilen verwechselt
- Die Möglichkeit, erzeugen noch mehr Parameter-Kombinationen, wie Anzahl der Profile exponentiell mit der Flag-Option zählt wächst, und noch mehr mit numerischen Parameter.
- Anzahl der bereits erzeugten Profile für Benutzerkomfort kann kurz gehalten werden, die Auflistung als nur die üblichen Einstellungen, würde Rest auf dem Batch-Konfigurator gelassen werden.

Note that I consider to create an interactive batch, that would generate a single profile from my profile templates, that would be based on the user input.

It could have 3 advantages:

- A user not confused from a flood of profiles
- Possibility to generate even more parameter combinations, as number of profiles grows exponentially with flag option counts, and even more with numerical parameters.
- Number of already generated profiles for user convenience can be kept short, listing just the most usual setings, rest would be left on the batch configurator.

In der BR 1.4.4, bei der Locus Auszeit, müssen Sie die brouter zu gehen, wo es wird Ihnen auf der Oberseite der Profilliste eine Option mit timeoutfree Berechnung fortzusetzen bieten <in spitzen Klammern>. Wenn Sie fertig sind (auch schließlich Rat so über brouter HELP-Taste), sollen Sie Locus zurückkehren und wieder die gleiche Berechnung durchführen .
Diese Zeit gewährleistet ist, zum Zeitpunkt abgeschlossen werden, da die Route in brouter vorberechnet wird.

Original msg:
In the BR 1.4.4, in case of the Locus time out, you need to go to the BRouter, where it will offer you on the top of the profile list an option to continue with timeoutfree calculation < in angle brackets >. When finished ( also eventually advice so via BRouter HELP button ), you are supposed to return to Locus and perform the same calculation again.
This time it is guaranteed to be finished at time, as the route is precalculated in BRouter.

Generally I think, that publishing this Locus direct Brouter mapping feature in public locus version is rather premature, but if it happened, it at least can serve as a wider base user feedback.

Custom settings OFF works with BRouter as before, using Brouter transportation mode-profile mapping, by default the  shortest profile.

Custom settings ON was set by Menion's decision to the foot profile Walking, that is technically my Hiking template with set preferred SAC scale 0 ( T0 ) and max SAC scale 1 ( T1 ).

There are 2 important objection notes I have:
1/ Walking profile is aimed rather for general foot usage for walks in easy or even urban areas. Simple stone paths of SAC T2 difficulty are already forbidden.   For Hiking is better rather Hiking-SAC2 profile, or Mountain-hiking SAC3 profile. See also https://github.com/poutnikl/Hiking-Poutnik

2/ iswet flag is good rather for easy walks or trips around hybrid surface OSM way network, to prefer better surface in wet weather, if you want so - what is not always case of hiking.  For hiking on surfaces of similar kind, like all soil / grass or all gravel/stones, it makes much less sense.

My foot profiles uses as default mild foot route preference, that can be increased,given by parameter
hiking_routes_preference =   0.20  ( it cca means 6 km or official track =  5 km of otherwise identical but not offical one.
Strict  "follow official tracks if possible" is not useful in cities and even in terrain may lead to undesired effects like following 20 km detour to avoid 2 km of non marked path. But I agree something like "Strong official track preference" can make good sense. Similarly as  (conditional) Follow cycleroute flag in my bike profiles, or Stick to cycleroutes in standard Trekking.brf profile.

Menion for now decided to support only boolean flags, addressing numerical parameters by different profiles, as I do for bike profiles.

Why there is result for (1) = Brouter foot default shortest different for add route and measure and navigate to, I have no idea.
( Unless different viapoints were used or Alternative BRouter route calculation was triggered. )
There was also some issue with rounding coordinate error in BRouter, but since 1.4.3 it should be fixed.

[vypnutou]

No, prozatim na konfiguraci Brouteru ve smyslu vlastniho vyberu profilu v Locusu zapomen, to bude az v dalsich verzich nekdy v pulce.rijna, podle Meniona.

Mas-li v Locusu vypnutou vlastnii konfiguraci Brouteru, zustava v pro Locus v platnosti nastaveni v BRouteru.

Mas-li vlastni konfiguraci Brouteru v Locus zapnutou , prozatim tam Menion nastavil natvrdo

Auto rychle -  Car-FastEco  ( doporucuji do budoucna Car-Fast )
Auto kratke -  Car-short  ( nedoporucuji pouzivat, doporucuji do budoucna Car-EcoFast nebo Car-Eco )

Kolo rychle -  Trekking-Fast ( je nekde mezi trekkingem silnickou, na cistou silnicku je lepsi standardni Fastbike, nebo Fastbike-lowtraffic )
Kolo kratke -  Trekking-MTB-medium   ( je nekde mezi trekkingkem a (lehci) MTB. )
Pesi          -   Walking

Takze ti zbyvaji pouze modifikace
pro auto  Placene/Neplacene  a Dalnice/Bez dalnic
pro ostatni za sucha a za mokra.

[no method]

!The issue is no method  "from,via,nogo,to"  / Das Problem ist, keine Methode "von, über, nicht gehen, auf"

Google Übersetzung
Aah, ich sehe. Dann ist es in der Regel 50 bis 200 km, es hängt sehr auf OSM Wege Dichte, verwendet passcoefficients und schließlich verbot kleine Wege.

Nach dem Check ist der angezeigte Fehler die pass0 den 60er Jahren mit der Empfehlung eines anderen Routing-Dienst Timeout überschritten. Die msg disppeared zu schnell zu erfassen.

  Längere Strecken müssen als Vorstufe des brouter Timeout freien Server-Modus von-bis Strecke Vorkalkulation. (Ich frage mich, warum es nicht einige am Leben Ping-System in der API halten implementiert)

Original message
Aah, I see.  Then it is typically 50-200 km, it very depends on OSM ways density, used passcoefficients and eventually forbidding small ways.

After check, the displayed error is the pass0 crossed the 60s timeout with recommendation of another routing service. The msg disppeared too quickly to capture.

Longer routes need as the pre-step the BRouter  timeout-free server mode from-to route precalculation. ( I wonder why there is  not implemented some keep alive ping system in the API )

Google translation
(Leider für die Verwendung von Englisch, hätte ich noch mehr für meine Deutsch zu entschuldigen)

Ich erinnere mich, ich war erfolgreich einige vor 2 Monaten Strecke 1500-2000 km zu berechnen, road_restriction 4 oder 5 meiner Autoprofilvorlage. Aber es dauerte 25 bis 30 Minuten, 1pass-Routing und mit verbotenen ungepflasterten und kleinen asphaltierten Straßen. Später nach Brouter Update manchmal bekam ich einige Brouter interne Timeouts.

Original message
(Sorry for using English, I would have to apologize even more for my Deutsch )

I remember I was successful some 2 months ago to calculate route 1500-2000 km, using road_restriction 4 or 5 of my Car profile template. But it took 25-30 minutes, using 1pass routing and with forbidden unpaved and minor paved roads. Later after Brouter update I sometimes got some Brouter internal timeouts.