Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Andrew Heard

Quote from: Andrew Heard on October 27, 2016, 00:42:45
@menion - I don't see new sound file PassPlace.ogg in navAudio ZIP in - ref.
traps for young (& old) players - the reason I didn't hear my new PassPlace.ogg - it appears the notification sounds are cached only when the voice is changed. Workaround - if I select a different voice, then re-select my desired voice, now I hear the updated PassPlace.ogg. hmmm.

Quote from: Andrew Heard on October 27, 2016, 00:42:45
What exact navigation scenario is it supposed to cater for, and does the user need to manually add this file into the ZIP?
So to answer my own question - navigation scenario for example using generic cue point in RWGPS - this now invokes PassPlace sound - excellent. Yes, you need to manually add this file into your chosen voice ZIP file.
Thanks for explanation.
>. If you then start navigation, movement is based on your movement on map center cross
>anyway still no speed
OK - I wrongly assumed the speed of map dragging would be calculated as the simulated position speed

Is this setting needed then, and/or is default value of 0 any use? Probably good historical reason I guess. If GPS is turned off for simulation of position why not just assume this speed setting speed_for_moving_cursor_when_gps_off  is 5.0 unless user has specifically set to non-zero value?
For others possible benefit - 0709 has pointed out that I change setting config.sys speed_for_moving_cursor_when_gps_off from 0.0 (default) to 5.0. And this fixes my problem - now there is a voice announcement during navigation GPS simulation. Thank you so much 0709 - yet once again.

Setting comment says # set speed for moving cursor on map when GPS is off (in m/s) (default: 0.0)
#  - value <= 0 disable this feature. I don't really understand what this setting is supposed to do.
I have noticed a difference in navigation simulation operation between me and 0709. See - Willy has GPS turned off - navigation simulation - and TTS voice (beeps) are correctly heard as each waypoint is approached.

But when I perform the exact same with his supplied track and nav_audio files, no TTS voice is heard. If instead I use a GPS simulator eg. Lockito each waypoint is correctly announced, same as 0709.

So a question with my setup, why should navigation announcement occur with "proper" GPS (GPS icon green) but not with GPS simulation (GPS disabled, dragging map)? Thanks for any advise.
If I saw that checksum error for RD5 file my first step would be to delete the file and download the file again. Or even rename old RD5, download new, and do binary compare to see whether there really is a checksum error.
Quote from: 0709 on October 28, 2016, 21:25:18
By the way, those green and blue dots during edit is not optimal, as these colours are too similar, you hardly can see a difference during track creation. Coloring should be improved for more edit view comfort.
Not just color, but maybe different icons? Who knows which color is which?
Quote from: menion on October 28, 2016, 14:32:55
"Quick measure" really do not disappear after / sec? Ah damn, issue, fixed ... thanks :)
I actually like the new system in which measurement stays displayed until another tap by user. But you can't please everyone ;-) Also happy with short timeout.

Quote from: menion on October 28, 2016, 14:32:55
@Andrew Heard : ah links, thanks, missing "http://" at start of some links. Correct one should be here: . Anyway well .. I first thought about "declining" of this idea, later I said why not over config, it takes a while. In the end I spend on it half a day and I really do not wants to invest more time into this :). Three votes after an year? Not too important I believe, thanks for understanding.
@menion - thanks for link - there were 5 pages of topics with my search of "chart vertical" so I missed that one. Topic 1 year old. I have now voted for it. I still like the general idea, but now with SRTM elevations I hope chance of large vertical spikes will be less. Previously if GPS paused for shopping or lunch say then after resume there could be large change in initial elevation (I think as GPS elevation calculations stabilize/ average), causing large spike in chart, so chart line is mostly flat at bottom of chart with auto scale, quite annoying.
3.20.0 release notes has this very interesting new feature:

<add: option (in config.cfg) to pan & zoom in track chart in vertical axis as well>

In when I click on About > Release Notes > ">" to get more info for this topic I get error "Application for selected feature is missing...". It seems half the topics with links back into Locus website are valid/ working, but other half also give this error - mistyped URL?

New setting gui_track_screen_chart_vertical_scale=0|1.

My first experience with setting=1 and tap the chart + button: not very useful because X and Y zoom at same time. Pinch/zoom seems quite unreliable. Could the Y axis have own +/- zoom buttons when setting=1, or why not forget special setting, and just have Y axis buttons +/- zoom buttons always displayed?

@menion - I don't see new sound file PassPlace.ogg in navAudio ZIP in - ref. What exact navigation scenario is it supposed to cater for, and does the user need to manually add this file into the ZIP? Thanks.
Troubles & Questions / Re: new beta versions
October 26, 2016, 23:16:50
Quote from: marius on October 26, 2016, 21:51:58
Sorry, I didn't look enough for the information
I saw your post about already available 3.20.0 version as  of today and I don't know where to download
@marius - 3.20.0 not showing in Play store just yet but from experience should only be a few hours
@Cory - itinerary addresses - do you mean like in this help topic -
Quote from: poutnikl on October 16, 2016, 20:26:13
Sure, I am well aware of that.  But it is possible only if elevation profile is available.

As I have mentioned before on one of Locus forums,ideal would be if BRouter ( or Locus during the import ) would calculate the route nominal time profile estimation based on elevation profile. Then ratio of nominal and real speed for a particular route section would be used for the correcttion of  the nominal remaining time.

E.g. if you passed some distance in 9 minutes instead of nominal 10 minutes, based on nominal time profile,
than if nominal remaining time was 60 minutes, the corrected prediction would be 54 minutes.
@poutnikl nice proposal - maybe new help topic? The algorithm "logic" is simple enough for explanation in documentation. Seems to me lots of developer work for single ETA value when I think current algorithm is mostly OK, but people can vote.
Thanks, I knew that, but wasn't sure (until Menion's reply) where the internal Locus "BRF" files were stored. I now think it is a great solution. Well done you & @menion.
Quote from: Ulrich Kiermayr on October 15, 2016, 20:29:07
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 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?
Quote from: menion on October 14, 2016, 15:32:23
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!