MBTile overlaps... OpenCPN choosing wrong zoom?

[bbalan]

Hi Dave and everyone,
I've been creating several new sets of charts for The Chart Locker and have come across some interesting behavior in OpenCPN.

In the past I've created close-up charts at Z 12,15,18 and an separate overview at Z8 & 10. I'm not sure why I did that but it worked well.


I'm now including all zoom levels in the new MBTiles to simplify things. The MBTiles are created in SASPlanet using a 8km radius on a path. Since Z8 and 10 are very large tiles, MBTiles from different paths may have areas where the Z8/10 of one MBtile overlaps the Z12/15/18 of another. When that happens, sometimes the overlap area ONLY displays the Z8/10 tile.

In the examples below, the first image shows the West Coast of Baja. There are a few tiles that have a corner extending over to the East Coast of the Baja. The second image shows the coverage of the East Coast. And the third image shows a close up of an area of overlap (circled in the 2nd image). You can see how the West Coast tile is blurry where it overlaps the East Coast tile.

Hope that's clear. Any thoughts on this?

Many thanks,
Bruce
s/v Migration

[nohal]

Originally Posted by bbalan

Hope that's clear. Any thoughts on this?

There will always be corner cases like this when we do not have all the tiles at all the zoom levels available as we have to balance between performance and accuracy in the quilting algorithm.
In this particular case I suppose that both the tilesets "promise" having the same quality (maximum zoomlevel they contain) of the content in the metadata and they claim to cover the same "problematic" area (which they do, but not at all the ZLs they contain), so the first to come into the way of the quilting algorithm gets displayed as we do not check if all the zoom levels available really cover 100% of the area claimed by the metadata.
The simple solution for you is to create the tilesets for areas like this starting with a more detailed minimum zoom level - like Z9 instead of Z8 or Z11 instead of Z10, whatever the lowest you use is to avoid the overlay between high-res imagery useful for navigation and pretty much useless low resolution background from other tilesets.
Of course the ideal solution would be to scan the tilesets for the polygons actually covered by tiles existing at each zoom level and take that into account for quilting, but that would be extremely costly performance-wise, totally unacceptable for higher zoom levels where the tile count per ZL pass the order of thousands.

Pavel

[bbalan]

Hi Pavel,
Thanks for the great explanation.

Yes, both tilesets do 'promise' the same ZLs, so that makes perfect sense that OpenCPN doesn't know that Z18 tiles don't exist for all the areas covered by Z10. And now that you point it out, I see that scanning all the tilesets for the lowest zoom at every point would be a huge drag on performance.


I liked being able to make many charts by just choosing consistent ZLs every time... but I see that I will have to look at the tile boundaries and, as you suggest, choose a ZL that doesn't create overlaps with neighboring paths. Ack... more work!


Thanks so much.
Cheers,
Bruce
s/v Migration
The Chartlocker