Menu

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

#1186
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?
#1187
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: http://help.locusmap.eu/topic/scale-on-the-graphic . 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.
#1188
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 3.20.0.1 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?

#1189
@menion - I don't see new sound file PassPlace.ogg in navAudio ZIP in 3.20.0.1 - ref. http://forum.locusmap.eu/index.php?topic=5417.msg45464#msg45464. What exact navigation scenario is it supposed to cater for, and does the user need to manually add this file into the ZIP? Thanks.
#1190
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
#1191
@Cory - itinerary addresses - do you mean like in this help topic - http://help.locusmap.eu/topic/augment-navigation-itinerary-with-offline-address-data?
#1192
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.
#1193
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.
#1194
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 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?
#1195
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!
#1196
Quote from: TrulloF on October 13, 2016, 20:52:59
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?
#1197
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"
#1198
Quote from: menion on October 06, 2016, 12:22:41
@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.
#1199
Quote from: menion on October 06, 2016, 10:26:31
@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
#1200
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.