MBTiles for OpenCPN

[Gilletarom]

It's also my opinion. But, can we speak of community or only of particularly talented people?

[bcn]

Some more background:

from here:
Projections | Information | OpenStreetMapData

WGS84 (EPSG 4326)

OpenStreetMap uses the WGS84 spatial reference system used by the Global Positioning System (GPS). It uses geographic coordinates between -180° and 180° longitude and -90° and 90° latitude. So this is the "native" OSM format.

This is the right choice for you if you need geographical coordinates or want to transform the coordinates into some other spatial reference system or projection.

Mercator (EPSG 3857)

Most tiled web maps (such as the standard OSM maps and Google Maps) use this Mercator projection.

The map area of such maps is a square with x and y coordiates both between -20,037,508.34 and 20,037,508.34 meters. As a result data north of about 85.1° and south of about -85.1° latitude can not be shown and has been cut off.

The correct EPSG code for this data is 3857 and this is what the data files show. Before this code was allocated other codes such as 900913 were used. If your software does not understand the 3857 code you might need to upgrade. See this page for all the details.

This is the right choice for you if you are creating tiled web maps.

Christoph is a very actively involved in OpenStreetMap and an expert in working with geo-referenced data. A wealth of infos at his blog for example: imagico.de - Home

Nota bene: WGS84 is a datum, not a projection. Mercator or WebMercator as used in mbTiles are projections for data referenced to some datum as WGS84, UTM, NAD, ETRS...

More here in a friendly form:
EPSG 4326 vs EPSG 3857 (projections, datums, coordinate systems, and more!) – Victory Formation

and with more examples here:
https://source.opennews.org/articles...ap-projection/

[rgleason]

Gilletarom, what you say is true enough... talented people.

Originally Posted by Gilletarom

It's also my opinion. But, can we speak of community or only of particularly talented people?

[Gilletarom]

Hello Dave, Hello Pavel or Hello Pavel, Hello Dave,

At this stage of the debate on the nature of MBTiles card files, we must now consider:
- That the geographic extent of the areas covered by these types of maps is rather small to avoid positioning anomalies?
- That cards made "by hand" (for example from SAS planet) may be dangerous because:
* lack of geolocation that can accumulate?
** use of inappropriate projections, different from the WGS84 projection?


Gilletarom.

[bdbcat]

SailorF54...

Current github contains corrections which allow your SAS2 tileset to load and display correctly, at least for me.

There were problems with memory management and chart georef calculation.

On this tileset, the challenge to display performance is zooming out on higher zoom factor tiles. This is called "underzoom", and really stresses memory on tilesets with full region coverage of high zoom (large scale) tiles. You may wish to experiment with the Options->Display->Advanced->RasterZoomFactor to explore the effect.

While they take more effort and experience to create, better tilesets (for OpenCPN) will have large scale tiles only where they are needed (harbors, rivers, etc). The large scale tile array will be sparse, but that is OK. We don't need high zoom in the middle of the ocean.

And this is, of course, the same way that experienced cartographers compose paper charts.

Thanks
Dave

[sailorF54]

Originally Posted by bdbcat

SailorF54...

Current github contains corrections which allow your SAS2 tileset to load and display correctly, at least for me.

There were problems with memory management and chart georef calculation.

On this tileset, the challenge to display performance is zooming out on higher zoom factor tiles. This is called "underzoom", and really stresses memory on tilesets with full region coverage of high zoom (large scale) tiles. You may wish to experiment with the Options->Display->Advanced->RasterZoomFactor to explore the effect.

While they take more effort and experience to create, better tilesets (for OpenCPN) will have large scale tiles only where they are needed (harbors, rivers, etc). The large scale tile array will be sparse, but that is OK. We don't need high zoom in the middle of the ocean.

And this is, of course, the same way that experienced cartographers compose paper charts.

Thanks
Dave

Thanks Dave
Your points are quite clear (and may explain why I had problems on certain mbTile charts and not others of same size)

However building throws the following error
(-- The C compiler identification is GNU 7.2.0
Ubuntu 17.10
FWIW with/without libsqlite0 sqlite3 installed)

[CODE][[ 16%] Building CXX object CMakeFiles/SQLiteCpp.dir/src/SQLiteCpp/src/Backup.cpp.o
/usr/bin/c++ -DLINUX_CRASHRPT -DOCPN_HAVE_X11 -DOCPN_USE_PORTAUDIO -DSQLITE_USE_LEGACY_STRUCT -DTIXML_USE_STL -DUSE_GARMINHOST -DUSE_LZMA -DUSE_RENDER_CAIRO -DUSE_S57 -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__OCPN_USE_CURL__ -D__WXGTK__ -DocpnUSE_GL -DocpnUSE_SVG -DwxsvgUSE_EXIF -I/home/pytheas/OpenCPN/src/mygdal -isystem /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -isystem /usr/include/wx-3.0 -I/home/pytheas/OpenCPN/include -I/home/pytheas/OpenCPN/src -I/usr/include/x86_64-linux-gnu -I/home/pytheas/OpenCPN/src/wxcurl -I/usr/include/cairo -I/home/pytheas/OpenCPN/src/wxsvg/include/wxSVG -I/home/pytheas/OpenCPN/src/wxsvg/include/wxSVGXML -I/home/pytheas/OpenCPN/src/wxsvg/include -I/home/pytheas/OpenCPN/src/wxsvg/src -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/home/pytheas/OpenCPN/src/SQLiteCpp/include -I/home/pytheas/OpenCPN/src/nmea0183 -I/home/pytheas/OpenCPN/src/garmin/jeeps -I/home/pytheas/OpenCPN/src/texcmp/lz4 -I/home/pytheas/OpenCPN/src/texcmp/squish -I/home/pytheas/OpenCPN/build/CMakeFiles/include -pthread -O3 -DNDEBUG -Wall -Wno-unused -fexceptions -rdynamic -g -fno-strict-aliasing -DPREFIX=\"/usr/local\" -o CMakeFiles/SQLiteCpp.dir/src/SQLiteCpp/src/Backup.cpp.o -c /home/pytheas/OpenCPN/src/SQLiteCpp/src/Backup.cpp

In file included from /home/pytheas/OpenCPN/src/SQLiteCpp/src/Backup.cpp:16:0:
/usr/include/sqlite3.h:3712:16: error: using typedef-name ‘sqlite3_value’ after ‘struct’
typedef struct sqlite3_value sqlite3_value;
^~~~~~~~~~~~~
In file included from /home/pytheas/OpenCPN/src/SQLiteCpp/include/SQLiteCpp/Backup.h:14:0,
from /home/pytheas/OpenCPN/src/SQLiteCpp/src/Backup.cpp:12:
/home/pytheas/OpenCPN/src/SQLiteCpp/include/SQLiteCpp/Database.h:26:20: note: ‘sqlite3_value’ has a previous declaration here
typedef struct Mem sqlite3_value;
^~~~~~~~~~~~~
In file included from /home/pytheas/OpenCPN/src/SQLiteCpp/src/Backup.cpp:16:0:
/usr/include/sqlite3.h:3712:30: error: conflicting declaration ‘typedef int sqlite3_value’
typedef struct sqlite3_value sqlite3_value;
^~~~~~~~~~~~~
In file included from /home/pytheas/OpenCPN/src/SQLiteCpp/include/SQLiteCpp/Backup.h:14:0,
from /home/pytheas/OpenCPN/src/SQLiteCpp/src/Backup.cpp:12:
/home/pytheas/OpenCPN/src/SQLiteCpp/include/SQLiteCpp/Database.h:26:20: note: previous declaration as ‘typedef struct Mem sqlite3_value’
typedef struct Mem sqlite3_value;
^~~~~~~~~~~~~
CMakeFiles/SQLiteCpp.dir/build.make:65 : la recette pour la cible « CMakeFiles/SQLiteCpp.dir/src/SQLiteCpp/src/Backup.cpp.o » a échouée
make[2]: *** [CMakeFiles/SQLiteCpp.dir/src/SQLiteCpp/src/Backup.cpp.o] Erreur 1
/CODE]

[sailorF54]

Originally Posted by sailorF54

Thanks Dave
....

Latest git builds fine on W10 VS 2017
O digests and displays my SAS tileset beautifully...



PS As a stress test, it gulped down and can display a 1.8 Go tileset (largest file 600 Mo, including the previous SAS set) without retching !

[sailorF54]

Originally Posted by Gilletarom

Hello Dave, Hello Pavel or Hello Pavel, Hello Dave,

At this stage of the debate on the nature of MBTiles card files, we must now consider:
- That the geographic extent of the areas covered by these types of maps is rather small to avoid positioning anomalies?
- That cards made "by hand" (for example from SAS planet) may be dangerous because:
* lack of geolocation that can accumulate?
** use of inappropriate projections, different from the WGS84 projection?

Gilletarom.

I think we shouldn't jump to hasty conclusions
What amount of discrepancy should we expect when charting a 'small' area starting from accurate SASPlanet tiles ? (e.g. some 10 km x some 10 km)

[nohal]

Originally Posted by sailorF54

However building throws the following error
(-- The C compiler identification is GNU 7.2.0
Ubuntu 17.10
FWIW with/without libsqlite0 sqlite3 installed)

Francois...

This you should be able to work around by commenting out https://github.com/OpenCPN/OpenCPN/b...Lists.txt#L941
Until we have a better fix...

Pavel

[sailorF54]

Originally Posted by nohal

Francois...

This you should be able to work around by commenting out https://github.com/OpenCPN/OpenCPN/b...Lists.txt#L941
Until we have a better fix...

Pavel

Hello Pavel



Thanks

[Baikal]

Works fine cutting tiles on a polygonal area
Works without any glitches if you prepare a file of three scales

It works pretty fast with a large array of data

Is it possible to implement the co-ordination of the vector map ENC and MBtiles?
as in the video

https://www.youtube.com/watch?v=n4m7_A_3puE

https://youtu.be/Xaom8_E1yHw

[seandepagnier]

Originally Posted by bdbcat

SailorF54...

Current github contains corrections which allow your SAS2 tileset to load and display correctly, at least for me.

There were problems with memory management and chart georef calculation.

On this tileset, the challenge to display performance is zooming out on higher zoom factor tiles. This is called "underzoom", and really stresses memory on tilesets with full region coverage of high zoom (large scale) tiles. You may wish to experiment with the Options->Display->Advanced->RasterZoomFactor to explore the effect.

If I am not mistaken, using underzoom factor less than 0.5 is not very useful, but also difficult because of the memory usage. With raster charts we have mipmaps, and the logic is implemented to only upload the reduced data to video memory. When the cache is built, there is no longer any stress for under zoom.

In the case of mbtiles, the tiles should have a smaller zoom tile set to use. If it does not, I would suggest that the chart not appear at all, looking for alternative charts that are better suited instead. If none exist, then the normal background map. The outline should still be shown. This might require "composite" type logic, but it is what is really needed here.

I also believe that mbtile charts should not be considered "raster" charts on the bar. They should have their own unique color like cm93. They really are a new category of chart and should be treated as such. When partially transparent tiles are implemented this will become more apparent.

[Baikal]

Why is it and do not take into account the small scale on the zoom 18,19,20 (sasplanet)
Maximum visible 17-18 scale

[bcn]

Baikal,

a zoom level of 20 means at your latitude a scale of aprox. 1:500 or 15cm/px (depending on size and resolution of the monitor).

Do you want to dock automatically?

There is a cost to pay in terms of file size going to very big scales.
And which source material delivers such a true resolution?

A reference for the zoom levels here:
https://wiki.openstreetmap.org/wiki/Zoom_levels
(some count ZL from 0-19, others from 1-20)

Hubert

[pinguino]

I have created an MBTiles file that includes Ibiza and Formentera with a scale of between z9 and z18 and weighs just over 240 mb.

I like the way it works. I'm very happy with how the layers are showing up. Nice.

I think z18 is a scale that's right enough. Not more zoom is needed, in my opinion.







Is there any way to stop the overzoom message from showing in mbtiles files?