[APP] - version 3.18.x (27. 6. 2016+)

[Menion]

Hello @abrensch, thanks for a nice feedback.

I perfectly understand your point of view. More I think about it, more I agree that current system just "duplicates" settings for BRouter. On seconds side, life is not so easy.

I can imagine how you see it ... similar to what you have on web page, but
- quite weird to have some routing service done in this way, some in different, so it will require to recreate MapQuest and other to look and work same
- I read about no single problem till now, that car-fast, car-slow ... etc. cause problems to anybody. So this system as is, is usable and logical for users. What comes now is a complication - "profiles". You care about "average users". I care currently more about less then average users. They don't care about profiles. I expect, they will use all settings as is, no need to modify it.
- anyway good point is with extra parameters. As I think about it, agree they should be shared and agree they needs to be visible easily directly during creating navigation definition (start/stop). I have something in my mind, so give me one more chance .

@Andrew Heard: you are welcome!

[poutnikl]

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.


                 

[john_percy]

Locus will now display also [BRouter] profiles stored in Locus/data/brouter (for those who wants to play with it

They must be somewhere but I can't find them in that location on my system

[gynta]

Locus will now display also [BRouter] profiles stored in Locus/data/brouter (for those who wants to play with it

They must be somewhere but I can't find them in that location on my system

edit
...and you are right.
Locus/data/brouter is somewhere
Menion?

[LocusUser#1]

Beta 3.18.6.2
New Item screen: the arrow in the top left corner will not jump back into the list, I always land directly on the map screen, so I can not get to the list.

New Item screen: No items in the folder "GPSies" are displayed.

[Menion]

@poutnikl: thanks for feedback. Yep, it was quick action, but it's a beta and I think it's better to give you something to play with, then speed week on something, we later consider as useless.

I wanted to set just most used basic "boolean" parameters into optional parameters (like I did with motorways and tolls). More complicated parameters should be handled directly by routing profiles (separate files). Anyway it's on discussion. I think that for most of basic users, one or in worst case, two profiles for every type should be enough. Advanced users may use own profiles loaded in mentioned Locus/data/brouter directory (also possible to prepare pack with profiles to Store).

Btw. this directory is not created automatically. Just create it manually.

@LocusUser#1 and others ... what you expect to happen when you press "left arrow icon" in top left corner of screen? Forget on Locus now, it's a general question. As I read by Google suggestions, this button may move you one step back in activity lists, not just one step back like with "back button".
At start, in new "Items" screen this arrow has same system as hardware "back" button. But soon I realized that everytime I wants to return to map, I have to tap back many times and after return I have to again move to correct folder. This top arrow solve it and it's one tap to map and one tap to exactly same place where I was before.

Btw. I'm going to publish one more Beta now with completely redesigned configuration screen for BRouter and based on @arndt suggestion (and small inspiration from Google Maps), I made a compromise that I'll test next four days (out of office).

[abrensch]

- I read about no single problem till now, that car-fast, car-slow ... etc. cause problems to anybody.

I can help you remember :-)

http://forum.locusmap.eu/index.php?topic=5066.msg42633#msg42633

So this system as is, is usable and logical for users.

The system, as it is used, is not logical. In my mapping I mapped "moped" -> "car slow". A moped is not a car, so this is not logical, it's just a workaround. When zossebart maps 5 biking-profiles on the 5 transport modes and has a hard time to remember what "car slow" actually is, then there's also a usability problem.

What comes now is a complication - "profiles". You care about "average users". I care currently more about less then average users. They don't care about profiles. I expect, they will use all settings as is, no need to modify it.

I do not agree. The complication is the fact that there are two "namespaces" with a mapping between them. If there's only one namespace, whether you call it a mode or a profile is just wording. A user seeing a combobox with items like "car" "moped" "roadbike" "velomobil" "bike" "hike" will be less confused than a user that has to learn that a moped is a slow car.

- anyway good point is with extra parameters. As I think about it, agree they should be shared and agree they needs to be visible easily directly during creating navigation definition (start/stop).

Think about consistency. As poutnik pointed out, it's quite arbitrary where you put the "cut" between having distinct profiles or controlling behavior via parameters (and in current beta there are far too many profiles, because most differnces would be better implemented by parameters).

There's no good reason to treat these two ways of configuring the router on different levels of visibility/reachability. So if I convinced you to put the parameters directly on the Navigation Screen, I will also convice you to put the profile name there. Then you have a layout problem because of the extra space that needs, and convice yourself that you need to remove the transport mode buttons :-)

[Christian]

I'm very happy about the implementation of more BRouter profiles and even parameters.
This is for me beside guidance the most important functional module in Locus and sure also for other users and may make difference to other apps.
But i would like to ask all responsible and involved persons to create a functional design together before a new beta is released. This may avoid this kind of mailing list here in forum (see above).
Thank you. Looking forward to use this new feature.
And... i totally agree with the opinion of abrensch about users and parameters.

[Menion]

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.

Anyway I'm not saying that what you wrote does not make sense to me, it does. I just now can't imagine to create completely different UI for all routing engines, because of this. And have some special UI because of BRouter that will be quite different ... hmm ... have to think more about it ...

EDIT: and mailing list/discussion ... well, this is a one of main purposes of this forum I think .

[john_percy]

Back arrow button and new Items screen
I follow what you say @menion, but I was flummoxed as how to get back to the Items screen when I had drilled down to a collection of pois.
Back arrow returns straight to the map.

(Answer after a lot of trying is to get the title bar and system buttons to appear, then click system button "back". )
Not intuitive.

[poutnikl]

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.

[poutnikl]

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 )

[LocusUser#1]

Back arrow button and new Items screen
I follow what you say @menion, but I was flummoxed as how to get back to the Items screen when I had drilled down to a collection of pois.
Back arrow returns straight to the map.

(Answer after a lot of trying is to get the title bar and system buttons to appear, then click system button "back". )
Not intuitive.

+1

[T-mo]

@Menion:
shortly I recognised while driving close to start or end but being busy with the traffic situation due to road works and changed navigation, not much clicks and stuff possible, that the selection of the 'navigation data source' is quite faaar away.
Also studying and comparing of the found navigation-results of different 'data souces' for the same navigation (start-end) is nothing that can be done quickly..with a girl as assistant by my side and having a bit different result with an iphone on unknown tracks Sure, things can be done before, but happened..

Do you think it's possible to rethink some positions of settings?
At least you want to have your best route, which might not be delivered by using only ony data source nowadays..still the same with profiles, where we can quickly change due to situation depending criteria

[abrensch]

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.

Hi,

Both features do work in that constallation. And by the way, that was my main development effort when I implemented the remote-profile option for brouter 1.4.3

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.

@Arndt: What about modifying the profile syntax like

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

Nice try, but this ball goes back to Menion :-) When using a comment syntax instead, compatibility is not broken, so I don't have to repair. I would go one step further and define a comment-syntax that also provides the label-text and the label description text, and that also allows profile-defined parameters (currently, only build-in parameters work). Like that:

assign  avoid_toll  = false   # %config-option% Toll roads | Allows toll roads

regards, Arndt