Messages

A remark on that: during our vacation (cycling) the ETA often was not really usable. Reason: the topography of the route has a huge influence on the speed you are able to ride. Consider a tour where you go uphill the first half and downhill on the second. Just considering the current average speed, would result in unusable results,because it would estimate going up the whole tour. But this is wrong, since the second half will be faster because it is downhill.
I think the ETA algorithm (for cycling and probably also for hiking) should work somewhat like the algorithm to estimate the time for a track. The current avg speed could\should be used to set the parameters for that estimate (like piking the best profile in the trip time estimate).

@Ulrich Kiermayr - I recall the ETA calculation did something like what you propose a long time ago. At the time I made suggestion for opposite of what you now propose to return to i.e. "considering the current average speed" - help topic http://help.locusmap.eu/topic/why-was-time-to-target-so-wrong. No algorithm, unless it takes into account topography and history of your speeds in similar circumstance is going to be accurate, when there are range of gradients along the route, but in your example when cycling faster in second half, even after a few minutes of downhill your "current average speed" will of course quickly rise, and as a consequence the estimated ETA will indeed become more and more accurate? Didn't you observe that? Say you select a profile where the nominal speed is 18km/h, and on your route you cycle uphill all day, how is the profile speed any use to ETA calculation?

2) profiles are stored internally ... I've attached current version to this post below. Few available parameters ( %avoid_motorways%, %avoid_toll%, %avoid_unpaved% and %is_wet% ) are currently hardcoded in Locus.

@menion - that's great - I can extract a BRF file from your Locus ZIP, copy to the BRouter profiles2 folder, and now Locus advanced navigation settings will parse the special "hard coded" parameters and display equivalent checkboxes - very nice!

throws some java error or something,

@TrulloF - it your Java error similar to one I reported in BRouter Google group - https://groups.google.com/forum/#!topic/osm-android-bikerouting/-whNhF2aXeU?

I very much like the new BRouter navigation settings. Good result after a few beta trials.

1) One suggestion with BRouter advanced settings - when you edit the Locus Profile Name the text under the profile icon is not updated until you exit/ re-enter this dialog which I think is confusing.

2) Where are these Locus profiles stored in the file system? I'd like to compare those profiles with the BRouter ones. Can I edit BRouter BRF files and incorporate relevant Locus profile parameters? Are BRF files parsed for all parameters, or are these profile parameters "hard coded"?

3) To be consistent with the two other parameters the Unpaved parameter should be labelled "Avoid unpaved":


4) Very minor but the month in the release notes is September instead of October - "11.9.2016"

@Andrew Heard: understand, thanks. If you find something that may helps, let me know. Seems that publishing version next week (and not this one) was a good idea. I'll try to get out for some longer testing because of this and as well, because of Willy's (0709) issues. Thanks

I tried identical navigation test today as last week (in which navigation line wrongly appeared transparent) but this time worked perfectly. I have no idea why different. Oh well.

@Andrew Heard: hmm line is not on the first screenshot visible completely, so even a thin line on part you already passed is not visible. It may only means that Locus a) considered that track is not visible in current view, b) has any problems with rendering of this line. Never noticed something like this on own device, do you have steps to reproduce it please?

@menion - I've been using navigation for the last year. I can tell when it isn't displaying correctly. I've never noticed it before either, and although I don't have great screen captures sorry or steps to reproduce (yet), but as I said, it rendered perfectly on Pro, but not (at times) with latest Beta, on simple road/ route I use a lot for previous testing over the last year. I will try to reproduce next week

Using 3.18.9.6 for navigation I found the usual magenta line was not being displayed. I've never seen this before.


I then swapped to 3.18.0 Pro & restarted navigation, and the normal magenta navigation line was displayed properly.


I then swapped back to 3.18.9.6 & restarted navigation again. Same problem - invisible navigation line. But maybe 10 minutes later I found that the magenta navigation line was again displayed.

Unlike 0709 I didn't find any other problems with navigation. I also performed same navigation with GPS disabled and normal magenta navigation line was displayed properly. Weird.

3.18.9.4 beta: Locus/ BRouter Fast & Short car profiles have Unpaved checkbox, but Fast/ Cycle/ Walk profiles only have Wet Conditions checkbox. Unpaved checkbox is absolutely desirable for these latter 3 profiles too. And maybe Walk profile could use Wet Conditions checkbox. Why inconsistency?

Andrew, Locus GUI config for BRouter profiles can offer only parameters, that are exposed by the chosen profiles. Neither standard, neither my bike profiles offer absolute avoidance for unpaved roads like car profiles, for quite good reasons. You may want to stay with Fastbike profile, or my template e.g. with MTB_factor -2.0.

OK, so Locus scans each profile for exposed parameters & displays as list . This would explain the Locus delay in changes with the UI - reading/ writing the (pro)file. Clearly, absolute avoidance of unpaved roads is not desirable, and may result in huge detour, although it could be argued the user can also view the proposed route from each checkbox state and make own decision, but surely hint from user for increased cost to selection of unpaved roads would be nice, and operates with similar logic/ consistency to Wet Conditions.

3.18.9.4 beta: Locus/ BRouter Fast & Short car profiles have Unpaved checkbox, but Fast/ Cycle/ Walk profiles only have Wet Conditions checkbox. Unpaved checkbox is absolutely desirable for these latter 3 profiles too. And maybe Walk profile could use Wet Conditions checkbox. Why inconsistency?

"Absolute time when sun will rise/fall" - nice! But why does my tablet display correct sunset time, but phone displays "unknown"?

@michaelbechtold and @joeloc - no need to be quite so cynical and aggressive in some of your posts, we re all ordinary people in this forum, not robots. I don't see need for swear words (https://en.wikipedia.org/wiki/Profanity).

I used to find time to sunset (in top panel) useful when on long rides that continue through afternoon into night, but in scramble to have most useful buttons I now cover up that display with other buttons.

If the country's Lidar-elevation data is Opendata, then maybe. But those of Switzerland, France are not available free. And for Italy (exempt South Tyrol) I'm unsure about the situation. And if Opendata - where to find LiDAR sources of the whole country.

OK thanks for reply. One day...

Top effort @Sonny. I checked some routes I planned in Slovenia a few months ago, and the visual improvement in calculated gradient is amazing. Much less noise too. Are there plans for other countries, for example France, Switzerland, and the remainder of Italy?

Maybe a question for @Arndt, I presume for BRouter to make better routing decisions involving elevation the RD5 files would need to incorporate the new HGT/ GeoTIFF data?

Section can be misleading, as it is unclear what it means. Why not just the old good  (OSM) ways ?
The shift of preferences can be justified by either of being difficult(skills) and being unpleasant(perception).

I think only people familiar with OSM terminology would understand the meaning of "way" in this context. For the majority of english speaking people it reads quite strange. "Section" was more generic, but in new suggestion below "route" reads better to me. There are plenty of other places in Locus where the text could be improved and/or go round in endless discussions for marginal benefit.

Improving grammar & changing the negative (not) into a positive:
"Prefer easier ways when wet weather"
"Prefer easier route when wet weather"

[Avoid route that may be difficult in wet weather.]

For the explanatory text, maybe "Avoid route that may be difficult in wet weather."

nicely worded, purpose is clear, or Avoid sections that may be more difficult in wet weather?