[APP] - version 3.24.+ ( 31. 5. 2017 )

[Henk van der Spek]

Ok, guys, I will eat my hat and 3.24.xx is good. After some serious logging and emailing with Menion I found out that the track style on the map in combination with a quite big track, creates the slugginess I see at higher zoom levels.
We prefer a track style with arrows and that one asks for a lot of processing power at higher zoom levels, above 20 or so. This came up since we nowadays combine hiking with geoacaching. Coming close to the cache, we use to zoom in a lot, up to max 22 level. Then the phone freezes. Switching to a straight line track style does not freeze it.

[menion]

Hi guys, thanks for a valuable feedback!

Route planner & editor
- access to search system, points and tracks is quite a challenge to me, but I'm aware that it's needed to solve it somehow.
- I was also thinking about merging both systems into single screen with all these options, but I still think that both are quite different and I can't imagine single screen with so much options at once.
- map overlays ... hmm, I'll look at it

Andrew, your missing rubber-band planning is also in my head .. every track should have an option "Load to route planner", which should really load whole track to planner with all these via-points etc. I think it should work.

@Žajdlík Josef: issues with saving solved, thanks.

@joeloc , @slarti76 : what should I do to simulate this issue ( how to simply change DPI ), any app from Google Play?

@Henk van der Spek : thanks, glad we found a reason of your slowdown.

[slarti76]

@joeloc , @slarti76 : what should I do to simulate this issue ( how to simply change DPI ), any app from Google Play?

Afaik, it's only possible to do this with root and XPosed framework - very Android-nerdy stuff. For me, it's not important, and I don't think it's worth spending time on. There's much more important things...

[Andrew Heard]

With the new route planner, when I then Edit on map, the previous and next point buttons are both disabled. Would it be more useful that the first point is selected so the Next point button is enabled? Also regards rubber banding, at present when I add a via point during route planning, it doesn't have any icon displayed in subsequent map editing. If i move a via point, all other non start/ stop/ via points on each side of this via point should be deleted and those one or two track segments be recomputed.

[menion]

@slarti76 : hmm seems that root on my S7 no longer works, damn. Maybe later ... I'm just quite curios why this does not work, because all in code looks correctly on first look.

@Andrew Heard : if you start "edit on map" from list of tracks, then why start point is better then some in the middle or in the end? So I see nothing logical on pre-selecting just the first point. Try to start this "edit" directly from the map to see difference.

About via-points - if you add new point during planning, it is not considered as "via point", just a "helping track point". If you wants to create a permanent via-point, try to tap on green dot once again. This creates real via-point that will be kept in track, visible in list of points and also used during navigation for notification or re-calculation.

[balloni55]

Hello menion
since i´ve tested the new "route planner" the "route&measure" inside PRO calcuate the route but the route isn´t visible on map.

With old "route&measure" inside Beta the route is displayed on map not until i zoom or pan the map

If i use new  "route planner" all works fine

[Andrew Heard]

@Andrew Heard : if you start "edit on map" from list of tracks, then why start point is better then some in the middle or in the end? So I see nothing logical on pre-selecting just the first point. Try to start this "edit" directly from the map to see difference.

About via-points - if you add new point during planning, it is not considered as "via point", just a "helping track point". If you wants to create a permanent via-point, try to tap on green dot once again. This creates real via-point that will be kept in track, visible in list of points and also used during navigation for notification or re-calculation.

I am editing track from the map, not a list. I am pointing out the left/ right buttons start differently to existing pro behaviour. Existing behaviour is for tapped point to be selected, and therefore, generally, both buttons are enabled. Beta behaviour is for tapped point to be ignored.

As discussed before there needs to be better distinction between a green icon helping point and its converted blue? Via point. Currently almost impossible to tell the difference - shape, better colour, size?

If I edit this new track on the map I can long-tap to edit/ move the point (not always?), but from waypoint list there is an error message that point can't be edited?

How about long-tap on point to display same menu as tapping Tool button? Would be faster in lots of situations.

Maybe instead of further menu level Edit/insert > select point yet again, the Tool menu has separate items for Move/ Insert/ Delete?

Seems named via point is lost if edited and moved?

Moving, deleting points, a simple operation, just takes far too many taps. Surely long-tap point > menu > Delete? And if undo facility provided then no need for confirming each and every operation.

Each recompute is taking a very long time too. Just with simple test track.

Just a few long-winded thoughts to speed up editing and make more intuitive? Could there be a workflow "conflict" between users with short tracks wanting very precise control over placement of all points, and users with long tracks that rely mostly on compute source, and just want to steer in right direction is iniial route needs broad adjustment?

[joeloc]

Ok, guys, I will eat my hat and 3.24.xx is good. After some serious logging and emailing with Menion I found out that the track style on the map in combination with a quite big track, creates the slugginess I see at higher zoom levels.

Erm... I think I reported this bug more than two years ago... and menion already acknowledged the problem and did some profiling and blamed rendering code in Android. But basically, track styles were completely unusable since the beginning because they slow down Locus to a crawl (1 fps and less) at higher zoom levels. Since I quite often use high zoom levels to scout for campsites on sat maps, I had to stop using styles completely. Shame really, but cannot be helped until rendering is fixed, either in Android or in Locus.

A dead simple ten-second-workaround (also suggested back then) would still be:
if (zoom > X) style=0;

But obviously that would make more people complain about what happened to styles at high zooms. Performance isn't really such a big topic for most.. so what if rendering takes a second... or deleting track point takes five :-).

[joeloc]

@joeloc , @slarti76 : what should I do to simulate this issue ( how to simply change DPI ), any app from Google Play?

Afaik, it's only possible to do this with root and XPosed framework - very Android-nerdy stuff. For me, it's not important, and I don't think it's worth spending time on. There's much more important things...

Theres more important things indeed. I just thought maybe the bug is obvious... like using a different DPI value for cursor calculations/scaling and the rest of the UI. Testing will unfortunately require a rooted Android, xposed framework and the "app settings" module. Very nerdy indeed.

Anyway... Locus UI is just a tad small for moving bike-usage... but very well suited for couch-usage... or for while-being-stopped-usage. And I understand that the latter has preference and nobody really cares about moving bikes. It would be nice though if Locus had a simple "scale" setting that scaled everything at once... buttons... fonts... cursors... maps... just everything. Similar to what you accomplish by changing its DPI value with ugly hacks .

[Henk van der Spek]

A dead simple ten-second-workaround (also suggested back then) would still be:
if (zoom > X) style=0;

I vote for that!

[menion]

@Andrew Heard: thanks for a feedback. It is quite a lot of questions and thoughts on me now. I'll work more on route planner later, this was just a first shot. First step for me is route editing, then planning and last step is already mentioned rubber-band editor.

@joeloc , @hank : you will see in next version, performance improved

[Žajdlík Josef]

Hello Menione, in the new beta 3.24.1.6, the conversion of the modified route is significantly faster. Or is it just my impression?

[menion]

Yep, I think I have found some bottleneck, so it should be maybe 10x faster now .

Same with drawing of styled tracks in high zoom levels.

Well, everything is possible when there is will and .. correct push from you here . Enjoy it. I'll publish it at start of next week as new bug-fix version on Google Play, so if there will be any problems, please report it here. New "Route planner" and "Track editor" won't be yet published, there is still a long way ...

@balloni55: issue with refresh of map in old version of "add new route" fixed now, thanks

[menion]

*** New version 3.24.2 ***

uploaded on Google Play. News after start as usually. Consider it mainly as a bug fix version with few interesting improvements and mainly some performance improvements discussed here.

[zigzag]

Hi menion,

With new version of LocusMap the Locus addon Pebble app get no data from periodic update. Is there any changes in periodic update module?

thanks