Messages

My library -> this folder -> Edit -> Edit folder -> Style on map -> Line style -> blank

Tested and confirmed too.

- chg: Slope chart now have only inner fill and not the gradient below

look better thanks
 
@menion - late question regards new track chart & worse functionality - track list > tap recorded track > tap chart ">" > tap arbitrary point on chart, maybe highest point, fastest point, highest slope > tap Map icon (top) > top 1/5 of screen now shows map > tap "+" button > map is positioned in "middle" of whole track but not at the point of interest. It used to be possible when tap "+" that the map is position to the point of interest.

By contrast, and (in my opinion) working correctly, tap visible track on the map > tap point of interest on chart > map is correctly panned, OR even tap chart ">" > tap arbitrary point on chart > tap Map icon (top) > map is ALSO correctly panned. It seems inconsistent behavior from tapping the icon.

Suggestion in my 1st scenario - if no point is tapped then clearly the currently centering of the whole map is correct, however if a point is tapped/ a vertical line is displayed, center to that specific point.

crash after search > may you please record a short video for me? I can't simulate the problem and need to verify what do you see and what exactly you tap. Thanks!

I installed a screen recorder, and after a few attempts for online search, it now isn't crashing, oh well

slope coloring > hmmm

it wouldn't have to have varying coloring; I think the Web Planner simply has more logical presentation of +/-% slope
 

However, in edit mode, it only shows the section from A to B.

confirmed
 

I do believe the web planner's way of filling the parts above and below the zero line is far superior to what Locus app currently does. Even better would be different colors (e.g. red for above, green/blue for below, perhaps with gradient).

excellent suggestion; assuming the new Android chart library supports it

The example of my online search for "glen lusk" instead of "glenlusk" still crashes LM. online search > "glen lusk" > single search item in Ireland (other side of world) > tap item > map zooms out to full world > slow crash. On next app start - "Do not visualise too many points and tracks".

• Track chart no longer swallows tap events, and chart zoom respects the selected location.
• Chart slope data gets stronger optimisation

@menion 4.33.0.10 - confirmed improvement of chart slope - below is comparison of Web Planner (top chart) & LM (bottom chart) with my previous example - now LM shows 5% instead of 8% slope - far more realistic; zoom respects the selected location - great, thanks.
You cannot view this attachment.

Any opinions? Maybe introduce a third time?

@Menion I'm happy with current method, but with any change I think there will be opinions for/ against
 

Three UI issues:
a) searching a city

@menion - I hadn't tried Search for a while - Search > Online > Place & addresses > "glen lusk" - nearby place > only result is in Ireland half way around the world > LM super slow then crash. Screen cap below:
You cannot view this attachment.
I should have typed (all 1 word) "glenlusk" then my online search would have worked. But that is irrelevant to the crash about bogus message "too many points and tracks".

Newty - sadly a confusing distinction to trip up new users
at least see https://forum.locusmap.eu/index.php?topic=3799.0, although you have to hunt for that info from the home page
the search/ find abilities of the help system are very poor too/ never improved; I often can't even find my own posts from years ago
best of luck

4.33.0.8_1211_beta: startup & Store OK for me; no other testing done.

4.33.0.7 - crashes on start (after clean install too).

Locus Store working for me now

After further analysis of the thorny issue of the difference between WebPlanner & LM for display of slope - at a basic level LM is correct

Code Select Expand

lat        lon        alt (m) dist (km) slope (%)
-42.858939 147.326095 11.2    1.422     
-42.859009 147.326213 12.3    1.434     9.0
I guess LM is calculating slope (9%) point-by-point without filtering or averaging, whereas the WebPlanner must be doing some filtering and/or averaging to calculate 2.5%. I believe 2.5% is more realistic but there will, as in past? be endless debate for how it is done. I'd suggest at least the two platforms should use the same method & display similar charts though?

In my settings, for interest > GPS > Altitude manager > Replace GPS values + heavy filter, pressure sensor = off

rather than double post, my latest experience with 4.33.0.6 @ https://forum.locusmap.eu/index.php?topic=9553.msg80809#msg80809

4.33.0.5 maps button on tracks chart: the map is not correctly positioned if the chart is zoomed in: track list > track > chart > zoom+ > tap Map button (new) > tap + icon > observe map cursor is not in correct position.

Chart zooming suggestion: if the chart has been tapped (vertical line displayed) then maintain that position when zoom+ or zoom- is tapped. At present the position is often lost after the zoom.

Chart panning: seems a little unresponsive - swipe to side multiple times but often the chart does not move.

Chart panning: with zoom+ then pan too far to right (swipe left) and the screen (sometimes) becomes blank! Not sure 100% how to reproduce yet.

4.33.0.6 Locus Store > loading... forever and/or crash confirmed.

Smooth movement: detection of "stopped" is not perfect so still some unwanted rotation, but big improvement. If settings > GPS > Map rotation mode = GPS orientation only, then with only small or no movement, can all rotation be stopped? i.e. ignore GPS jitter of +/-5m?

The slopes in the new charts have always looked larger than the old chart. I checked one @ https://link.locusmap.app/t/wtkubf which is quite flat.
WebPlanner 2.5%:
You cannot view this attachment.

same place on LM chart 8%:
You cannot view this attachment.

I can't find my original help (suggestion) topic, so I'll say thanks to the WebPlanner developer(s) here - I note with pleasure after displaying a track from MyLibrary and then clicking the Back <- button, the scroll position in the list is now correctly restored rather than scrolling back to top of the list - a big time saving when the list is long, Thanks so much!