[APP] - version 3.33/3.34 ( 26. 9. 2018 )

[menion]

@Andrew Heard
hmm, this should make no difference.

@john_percy
you know that app has some more serious problems with labels because of the older part of MapsForge V3 library. And this is most probably just another problem. Sorry, I do not have a quick solution for this.

[michaelbechtold]

Hi Menion, you had thoughts about improvements in this area - what is your plan :-) ?

[john_percy]

you know that app has some more serious problems with labels because of the older part of MapsForge V3 library.

I am aware of the problem with labels and Mapsforge v3 library. But this is a Mapsforge v4 multilingual map -- doesn't that use v4 library?
The usual problem is labels not extending outside the boundaries of the tiles -- this is almost the reverse: the label is only displayed outside the relevant tile.
In any case, the issue is not simply to do with rendering as the map displays correctly on switching to it from a standard map but incorrectly on changing zoom. The standard maps don't display this effect.

[menion]

@michaelbechtold
you mean around the rendering of maps?

I believe we all will agree that best from long-term will be adapt to latest MapsForge version. This on one side will be a lot of work mainly for @voldapet who work years on themes for LoMaps, on the second side, it simplifies life to all of you, who suffer from divided themes for Locus Map and other apps.

Currently, latest version 0.10.0 of MapsForge library is already in app so V4 maps (and in next version V5 also) are supported. Auto-loading most probably does not work, MapsForge POI's are another, currently not so important, story.

Anyway, support for external V4 maps is not problem for LoMaps (they may still use old renderer).

Issue reported by John is probably little more complicated.
MapsForge is based on the same system as Google Maps or other map frameworks. They have own "map view" component which has logic how to draw map tiles. Anyway here is a problem. Locus Map has also own component. For using maps from MapsForge V4+, I use own hack how to prepare map tiles, which most probably cause a new issue with labels. But seems, there is one active use who may save us for now: https://github.com/mapsforge/mapsforge/issues/1085 . So let's wait on 0.11 version of MapsForge, I'll then use this method and we will see .

[Andrew Heard]

hmm, this should make no difference.

@menion - OK thanks - I have no other explanation why Locus locks up with RideWithGPS export then.

[balloni55]

@menion
is there a comment to my post #100 please ?

[michaelbechtold]

@michaelbechtold
you mean around the rendering of maps?
...

@michaelbechtold
you mean around the rendering of maps?
...

Yes, Menion, that has been my topic since long time :-)
I had a look at the mapsforge link, and I am not sure it really matches the Locus architecture - you will know best.
But when it comes to Labels, for sure they are best kept in the extra LabelLayer, like Cruiser does. Consistent, predictable and controllable (by theme) outcomes ...
Good luck and kind regards
Michael

[menion]

@balloni55
ah thanks for the reminder. Very nice issue (a nice example of curved developer mind  ) ... seems that description of cache is more then 221000 characters long text. Locus Map analyzes this text and looks for images that need "offlinize" (use of already loaded images). And it currently took really loooong.

I think I've improved this enough to make opening cache fast again. Thanks, this observation helps a lot not with this cache, but almost with every cache that has a longer listing, nice!

[menion]

So, another version with mostly bugfixes published.

Hope all will work fine, otherwise, I'm always ready for a quick hot-fix .

Enjoy the weekend.

[balloni55]

I think I've improved this enough to make opening cache fast again

perfect, solved with V 3.35.0