3d max zoomlevel generated but never used

[ltclm]

The most detailed zoomlevel of swissimage product layer which has been generated is zoomlevel 18 (native 4326 pyramid). This zoomlevel is never used in the application. the same for these layers: ch.swisstopo.swisstlm3d-karte-farbe.3d ch.swisstopo.swisstlm3d-karte-grau.3d

[oterral]

Since the config 3d of a layer doesn't inherit the resolutions array of the config 2d. The 3d layer takes default value for the max lod (17). So we have 2 choices:

• Add inheritance between config 2d and 3d (at least for the resolutions array)

or

• Add the resolutions array in the 3d config of layer

[loicgasser]

Add inheritance between config 2d and 3d (at least for the resolutions array)

Well it's different tiles and resolutions, I don't know how we would inherit that.

Add the resolutions array in the 3d config of layer

:+1: Yes and use a default one for the most common array of resoultions like in 2D.

[oterral]

I told about inheritance because we need to know the minResolutions of the 2d layer to determine the max lod we must use in 3d. I guess we can calculate the max lod when we get the config3d and so avoid the inheritance of the property which doesn't makes sense.

[loicgasser]

yes that's true for mapProxy whereas for native tiles in wgs84, the limitation is physical.

[ltclm]

the max lod of native wgs84 tiles is in the bod table tileset (attribute tilematrixsetid in the view re3.view_layers_js). Our native wgs84 tiles are all generated until zoomlevel 18 (+/- 10cm Resolution) https://github.com/geoadmin/bgdi-tilegenerator/blob/master/etc/tilecache.swisstopo.4326.cfg#L24

Shouldn't we add this information to the layersconfig service?

[gjn]

For native tiles, we should have it in the bod, as for any other pre-generated tiles.

[loicgasser]

It's settled then, I'll add it to the layersConfig when it's different from the default resolutions.

[oterral]

It makes sense to have it in the layers config.

But we also can calculate the max lod from 2d resolutions array, we actually do that for minRes and maxRes.

[loicgasser]

That would be nice for all mapProxy layers, e.g. most of them. @oterral You want to take care of this part?

[loicgasser]

Mmmm, Cesium is contrained by this layer.json file, changing the LOD won't change anything. I found out the hard way. We need to use layer.json specific files for these 3 layers if we want to be able to load the last level. https://github.com/geoadmin/mf-geoadmin3/compare/gal_max_lod?expand=1#diff-66ac86f99915855fde57c0a20d8f6d6bL1123 Current diff

[loicgasser]

@oterral Shall we adapt the Cesium fork so that this parameter is taken into account or shall we adapt the layer.json config for these layers.

[gjn]

I think cesium behaviour (in our c2c patch) makes sense: if you specify a layer.json, then it should be used.

Did you try to not use metadataUrl for this layer and specify maxLod by hand? Does it work?

[loicgasser]

yes it works you actually can load the last level if you use the PR I made in chsdi and the branch I am referring to in this issue and you simply remove the metadataUrl. but then you have the issue of the 204 errors. Another solution would be to use the terrain metadata per default and use a custom metadataUrl if defined in the layers configuration.

[oterral]

That would be nice for all mapProxy layers, e.g. most of them. @oterral You want to take care of this part?

If I remember we choose to block the layers to lod 17 by default to avoid too much requests. SInce we already removed the use of layer.json for overlays, we should verify the impact on the infra if we allow all layers to level 18.

I think only the terrain should have a layer.json defined then the overlays should be displayed only where terrain is available. Then definition of a maxLod for overlay layers should do to the trick if not matadataUrl defined.