Does vts support using high precision area mosaic with low precision area terrain?

[Davionshi]

Hi, MelownTech team. I'm interested in VTS backend, but when I set mine own vts backend, it occured some issues. According to the sample of VTS backend documentation, it's ok to using high precision data to generate global mosaic data of Mars and using a bit low precision data to generate global terrain data. But when I use Level 20 precision data of area mosaic and Level 15(even lower) precision data of area terrain, I only can see the low level precision texture on the terrain. Here is the details pictures.

[a180285]

Hi @vaclavblazek . Could you give us a help?

We are try to load level 20 image on level 15 terrain.

But it seems not work. We can only see very blurry image on the terrain.

Is there any limitation on terrain / dem data match with high level image data.

[vaclavblazek]

Hi,

We are try to load level 20 image on level 15 terrain.

If you mean that boundlayer (imagery) is 20 LODd deep and terrain is only 15 LODs deep it should work. Is the bound layer really that deep? You can navigate (in the web browser) to the directory with boundlayer and see the actual data, if you switch on grid layer you'll see the tile information.

Also, how does the boundlayer.json of that particular boundlayer look like? Can you paste it here, pls? You can catch the URL to this file in your browser's dev tools network tab (don't forget to reload the page after opening network tab) and display its content in separate window.

[jrjdavidson]

@vaclavblazek i wonder if this is a problem similar to this: https://github.com/melowntech/vts-backend/issues/14

[Davionshi]

Hi @vaclavblazek , Here are json files below, maybe they can provide some useful infomation to you to solve this issue.
Configrations.zip And this issue is similar to https://github.com/melowntech/vts-backend/issues/14, but I don't have any idea about how to use "mapproxy-setup-resource" because this cmd seems not be mentioned by documentationhttps://vts-geospatial.org/tutorials/landuse-wms-dem-cities.html, so can you provide some explains about this cmd pls? Does this cmd used to process the datasets in three folders which generated by "generatevrtwo"(I means min, max ,cubicspline)?

[jrjdavidson]

In order to display lod20 bound layers, your surface also has to be processed to lod20. Not ideal but just quirk you need to work with.

Now that I learned how to use mapproxy-resource-setup, I use it all the time to add new data to maps. Just check out the documentation using the —help flag ( i think that’s the correct flag, sorry I’m not a Linux pro) I would reprocess your surface using the bottomlod flag in mapproxy-setup-resource(e.g. —bottomlod 20).

One caveat though, the downside to having a lod20 surface is that it might be very time consuming to create glues later on, so you should be aware of that and think carefully about how you will put high detailed surfaces together later on.

see how you go, and I’m sure @vaclavblazek might have some thoughts on this too. Cheers

[jrjdavidson]

Whoops, I meant mapproxy-resource -setup

[vaclavblazek]

Ah, sorry, my bad. It's vice-versa: coarser imagery can be draped on finer mesh, not finer imagery on coarser mesh. So, you need finer surface.

However, the source dataset (those min/max/cubicspline GDAL VRT datasets you mentioned) can be used for this task since the finer data are generated from original dataset resolution -- mapproxy is zooming the source data past its natural resolution.

So, you can setup new surface-dem resource in mapproxy, identical to the one you have but with the same LOD range as the boundlayer resource.

I.e. it's gonna be the same resource like in the file testarea-dem.json from Configuration.zip you uploaded here but the LOD range will be 12-19. You need to change the resource ID as well.

Or, if you do not want to change the ID and you are feeling brave, you can update the existing resource, which is normally not recommended -- but you are not using the resource in any VTS storage so it's not gonna break anything.

Mapproxy keeps data 1) in memory and 2) in its on-disk storage. It will protest when some incompatible changes occur and will insist on using the old resource version. In the case of surface, any tile tree structure change or input dataset change is incompatible because it can cause havoc where used.

Recipe follows:

• stop mapproxy
• update the range in the existing resource in the testarea-dem.json file (to 12-19); keep tile range untouched
• add "revision": 1 in the toplevel object in the resource; this causes URLs to have ?r=1 added which would prevent clash with previously (possibly) cached data in your browser
• and now the fun begins: remove the resource from mapproxy's store, i.e. remove the /var/vts/mapproxy/store/melown2015/testJapan/hengxuheshi-dem directory (I hope I composed the path right)
• only now start mapproxy again

Mapproxy will treat the resource as if it has not seen it before and create the necessary data again.

Caveats: You can safely mess with mapproxy's storage only when the surface is not used in another storage. Also, if someone has already displayed the surface in their browser the viewer will hapilly download new data and mix it with the old ones. So, this is only when you have "unpublished" resource and you want to keep its name.

[Davionshi]

It works well! Thanks!

[vaclavblazek]

:+1: