Messages

[Trekking Wet]

Same for other Languages

"Is Wet" @Crowdin is the quite wrong word.
What ever. If a hiker/biker isn't clever enough to handle wet tracks, he should better stay at home.
So for me this flag is an overdosed feature. just my two cents...

Hi Gynta,

Menion just overtook my naming of the flag for consistency. I as the author of the BRouter profile can name it as I want..  :-)

Edit: Using 1-2 flags means replacing 2-4 profiles by a single one, avoiding profile flood. Technically, all my bicycle profiles could be represented by a single one and several boolean flags and numerical settings. Menion has chosen reasonable conservative approach of 1-2 booleans.

BTW, I guess you misinterpreted intention of this flag, probably bacause it was incorrectly commented in Locus config. It is not about technical skills nor about avoiding danger nor about avoiding such roads, like avoid motorways. It just gives different BRouter costfactor preferences to problematic surfaces.

Edit:  E.g. the profile may prefer 6 km of soil but fine track to 5 km tertiary road. In case of iswet=1 it would take the tertiary road, as the track may be muddy and unpleasent, especially for girlfriends. You may want to think twice before taking them into muddy hell, full of track ponds.  OTOH, if it would be 2 km of such track versus 10 km of tertiary, the track  can be chosen in spite of that.

See https://github.com/poutnikl/Brouter-profiles/wiki/Bicycle-Trekking-profiles

Trekking Wet is modification of the above. The parameter assign iswet=1 penalizes potencially muddy / slicky surfaces and little promotes paved and main roads. Weather related priority shifts are fixed*), but distinguishing weather effect on different surfaces.

*) in contrary to numerical parameters MTB_factor and smallpaved_factor, where the profile behaviour can be tuned.

Pokud máš v nastavení Konfiguracce BRouteru Vlastni profily vypnute, tak nijak - vse je jak pri starem, porad se pouziva  mapovani v BRouteru.

Pokud máš v nastavení Konfiguracce BRouteru Vlastni profily zapnute, tak Locus pouziva vlastni mapovani a posila kod profilu primo do Brouteru. Mapovani profilu v BRouteru se obchazi. 

Vyhledove bude mozne toto mapovani rucne nastavit,
ale zatim - udajne vyhledove asi do puky rijna - je tam natvrdo

  Mode            Profile
  Car-fast        Car-FastEco
  Car-short       Car-Short
  Bicycle-fast    Trekking-Fast
  Bicycle-short   Trekking-MTB-Medium
  Foot            Walking

Takze pro Tebe to zatim nama vyznam zapinat.

P.S. for integration of the BRouter  profiles:

Iswet flag would be better translated to CZ "Za mokra" rather than "Je mokrý". ( Localizators have difficult job, as needed context for proper translation is often missing.. )

The description ( back translated ) as "to avoid dangerous ways in case of wet weather" is misleading, Most of such ways are not dangerous, just inconvenient. Danger particularly is not evaluated, as such info is not available. Danger must be evaluated visually on the map and terrain.  Better would be something like "It prefers ways that do not become slicky or dirty during wet weather".

Important info is, that ISWET flag DOES NOT avoid/forbid such ways, like e.g. Flag "Avoid motorways". It could lead to serious unnecessery detours. It just gives them various extra penalty, so in case of significant shortcut, they ARE chosen.
( It is possible my comments in profile or on wiki are misleading as well, I will review them. )

[OOps, accidentally I replaced this my post by the new one below. I have tried to recreate its main points.]

OOps, accidentally I replaced this my post by the new one below. I have tried to recreate its main points.

To BRouter profiles integration
1/ I suppose BRouter config Own Settings OFF works as the previous mode profile mapping in BRouter.
   ( Already confirmed by Menion in CZ post on HelpDesk )

2/ If Own Settings is ON,and transportation mode is chosen, there is for a fraction of second displayed used profile, mapped diractly in Locus. There is shown some roll out menu probably intended for profiles selection, but cannot be activated.

The profiles in Own settings ON are for now hard coded
  Mode            Profile
  Car-fast        Car-FastEco
  Car-short       Car-Short
  Bicycle-fast    Trekking-Fast
  Bicycle-short   Trekking-MTB-Medium
  Foot            Walking

Than all disappers and appears a new screen with avoiding switches. Is it intended behaviour for now ?
( Menion confirmed that such behaviour is temporary till next versions, should be ignored. Profile choice is planned )

3/ Car-short profile exists rather just for completess, is intended just for e.g. technical emergency of damaged but still operational cars. Most of drivers would not seriously choose such a profile for "production drives".
IMHO, Car fast mode should be Car-Fast and short mode should be some of Eco profiles, Particularly Car-Eco is short enough.

[from, [via1,] .... [viaN,] to]

......
Every request with a remote profile saves that profile on the brouter-side as brouter/profiles2/remote.brf

So after a timeout, you can repeat that long-distance calculation using the brouter-app, using the exact same destination point and a close-by starting point. That will automatically store the "reference-track" as brouter/modes/remote_rawtrack.dat, and with the help of that file the next try from Locus is guaranteed not to time out. Same for automatic recalulations (using endpoint priority). Recalculations should always be faster than the initial ones.
......

Hmm....., Locus can define the startpoint and the endpoint for the route calculations by multiple ways, e.g. by coordinates or screen center position. The above procedure of manually trigerring timeout calculation would fail, if the points are not chosen from already defined Locus waypoints...... It would be good if BRouter exposes the used points to the user so he would use them for timout free calculation.  Perhaps the way of generated points from, [via1,] .... [viaN,]   to would help.

...... I had to test BRouter & Locus on moto and it worked pretty well. I was used mainly "FastEco" mode and have to say, that few times track was longer then expected (usually a lot shorter track was over city which was probably considered as "not so eco"). .........

You may want to try the updated Car-Profile template, identical to future Car-FastEco.

The above experience may be caused by not well tuned yet evaluation of turn and initial ways costs, that could provide less them optimal results in urban areas. I have tried to address it better in the above template.

I have also added 2 extra boolean flags for Locus, that allow to turn already existing features by ON/OFF flags.
Avoiding Unpaved and
Fast versus FastEco. Or may be named Balanced .

Code Select Expand

assign fastprofile            0 # default 0=economic, i.e. balanced cost and time, 1=prefers shorter time
                                # implemented for Locus config switch system
                                # fastprofile=0 is equivalent drivestyle=2(FastEco), fastprofile=1 is equivalent drivestyle=3(Fast)
assign avoid_motorways        0 # default 0, 1=like if on moped or on "sightseeing tour", includes motorroad=yes
assign avoid_toll             0 # default 0 / 1=avoid paid ways and toll points like booths or bridges
assign avoid_unpaved          0 # default 0 / 1=avoid unpaved roads, equivalent to road_restriction=2, implemented for Locus confing switches

It is not problems of servers for LoMaps.
It is problems of the 3rd party servers, providing online routing service YOURS, alternative to e.g. Map|Quest.
Or, it is  a general networking problem of DNS service, resolving domain addresses to IP addresses.

But, as I have checked it now, the address does work, so it was probably a temporary problem.

......
Every request with a remote profile saves that profile on the brouter-side as brouter/profiles2/remote.brf

So after a timeout, you can repeat that long-distance calculation using the brouter-app, using the exact same destination point and a close-by starting point. That will automatically store the "reference-track" as brouter/modes/remote_rawtrack.dat, and with the help of that file the next try from Locus is guaranteed not to time out. Same for automatic recalulations (using endpoint priority). Recalculations should always be faster than the initial ones.......

It could be better from user convenience view,
if BRouter, seeing start destination distance bigger than a threshold,
would calculate the reference track and the first route calculation directly,
sending via API some kind of "keep alive ping".until finished.

As if used for cars, ( even if aware of turn restriction issue ), the timeouts may be rather the rule then exception.

What about - perhaps a crazy idea - general expandable list of "slots" for the Locus Routing

It would have
Slot Name ( like Fast Tollfree - car would be seen from the icon )
Mode, projected to the slot icon ( car, moped, bike, foot, canoe ). For BRouter may be extracted from Profile code
User routing service ( Mapquest, OSRM, GraphHopper, BRouter )
Optional legend - extracted or typed
Dynamic routing  options ( possible ?? ) like
     already available options for existing services ( car/bike/foot, fast/short for OSRM etc,)
     for Mapquest also toll, unpaved ...,
     For Brouter the used profile + extracted list of defined parameters.( or just predefined fixed list )

By "I read no ...", I was talking about using basic simple separation to "car fast", "car slow" etc. used in MapQuest and other services. Not about BRouter.

If we will talk about BRouter and it's usage in Locus as is now, then of course, system is not best in case you wants to change profiles and use different options. 

I think one BRouter feature would have to be addressed - Timeout free route precalculation in BRouter server mode.
It serves to prevent 60s routing timeout for the Locus 1st time route calculation or route recalculation with ( distant ) point priority.  At destination distance 50-100 ( OSM data density dependent ) km , the timeouts at normal calculation start to appear.

Either the new Locus system has to address it, either timeout policy has to be changed.
---------------------
@Arndt:
It could make sense, if there is implemented a way of default values if no parameter is provided, to have the common profile version.

E.g., current idea is
assign avoid_toll 0  # profile for BRouter
assign avoid_toll %avoid_toll%  # profile for Locus

What about modifying the profile syntax like

assign  avoid_toll  [%avoid_toll%] 0   # profile for both, [] means optional

where the assign command would take %avoid_toll% value if provided by API.
If no parameter is provided, syntax %avoid_toll% would be ignored and the default value 0 would be used.

I suppose HiLo may mean Hiking Locus...,  even if I once got idea of hiking High and Low...

[@balloni55:]

brouter profiles:
- allways long list of available"profiles". I think only meaningfull profiles should be available for selection, or what is the realistic use of  e.g "CAR-SHORT > Walking"  or  "FOOT > Car ECO"
- Where can user find abbreviation of e.g. SAC4 or FCR

@balloni55: Well, my work on script based generation of profiles (  I have found manual creation of profiles boring ) got ahead of the documentation. There was planned to add during the generation the short legend inside the profile header comment and to create a profile legend list file. Also the Github documentation of the new profiles versions.

At that moment Menion "has caught me off-guard" with this profile initiative, before the documentation was ready. 

All profiles for given way of transport come from a signle template, so using Locus options can significantly decrease their number. It could make sense to put them to car/bike/foot subfolders...

4 in SAC4 means maximum allowed value of OSM SAC_Scale , what is rating of alpine hiking difficulty of the trail.

FCR stands for Follow Cycle Routes, an analogy to ICR name.
FCR is a functional analogy to the flag stick_to_cycleroutes in the standard reference Trekking.brf, but works differently.

For more, see my Github pages or wait for later provided more elaborated comments.

@Menion: For car profiles, I would recommend added parameter %drivestyle%, modifying it to Fast / FastEco / Eco variants.

Eco is too focused on cost of fuel consuption at steady speed, but drivers would not be usually willing to drive so slow
( Driving distubations influence on time/cost are considered in Fast/Eco profiles as well. )

FastEco is a kind of balancing of speed and cost criteria.

My recommendations for bicycle and hiking profiles will come later. While all comes from the single template, it must be well thought, what to address by %parameter% and what rather by independent profile.

For bicycle, the most often tweaked is iswet, MTB_factor and smallpaved_factor.

https://github.com/poutnikl/Brouter-profiles/wiki/MTB_factor-and-smallpaved_factor

Boolean iswet try to guess shifting of preferences in wet weather, avoiding muddy/slicky roads.
MTB_factor and smallpaved_factor are numeric factors with default values 0.0, used for the single place tweaking of road preferences of profiles.   More on Github or later.


                 

Works very fine now, and improvements are well noticeable.

I have noticed a strange, too emphasized ( size, bold, red ) rendering of heath care/medical building names.
See the screenshot from the city of Brno, with all options of UniGCCZ theme checked out.

It could be dangerous to complain in a Scottish pub that Scotland is not a part of the England map... :-)