[APP] - version 3.15.x (27. 1. 2016+)

[balloni55]

althought i have disabeled shading, in down left area of german maps shading is visible in lower ZL

[Menion]

@gynta: hmm really nice issue. It's there also in latest public version and this issue should be there since exists shading. Problem is that on that tile are no data in vector map. Result is empty tile and well .. no shading. I was trying to fix it, but all attempts break mainly auto-loading of vector maps. So for now, no simple solution. I'll try to do something with it later.

@balloni55: anything I may do to reproduce it? For me, when I disable shading, whole map redraw without it. Weird.

[balloni55]

Hi menion
it´s more and more confusing for me
today i purchased new map "germany south" in hope to solve my problem with it, please compare both screenshots with different maps i get different results
most problems apeare at ZL10-12

with disabeled shading


and with enabeled shading


how can i support you to solve this behavior?

[Menion]

Nice, interesting. Do you have disabled autoloading of vector maps? May you try to enable it? Only what I think it may cause, are some cached tiles for vector maps. And vector maps are cached only in case, auto-loading is disabled.

[balloni55]

thanks for your idea,
but it doesn´t matter vectormap autoload is enabeled or disabeled
all works fine on ZL13 and higher

[joeloc]

I can confirm some hanging tiles with latest beta... but it looks to me as if only the "hill shading part" is hanging. Is there maybe some separate caching going on for the hillshade layer now?

As for the hill shade speed... better... but not quite fast enough :-(. Is it really such a bad idea to first render ALL TILES normally and ONLY AFTERWARDS, when the screen is completely filled already, spend any cpu power on shading? You probably think it doesn't make any difference in overall rendering time... but the difference in look & feel & snappiness would be absolutely major. Blank screen staring time is reduced to a minimum.

Also... when scrolling&zooming, it usually takes a few taps & swipes for me until I find the area I am actually interested in. But I still have to wait for the map to render in-between to see where I am going. If shading/coloring would NOT BLOCK normale tile rendering, this process could be much faster.  Locus would obviously abort shading/coloring for the tiles that are scrolled off screen quickly... saving battery and cpu time.

Hill shading for me is nothing I enable "just occasionally". On the contrary: I consider it absolutely essential for vector maps to make them look reasonably good. So anything that happens here directly affects every single moment of my "time with Locus". Progress in this area is just as important as in actual osm data rendering and slowdowns are just as annoying.

From a users point of view, things are really simple: If you can see an app (any app) "slowly" build up its screen part by part, it feels "sluggish". If the screen is just there, it feels fast. I admit having no idea whatsoever about the complexity of the actual shading algorithm... but if you'd simply do the work *afterwards*, it's slowness really would not matter so much. Thinking in this direction is IMHO much more rewarding than squeezing out another 4% in actual algorithm speed.

Oh... to end with something positive... the brightness/darkness is totally OK now :-).


Edit: Added a video of current beta hill shading speed on a Galaxy Note 4. Ten seconds for a screen is not exaggerated.

[joeloc]

- clear installation and empty Locus directory
- here download and import this X file and do this, bam .. slow

This is one way to look at it... and I have a hunch that your own Locus installation is basically similar... almost always almost clean... with just a few tracks and very few points.

Another suggestion, that is probably more likely to give results, would be for YOU to personally always use Locus with a 50MB database and at least 100 enabled tracks and 5000 enabled points... worldwide... no excuses. I can almost guarantee that you would start looking at things differently :-)

[joeloc]

Regarding hanging tiles: I just tested "the old way" of hill shading to compare speed & looks by using an online map hill shade overlay from http://korona.geog.uni-heidelberg.de/contact.html . It seems that there is some serious tile hanging going on with Locus overlay maps. At the moment, I do not know if this is related to this beta version or if it is a server issue:

Code Select Expand


<provider id="11234" type="0" visible="true" required="false" background="-1">
<name>OSM Layers Uni Heidelberg</name>
<mode>Aster/GDEM Hill Shading</mode>
<area></area>
<url><![CDATA[http://korona.geog.uni-heidelberg.de/tiles/asterh/?x={x}&y={y}&z={z}]]></url>
<zoomPart>{z}-8</zoomPart>
<zoomMin>8</zoomMin>
<zoomMax>26</zoomMax>
<tileSize>256</tileSize>
<attribution>http://korona.geog.uni-heidelberg.de/contact.html</attribution>
</provider>


[joeloc]

...played a few more minutes with map overlays & scrolling & zooming (the hillshade layer from last post on top of mapsforge Alps from openandromaps) and had plenty more hanging tiles. Also, Locus Beta crashed on me at least two times. No more time to properly debug right now since I am leaving for the weekend... just posting this so you can maybe look into it a little more before releasing another version. Something is very bogus.

[balloni55]

Hi menion
- i delete all srtm data from folder, srtm folder is empty
- i clear cache of Locus Free app
- i start Locus Free/Beta
and now my question an perhaps the solution:
- where get locus info for shading in south west area of my map on ZL9-12, independent shading is enabeled or disabeled? Exactly in this region the problem with hangig tiles appeare.
see screenshot

[joeloc]

I can confirm hanging mapsforge tiles completely independent of hill shading. Map is from http://www.openandromaps.org/maps/europe/Alps.zip , no overlays, no internal hill shading, no slope coloring, nothing fancy. Tiles are randomly forgetting to be rendered when you zoom in and out frequently. This happens with latest beta and is easily reproducible here.

[Menion]

I can confirm some hanging tiles with latest beta... but it looks to me as if only the "hill shading part" is hanging. Is there maybe some separate caching going on for the hillshade layer now?

Yep, small cache for test on background

As for the hill shade speed... better... but not quite fast enough :-(. Is it really such a bad idea to first render ALL TILES normally and ONLY AFTERWARDS, when the screen is completely filled already, spend any cpu power on shading? You probably think it doesn't make any difference in overall rendering time... but the difference in look & feel & snappiness would be absolutely major. Blank screen staring time is reduced to a minimum.

I already did this some time ago, but results was terrible. Too much threads, too much options, too much already implemented memory/cpu optimizations on one place .... result was always a mess and problems with incorrectly shaded tiles. That's why I'm now doing shading directly on ready-to-display map tile even before it's visible for the first time. So it's now about "I don't want". It's about "I already did it, but first attempt some time ago was disaster".

Oh... to end with something positive... the brightness/darkness is totally OK now :-).

fine

This is one way to look at it... and I have a hunch that your own Locus installation is basically similar... almost always almost clean... with just a few tracks and very few points.

Another suggestion, that is probably more likely to give results, would be for YOU to personally always use Locus with a 50MB database and at least 100 enabled tracks and 5000 enabled points... worldwide... no excuses. I can almost guarantee that you would start looking at things differently :-)

Well, my current database waypoint.db - 17 MB, tracks.db - 68 MB. I use it daily, not just behind the desk. Device? Three years old Sony Z1C. Why should I display so much points and tracks around whole world? It's not common case of usage I believe. Every app has it's limits. Well, you already know limits of Locus. Anyway I'm aware that slowdown comes in these cases directly in list of points/tracks. This is probably due to incorrect structure of SQLite database. Quite hard to solve now ... anyway in near future will be maybe needed another conversion of database, same as few years before.

@balloni55: hmm cache for hillshading tiles is stored in private app directory on SD card, usually android/data/menion.android.locus(.pro)/cache/maps/shader/hill. Anyway if you have disabled shading, I'm sure it should not be visible in any case. What about some overlay map or enabled WMS maps?

[joeloc]

I already did this some time ago, but results was terrible. Too much threads, too much options, too much already implemented memory/cpu optimizations on one place .... result was always a mess and problems with incorrectly shaded tiles. That's why I'm now doing shading directly on ready-to-display map tile even before it's visible for the first time. So it's now about "I don't want". It's about "I already did it, but first attempt some time ago was disaster".

Disaster sounds terrible :-).

Anyway.... what I just did for testing was: Use Locus to download hill shade tiles from the server mentioned above into an offline map. Zoom 13 is enough, the tiles don't seem to be more detailed anyway. I believe the whole alps will fit into 1.5GB at zoom 13. Using this offline sqlite map as a Locus map overlay on top of a vector maps, the results are simply AMAZING:

Reasonably pretty hill shading with almost no delay. The overlay seems to be rendered "independently" from the vector tiles, it appears first, long before the maps forge data is actually rendered. Thats exactly how things should work... giving us a "blank screen time" of nearly ZERO. Locus instantly feels speedy and snappy and fast... I LOVE IT.

Compared to this experience, Locus own hill shading is really only bearable as a last resort :-(.

Yes yes... I know... I compare pre-rendered tiles to custom smartphone magic from raw altitude data... bummer... but seriously:
+ you have the data (hgt).
+ you have the algorithm (beta hillshade prettiness).
- you run it at very unfortunate time in an unfortunate way (blocking tiles, maximizing blank screen time & sluggishness).

Nothing prevents Locus from translating HGT files into sqlite maps right after download (or on first use) automatically and then use the map overlay engine for display. Yes... some minor issues would have to be sorted... like auto-switching the overlay across htg borders... what to do with other overlays... doing the conversion "in the background" without disturbing the user... keep or delete original files... etc... but nothing here sounds unsolvable. And the difference in usability compared to the current "realtime render" implementation could not be greater. IMHO, this is the only proper way to proceed... unless you magically find a way to speed up the shading algorithm by two orders of magnitude or implement 100% bitmap caching of every single rendered shading tile at every zoom level. A few percent here and there won't do...

Sorry for always having such strong opinions :-).

[gynta]

@gynta: hmm really nice issue. It's there also in latest public version and this issue should be there since exists shading. Problem is that on that tile are no data in vector map. Result is empty tile and well .. no shading.

hm ok but what about missing tiles on vector maps?
-> https://www.dropbox.com/s/n29z3t17pf5exm0/clip0433.avi?dl=0

edit
Locus caching vector maps?
whatever - clear locus data in system helps*


*) hint: backup your settings

[michaelbechtold]

Update for usage of external SD card under KitKat - SRTM in particular

Hi all,
following the guidance from
http://docs.locusmap.eu/doku.php?id=manual:faq:use_sdcard_on_kitkat&do=login&sectok=ea111e6e0396dfbd1215ceb613941744
option C like, I have the working directory on the internal SD, except the vector maps on external SD card in /LocusMapsVector, and the SRTMs next to those.

Adding elevation files on the fly has been a mess, though! Always need to switch to default, download, then copy to external SD by the Samsung File Manager (only one that can do that on non-rooted device).

Today I tried something new (new at least for myself): leaving all critical working directories on internal SD, leaving the vector maps in their place. But I moved the SRTM directory to the /Android/data/menion.android.locus.pro/files.
I have been delighted that this gives me what I want: working data on internal (safe place in case of de-install), vector maps on safe place on external SD. And R/W access for SRTM on external SD (with loss risk, though).