Select to view content in your preferred language

Level of Detail for Custom Tile Cache

1665
5
02-23-2018 04:09 AM
New Contributor II

Hello,

I have a question about computing the values for the LevelOfDetail class, which is necessary for a custom tile cache implementation. How they are computed/calculated?

First a short description of my problem. I have WebMercator based tile caches with only a single level. Each of the tile caches are created from a single GeoTiff with GDAL 2.x. Displaying these caches is solved through an implementation of a custom tile cache as a ServiceImageTiledLayer. Because the GeoTiffs for different scales don't have the same bounds/extens sometimes, each is one tile cache.

So far, everything is fine, but the level ordering bases on the scale of the LevelOfDetail. To get the caches in the right order and visible levels this value is necessary, but I don't know how I can compute it or get it from somewhere.

As I understand it, the resolution must be the value of one pixel in map units (here meters) and the scale would be for example one meter screen to meters on map. Is this right? If yes, how can I get/calculate this value?

Thanks and best regards,

Oliver

5 Replies
New Contributor II

In the meantime, I solved the problem. Because the scale is depends on the screen resoultion (DPI). The formula is as folllowing:

var scale = dpi / 0.0254 * resolution;

The scale ist the denominator of 1:scale. We know the resoultion, which means the map units per pixel. Thus, we have to figure out the, how many pixel per meter on the screen we have. This is done by dpi * (1m / 1inch) and all together is the formula.

Maybe that helps someone else.

@Esri: I would be nice to have a method to calc this or getting the DPI of a GeoView.

Esri Notable Contributor

> because the scale is depends on the screen resolution (DPI)

Yes and no. We always assume the device-independent DPI to calculate the scale, which means it is basically 96dpi, but the DPI value here shouldn't be the dpi of the screen, but the dpi the tile was created for.

If we didn't do that, on high-res devices we'd be loading tiles so tiny that for instance an labels baked in would be unreadable, and you'd be download way more data than you can probably even see.

So the 96dpi value is only correct if you use the defaults for generating your cache. You could generate higher-res tiles, and in that case you'd use a different value.

The sample I posted here is probably helpful to you:

(the issue itself is a little outdated, since OpenStreetMap and WMTS is now built-in but the general approach for a custom layer is still the same)

I would be nice to have a method to calc this or getting the DPI of a GeoView

All the platforms the SDK supports already provides this capability. However as mentioned you really don't need it, as you should be using the DPI of your data, not your device.

Esri Notable Contributor

I forgot to mention... the runtime supports direct-read of rasters, and supports pretty much all the formats GDAL supports (it is in fact powered by GDAL too).

Check out the raster classes.

New Contributor II

Thanks Morten,
it was not clear to me, that these values depend on the tile information. This is for me in some cases a problem I have with the API documentation. For somebody who is not familiar with the general GIS topics there is sometimes a lack of information to deal with the usage.

The support of the GDAL formats are great. In this special case we have to share a format between two grown applications where we had to follow this way, because of sharing the cache structure. So, it was the only way to do it.

Kind regards,

Oliver

Esri Contributor

Good point. We also sometimes find gaps in the documentation. Above all, detailed information is missing now and then.
What is the best way to report such gaps?