Image Overlays: Allow for "dynamic" depth and loaded tile size

[gkjohnson]

Right now image overlays expect and require a fixed "levels" depth which is used to limit the tile requests or further split tiles to increase the detail resolution. But overlays like WMS (#1302) potentially allow for arbitrarily sized images requests and svg or geojson (#1305) can be scaled arbitrarily with no added detail on zoom, so ideally it wouldn't start splitting tiles unless the user wanted it to.

The nature of the two image sources also potentially means that tiled images can be fetched arbitrarily rather than being composed, as overlays are done now:

• Allow for "null" or "-1" levels that will allow for generating / loading new content only up to the depth of geometric tiles and not allow for splitting. Alternatively this could mean that the "enableSplitting" flag should be on the overlay instance rather than the root overlay class.
• Allow for fetching the exact image range that is required for tile rather than composing the tile data from multiple images.

[Brakebein]

I'm not sure if this is related to this issue, but I noticed that when zooming in or navigating close to the surface, then rendered texture gets very blurry. I would expect that the next zoom levels are getting loaded earlier to improve the visual quality. However, the closer you get to the surface, the later, it seems, the next zoom level is loaded.

How can the quality be improved?

You can check on your Quantized Mesh with Overlays example, best with OpenStreetMap XYZ tiles.

I also noticed that, especially at rivers, there are many white/untextured triangles. This occurs at many places/rivers worldwide.

[gkjohnson]

@Brakebein this issue is for data overlays that contain an arbitrary level of procedural detail like GeoJSON. Please make a new issue for your question.

[Brakebein]

Okay, I opened a new issue: #1334