.sqlitedb as Overlay not working?

[noisyriver]

Edit 2
Narrowed the problem: Locus is not reading this map when tile recalculation and JPEG compression is activated in MOBAC.

I exported four files with MOBAC:
1. A normal OSM map area with compression and recalculation to Rmap sqlite: No problem in Locus
2. Hike & Bike Map hill shade layer to orux sqlite: no problem in Locus (but not possible to select as overlay)
3. Hike & Bike Map hill shade layer (same region) without compression and recalculation to Rmap sqlite: No problem in Locus
4. Hike & Bike Map hill shade layer (same region) with compression and recalculation to Rmap sqlite: Empty (grey) in Locus

---------------------------------
Older Message:

I have a problem:
I want to create an offline hillshade overlay for my offline OSM-Vector-Map.
So I have downloaded me a small region of the Hike&bike map hillshade layer, zoom 8 to 15, via MOBAC in a RMAP .sqlite file.
I am able to open this layer alone in Locus and see the hillshading very nicely.
I am also able to add this map as overlay with the overlay function. But it is not displayed, the OSM map is still "flat".
Doing the same directly with the online Hike&Bike map through Locus works fine, I have a nice hillshading. For testing I also copied the .sqlite file Locus was creating from downloaded tiles and used this as a offline map and this was working fine too.

But no success with the .sqlite from MOBAC.

(MOBAC 1.9.7., newest Locus Pro, Android ICS on an Galaxy Note 2.)

Thanks for any help!

edit
Invested some more time and found that Locus shows the sqlite file empty (grey) also when viewed alone. (Had the Hike&Bike hillshade overlay on by accident). Made some tests with other formats (paper atlas and export to Orux) and also exported other sources with sqlite from mobac to Locus. No problems. Only the Hillshade overlay is not shown only in Locus.Any ideas?

[kech61]

Hi,

All I can say is that I can confirm this
In addition if you try to reprocess the tiles as png (8/4bit) the screen is black.

The unprocessed version is IMO useless because of the size of the resulting file.
@Menion, is there any way to get a reprocessed (small) offline hillshading sqlite file working in Locus?

[Menion]

I'm not familiar with mobac, so may you guys create for me two small maps (just for example four tiles) as noisyriver describe as map 3. and 4.

3. Hike & Bike Map hill shade layer (same region) without compression and recalculation to Rmap sqlite: No problem in Locus
4. Hike & Bike Map hill shade layer (same region) with compression and recalculation to Rmap sqlite: Empty (grey) in Locus

so I should compare where are main differences in stored format and try to fix map 4. thanks

[kech61]

so I should compare where are main differences in stored format and try to fix map 4. thanks

Hi Menion,

I made 3 Versions, zoomlevel 10-14:

uprocessed
jpeg 50% compression
png 8bit (the smalest file by far, ...if OK)

Permalink: http://www.openstreetmap.org/?lat=48.29 ... 0&layers=M
Zip-File: www.openandromaps.org/files/shade_test.zip

Thanks for all your efforts,
Christian

[Menion]

Christian, I thanks you ...

anyway I'm quite confused now. File ShadeTest_png8bit.sqlitedb seems to contain 1364 tiles where all are just 141 bytes big images. In all programs I tried, it display just completely black tile. Are you sure this works? Because 141 bytes is quite low on tile where should be at least something ... (and all, tested 3 from different places, are same 141 b)

[kech61]

Christian, I thanks you ...

anyway I'm quite confused now. File ShadeTest_png8bit.sqlitedb seems to contain 1364 tiles where all are just 141 bytes big images. In all programs I tried, it display just completely black tile. Are you sure this works? Because 141 bytes is quite low on tile where should be at least something ... (and all, tested 3 from different places, are same 141 b)

Hi Menion,

I just tried to work with a original tile (with lots of elevation data) from tileserver and optimized it in Fireworks.
original file: PNG 43k
jpeg50%: 7k
optimized png (palette optimized, Alphatrans, png8, bells n' whistles) = 10-14k

So the png8-file from Mobac is definitly broken and the way to go is IMO the optimized (shrinked) jpg.
I hope that the 50%jpeg is OK out of Mobac.

The overall size of the resulting sqlite-db seems to vary between the different sqlite-formats too.

I will do some further testing and report.

[kech61]

Hi Menion,

I will stop this (hillshading with Mobac) and switch to Maperitive - I'v read that Locus support MBTiles sqlite-format > is this Format capable to support transparent hillshading as overlay in Locus?
Actually I cant provide an example - I'v to learn to drive Maperitive  :roll:

Best regards,
Christian

[Menion]

Hello Christian,
  I played a while with Maperitive. After around 4 hours it created complete hillshade map for czech republic in levels around 10 - 15 and size around 200 MB, not bad. Anyway I just tried to display it and seems that it do not work. Locus is trying to load images but without success. I'll try it later anyway all I do inside locus is using function "Bitmap.createFrom(byte[] data)" ... where byte[] is just array of bytes and Android itself handle it and create bitmap image from raw data. So there is not much space for some improvements. I'll check it anyway once more

[kech61]

Hello Christian,
  I played a while with Maperitive.

Hi Menion,

After some testing with maperative I can say that it works.
You have to set map-background-opacity  to "0" in the ruleset and reaply it right bevor generating Hillshade (the ordinary hillshade, not the Igor-relief)

The problem ist that Mobac destroys the transparency of the tiles when trying to shrink them.
So the Tiles have to generated and processed within the tiles/-Folder one by one, preserving transparency,  _bevore_ feeding them into mobac.

HUHU..  

This means for the Alps processing of about one millon tiles (Level 8 to 15).
I wrote a script for parallelization of this, its curently running, an running and...

The tiles/-folder for the Alps (Level 8-15) is as heavy as 9GB,  :shock: I hope to shrink it to >2GB

For a small area I tested this and it works = maperative>shrinking Tiles>Mobac>RmapsSqlite>Locus, however its real heavy number crunching.

Edit: I tested mbtiles-Format right out of Maperitive and it worked, however there is noch chance to shrink it so: not the way to go.

[Menion]

hmm these are terrible numbers. I was really happy when I firstly saw your file with shading. File ShadeTest_png8bit.sqlitedb .. it looked that it's possible to create so small file with shading nevermind ...

I have similar result as you. 200MB just shading for Czech, isn't bad. 9 GB for Alps, is worst ... also on second side it means another around 4 MB of RAM consumed on average device (as an overlays), also speed reduction etc ... I think way to go is with "Locus internal shader", it just needs to improve little bit. Did you tried shading of vector maps in Locus?

If not, check Locus configuration file http://docs.locusmap.eu/doku.php/manual ... ation_file and last parameter dev_enable_vector_maps_hillshade set to 1. Locus will then use HGT files and generate "shading" on vector maps ...

EDIT: with latest 2.12.2 version it really isn't so bad

[kech61]

If not, check Locus configuration file http://docs.locusmap.eu/doku.php/manual ... ation_file and last parameter dev_enable_vector_maps_hillshade set to 1. Locus will then use HGT files and generate "shading" on vector maps ...

Hi Menion,

Always a step ahead    , isnt it  
I tried your solution with viewfinder .hgt's and for me this is deffinitly the way to go - thanks for bringing this Beta-feature to my attention, it will save a lot of time for walking, cycling etc. instead of sitting at the computer - THUMBS UP!

[Menion]

Hello,
 not always . It's still not perfect. Main problem for me is that I still use software rendering on Android (not OpenGL) and there are some issues, anyway as you wrote - this is the way to go. As we both know, sizes of shadings images are quite crazy and this is very elegant solution where 3' HGT files are enough, so not so much space is needed.

[joze]

Hi,

I tried dev_enable_vector_maps_hillshade and it seems to me that it generates a very weird blotchy hillshading where especially small gradients are over-exaggerated.

Here's a comparison.

Left: openandromaps.org vector map with locus hill shading (by dev_enable_vector_maps_hillshade). height data is dem3 files from viewfinderpanoramas.org
second: alpha.map1.eu raster map with it's own hill shading
third: hikebikemap raster map with it's own hill shading
right: hill shading created myself from dem3 files from viewfinderpanoramas.org by maperitive and mobac

Thus at least the left and right images use the very same source dem3 files from viewfinderpanoramas.org

As you can see, small gradients are largely exaggerated by the locus built in hill shading, see for example red arrow which points to a region with low gradients. As I know the displayed region, I can say that the raster images correspond to reality MUCH better than what is generated by locus.

--> what algorithm do you use to display the height data?

[gynta]

compare?
oh yes! let's  compare  :mrgreen:

means, Locus is not soo bad...

[joze]

compare?
oh yes! let's  compare  :mrgreen:

means, Locus is not soo bad...

Hi,

thanks for this exhaustive comparison -- but still I think that all example show that locus' built-in hill shading does it sub-optimal.