Question about using Tilezen elevation as remote datasource for VTS surface

[pjanetzek]

Hello I wonder how much work it would be to add support for generating terrain meshes from this elevation tiles or if you could give me some pointers where to look in the vts code to implement this.

https://registry.opendata.aws/terrain-tiles/ https://elevation-tiles-prod.s3.amazonaws.com/index.html#3/69.13/-127.27

Thanks for this awesome stack - hoping to use it in an upcomping project :)

[pjanetzek]

It's also possible to get the elevation raster tiles as GeoTiff so it should work directly as input. Only thing that needs to be done is the overview generation for remote tiles - is that correct?

https://s3.amazonaws.com/elevation-tiles-prod/geotiff/14/8489/5894.tif

[vaclavblazek]

Mapproxy uses GDAL for raster data handling, so any raster dataset type supported by GDAL is supported my mapproxy. You need to generate 3 overviews to configure surface (i.e. dynamic vts tileset) in mapproxy: 1 generated with cubic or similar filter (to have subsampled heights), another with minimum filter (to have low envelope of heights) and the last one with maximum filter (to have high envelope of heights). These are generated by generatevrtwo tool (which stands for generate VRT dataset with overviews).

To create a resource in mapproxy, you may use mapproxy-setup-resource tool which does all the stuff (generates dataset with overviews, creates tiling info and sets it up in mapproxy).

[pjanetzek]

Oh sorry I forgot to mention that the main intention was to use the DEM tile pyramid for the whole world without having a local copy. I thought that maybe one would not need to generate the overviews as all the LODs (or zoom levels) for 0-14 are directly available.

What I've tried is to use this as tilezen-elevation source

<GDAL_WMS>
    <Service name="TMS">
      <ServerUrl>https://s3.amazonaws.com/elevation-tiles-prod/geotiff/${z}/${y}/${x}.tif</ServerUrl>
      <Transparent>TRUE</Transparent>
    </Service>
    <DataWindow>
       <UpperLeftX>-20037508.34</UpperLeftX>
       <UpperLeftY>20037508.34</UpperLeftY>
       <LowerRightX>20037508.34</LowerRightX>
       <LowerRightY>-20037508.34</LowerRightY>
       <TileLevel>14</TileLevel>
       <TileCountX>1</TileCountX>
       <TileCountY>1</TileCountY>
       <YOrigin>top</YOrigin>
   </DataWindow>
   <Projection>EPSG:3857</Projection>
   <BlockSizeX>512</BlockSizeX>
   <BlockSizeY>512</BlockSizeY>
   <BandsCount>1</BandsCount>
   <OverviewCount>10</OverviewCount>
   <ZeroBlockHttpCodes>404</ZeroBlockHttpCodes>   
   <Cache />
</GDAL_WMS>

  /home/jeff/data/mapproxy/datasets/examples/tilezen:
  total used in directory 16 available 1.7 TiB
  drwxr-xr-x 2 jeff jeff 4096 12. Feb 20:29 .
  drwxr-xr-x 9 jeff jeff 4096 12. Feb 16:43 ..
  lrwxrwxrwx 1 jeff jeff   20 12. Feb 16:47 dem -> ../tilezen-elevation
  lrwxrwxrwx 1 jeff jeff   20 12. Feb 16:47 dem.max -> ../tilezen-elevation
  lrwxrwxrwx 1 jeff jeff   20 12. Feb 16:47 dem.min -> ../tilezen-elevation
  -rw-r--r-- 1 jeff jeff  678 12. Feb 16:37 tiling.melown2015
  -rw-r--r-- 1 jeff jeff  217 12. Feb 20:29 tiling.tms-global-geodetic

And then run mapproxy-tiling tilezen-elevation --output tilezen/tiling.tms-global-geodetic --referenceFrame tms-global-geodetic --lodRange 1,7 --tileRange 0,0:2,2 --registry /home/jeff/data/mapproxy/registry/ --forceWatertight 1

This seems at least to fill the gdalcache and write a tiling :) If this approach could work then it would be ideal if one could prevent mapproxy-tiling to inspect all the tiles when it is known that the whole (pseudo-mercator) extent is covered

[pjanetzek]

Is the min/max elevation strictly required for generating vts surfaces? Or what would fail if this information does not exactly match between zoom-levels?

[pjanetzek]

Actually this works more than I expected - the meshing looks as if it is affected by the DEM, though the vertices are not elevated at all and there are certainly a few y origins flipped (I had to set the curl timeout to 50 seconds for the initial metatiles to be fetched - but then tile loading became super quick)

[pjanetzek]

Is there a command in the vts suite to create and inspect a single tile for easier debugging?

[vaclavblazek]

Is there a command in the vts suite to create and inspect a single tile for easier debugging?

No, not easily.

[vaclavblazek]

Is the min/max elevation strictly required for generating vts surfaces? Or what would fail if this information does not exactly match between zoom-levels?

It is a must, it's how mapproxy works. Parent tile's vertical extent must be at least the same as all its children tiles. Since filter smooth out heightmap the actual data in coarser tiles have narower extent than its finer children we need to keep the min and max info everywhere easily available.

[pjanetzek]

ok thank you - I'll look into this approach later again :)