New beta version 9.x.x

[YvanCB]

Hello Orux,

I think I have found a bug:

If I activate the option "VTM Map Viewer" (Settings/Maps/VTM map viewer) sometimes when I change zoom level there is a map shifting. The visible zone in the screen change of several meters or kilometers.
For information I'm using off line maps created by MOBAC.
When I remove the option : everything is OK.

Regards.

[orux]

Hello Orux,

I think I have found a bug:

If I activate the option "VTM Map Viewer" (Settings/Maps/VTM map viewer) sometimes when I change zoom level there is a map shifting. The visible zone in the screen change of several meters or kilometers.
For information I'm using off line maps created by MOBAC.
When I remove the option : everything is OK.

Regards.

It's possible.

To use the vtm viewer I do some cheating, otrk2 maps have a lot of difficulties to use.

If you can share a map of those with me, to analyze it.

orux

[YvanCB]

Hello Orux,

I put a map on Google Drive. I will send you a link in MP.

Regards.

[YvanCB]

Hello,

When I create my maps with MOBAC, is there any advantage to use "MBTiles SQLites" format instead "Oruxmaps SQLites"?
It seems that the size is smaller...

For the moment I use "Oruxmaps SQLites".
Regards.

[LaurentG]

Hi,

according to me, YES, there are several MAJOR advantages to use "MBTiles SQLite" format instead of "Oruxmaps SQLite".

The main reason is that tiles, in "Oruxmaps SQLite" are 512x512 pixels, while, natively, most of servers serve tiles 256x256 pixels. As a result, with Oruxmaps format, Mobac is obliged to combine several tiles to produce one, with two major drawbacks :
1) It takes a lot of time.
2) Transparency of tiles (in case of origin tiles are PNG with transparency) is LOST

The first point is not really "sensible" if MOBAC has to download tiles from server, since the time lost in recreating  tiles is almost negligeable vs. time spend in network download. But in case tiles are already present in local tilestore, atlas generation, that is in this case free of network time, may be 10 times or more longer with Oruxmaps format than with MBTiles sqlite format.

The second point is of even higher importance : When reprocessing tiles to generate 512x512 px tiles, native transparency (if it exist) is lost. This remove capability to create "composite" maps directly in Oruxmaps, with an opaque background superposed with a transparent atlas (like tracks from WMarkTrails or Strava, or etc...).

On the other hand, there is one "drawback" (that is not really one) to use MBTiles format in Oruxmaps : In case you have created an atlas in which not all conscutive levels are present (eg. an atlas with only levels 10, 12, 14 and 16), when you zoom in Oruxmaps, missing levels are "displayed" (and screen remains empty for these levels, since data is missing) while with OruxMaps format, missing levels are "skipped" (replacing them by digital zooming of lower level).
Nevertheless, this is not really a drawback, since IMHO there is no interest to let some intermediate levels missing. An atlas with level 10, 12, 14 and 16 is only 20% smaller than the same atlas, with all intermediate levels 10, 11, 12, 13, 14, 15 and 16

Personnally, a long time ago, I used to generate "OruxMaps sqlite" format atlases. But since I discovered the "MBTiles sqlite" format, I now use ONLY this one.

[orux]

Hi,

according to me, YES, there are several MAJOR advantages to use "MBTiles SQLite" format instead of "Oruxmaps SQLite".

The main reason is that tiles, in "Oruxmaps SQLite" are 512x512 pixels, while, natively, most of servers serve tiles 256x256 pixels. As a result, with Oruxmaps format, Mobac is obliged to combine several tiles to produce one, with two major drawbacks :
1) It takes a lot of time.
2) Transparency of tiles (in case of origin tiles are PNG with transparency) is LOST

The first point is not really "sensible" if MOBAC has to download tiles from server, since the time lost in recreating  tiles is almost negligeable vs. time spend in network download. But in case tiles are already present in local tilestore, atlas generation, that is in this case free of network time, may be 10 times or more longer with Oruxmaps format than with MBTiles sqlite format.

The second point is of even higher importance : When reprocessing tiles to generate 512x512 px tiles, native transparency (if it exist) is lost. This remove capability to create "composite" maps directly in Oruxmaps, with an opaque background superposed with a transparent atlas (like tracks from WMarkTrails or Strava, or etc...).

On the other hand, there is one "drawback" (that is not really one) to use MBTiles format in Oruxmaps : In case you have created an atlas in which not all conscutive levels are present (eg. an atlas with only levels 10, 12, 14 and 16), when you zoom in Oruxmaps, missing levels are "displayed" (and screen remains empty for these levels, since data is missing) while with OruxMaps format, missing levels are "skipped" (replacing them by digital zooming of lower level).
Nevertheless, this is not really a drawback, since IMHO there is no interest to let some intermediate levels missing. An atlas with level 10, 12, 14 and 16 is only 20% smaller than the same atlas, with all intermediate levels 10, 11, 12, 13, 14, 15 and 16

Personnally, a long time ago, I used to generate "OruxMaps sqlite" format atlases. But since I discovered the "MBTiles sqlite" format, I now use ONLY this one.

Yes, it is better to use mbtiles if possible.

Other advantages: The mbtiles are always maps with EPSG:3857 projection, they do not need additional files or data. And they are almost a standard, they can be used in many applications.

The advantage of the OruxMaps format is that it supports any projection, it is more flexible.

I didn't know about the transparency issue. I made the mobac plugin a long time ago, I think there were no maps with transparency, we are getting older There was also no possibility to use the mbtiles format. That's why I added mine to the library...

orux

[YvanCB]

...
Nevertheless, this is not really a drawback, since IMHO there is no interest to let some intermediate levels missing. An atlas with level 10, 12, 14 and 16 is only 20% smaller than the same atlas, with all intermediate levels 10, 11, 12, 13, 14, 15 and 16
...

If there are missing layers, it seems that Oruxmaps just apply a numeric zooming of the previous level to create the missing one.
@Orux : Do you confirm?

Regards.

[YvanCB]

Hello,

I have troubles with MBTiles format map creation with Mobac.
The created Map is OK but the covered area is not the same as before (with Oruxmaps format).
I use the same coordinates, the Tile (x or y / zoom) system.
Please have a look to my 2 maps M11 created with Oruxmaps and MBTiles format (attached file).

This is not very easy to understand the way this different format works.

Regards.

[YvanCB]

Hello,

I think I have found the problem with map creation on Mobac and MBTiles format.

With MBTiles format the white frame on the border of the map is for the smallest zoom level (the biggest area, Z10).
With Oruxmaps format the white frame on the border of the map is for the biggest zoom level (the smallest area, z17).

If I'm right, is it possible to make MBTiles works the same way that Oruxmaps,
the white frame around the biggest zoom level?

Regards.

[dietherr]

Hi,

i've the same problem with zooming.
I'm using Openandromaps with the Elevate-Mapstyle.

When i decrease zoom-level, it's not possible to increase after that.
The zoom-level then stays decreased.

Best Regards
Didi

[YvanCB]

Hello,
I'm here again with my problem of frames with MBTiles format maps.
Does somebody have the same issue?
I really want to use the MBTiles format. It's faster to create Maps. But with this issue I'm confused, the shown delimited zone is for the zoom z10, I would like to have the zoom Z17.
Regards.

[YvanCB]

Perhaps the problem comes from the fact that with Oruxmaps maps format there is one file for each zoom level?
With MBTiles maps format there only one file for all zoom levels.
Am I right? Is there a way to change this?
Regards.

[Juanjo]

Hello,
I'm here again with my problem of frames with MBTiles format maps.
Does somebody have the same issue?
I really want to use the MBTiles format. It's faster to create Maps. But with this issue I'm confused, the shown delimited zone is for the zoom z10, I would like to have the zoom Z17.
Regards.

Hi,

I think the issue isn't with oruxmaps but with the way you create your MBTILES with MOBAC.
In MOBAC you can display a grid that correspond to tiles boundaries at a given zoom level. You have to display it at the lowest zoom level you are going to use in the map you want to create, that way, all the zoom levels in the resulting map will cover exactly the same area.
If you choose an higher zoom level for the grid, lower zoom levels of the map will cover an bigger area than higher ones.

BTW, it makes little sense to skip zoom levels as you do.

Cheers

[LaurentG]

BTW, it makes little sense to skip zoom levels as you do.

I would even say more : With MBTiles format, you MUSTN'T skip zoom levels. Otherwise, when you zoom in OruxMaps at a level that is not present in the Atlas, OM displays what is in the atlas....ie. an empty map !
It's actually the ONLY known drawback of MBTiles format vs OruxMaps Sqlite format (in OM Sqlte, when a level is missing, OruxMaps displays a numeric zoom of the level below, rather than an empty level)

And even with OruxMaps Sqlite format, it would make no sense to skip zoom levels. In your example, if you add the missing levels, 12, 14 and 16, your atlas will be only 25% larger than without them

Now, on the root of your initial question, Juanjo's answer is the right one.

In OruxMaps format, the bounds of the map are defined level per level (in the xml file), and OM consider the "smallest" bounds (the one covered by all levels) as the map bounds.
While in MBTiles format, they are defined ony once (in the database) for all levels, and it is the "largest" bounds (the one covered by at least one level) that are memorized as the map bounds.
To reach your request, then, two solutions :
- do as described by Juanjo (because in this case, all the levels have the same bounds)
- or ask a modification of MOBAC (in MOBAC's forum) to put in MBTile databse the bounds of the highest level rather than those of the lowest one.
But clearly, there is nothing to modify in OruxMaps itself

I just asked for the modification in MOBAC. (see here : https://sourceforge.net/p/mobac/forum/general/thread/3a86f69952/ )
We'll see how it will end...

[Juanjo]

I just asked for the modification in MOBAC. (see here : https://sourceforge.net/p/mobac/forum/general/thread/3a86f69952/ )
We'll see how it will end...

Good ;-)

As an argument to convince MOBAC developer, you can point him to the MBTiles spec, which explicitly states that 'Bounds must define an area covered by all zoom levels'