Cadastre tutorial: Explanations on the "referenceFrame" parameter needed

[fnicollet]

Hello,

I am now trying to reproduce the Cadastre tutorial but on my own data (TIFF and LAS files). Quite early in the tutorial, you execute:

mapproxy-calipers srtm/dem --referenceFrame melown2015

What does "--referenceFrame melown2015" mean exactly? Because nowhere before, a referenceFrame was created. Is it something that already exist? Why 2015? I found the page with more explanations (http://melown.readthedocs.io/en/latest/introduction.html#reference-frame), but there should be some details about this magical value here :)

[fnicollet]

Looks like it's taken from a default config file here: https://github.com/Melown/vts-registry/blob/master/registry/registry/referenceframes.json

[fnicollet]

So the actual question is: Do I need to add a referenceFrame to the registry or should I reuse melown2015? My TIFF files are in a french projection, not sure if that needs to be taken into consideration at this step

[vaclavblazek]

A reference frames describes the world: what spatial reference system it uses (and whence what celestial body it models), how is are individual tiles in the tile tree mapped to the world etc.

Reference frames, spatial reference system (SRS) and historically other stuff are taken from VTS registry. Registry is a database shared between components that must be installed on every system VTS software is running. You got it via dependencies in thevts-registry debian package.

Why reference frame melown2015 has 2015 in the name? Is kinda boring: it was specified in the year 2015.

melown2015 reference frame models Earth in geocentric coordinates: full 3D globe. Tile space is divided in a way where major part of the planet is covered in tiles whose spatial division uses so called Pseudo-Mercator SRS that allows us to directly use existing raster map tiles as boundlayer textures, for example we use tiles Bing Maps in our cloud service. Since Psedo-Mercator is defined only in between +85.05 and -85.05 degrees of latitude the remaining cca 5 degrees in the polar areas are modelled via polar stereographic projections.

It doesn't matter what input SRS your data are. Reference frame says how they will be represented in the VTS system and displayed to the user, like:

• melown2015 is whole Earth as a globe described above
• webmerc-projected uses only Pseudo-Mercator projection for Earth while physical data are also in this projected system: you get flat square representation of majority of the planet
• mars-qsc describes planet Mars using 6 different QSC projections
• earth-qsc is Earths equivalent of mars-qsc

In general stick with the melown2015 reference frame for Earth.

[fnicollet]

got it, i'll stick with melown2015 then, thanks 👍

[vaclavblazek]

If you play with bound layers, then ignore this comment. If you want to generate a surface from some TIFF dataset then this is important:

There is one requirement for the input DEM datasets: vertical system must be compatible with vertical system used in VTS. Two vertical system are compatible:

• either they use same reference ellipsoid (e.g. WGS84 for melown-2015)
• or the SRS use vertical system that models local sea level that heights in this system are within reasonable error from geoid combined with reference frames's reference ellipsoid (e.g. WGS84 + EGM96 geoid for melown-2015)

Due to GDAL's inability to keep vertical shift grid inside in SRS stored in various data format there is no way to find out whether heights in DEM are ellipsoidal (measured from reference ellisposoid) or orthometric (measured from geoid, i.e. "above sea"). Currently, the default is to treat data as GDAL reports them due to its deficiency as ellispoidal heights. If the data are, in fact, heights above the sea level you have to use the geoidGrid parameter inside surface-dem definition and set it to egm96_15.gtx.

Since we humans are used to heights above the sea level virtually all DEM (or DSM, or DTM) data are provided as height above sea, i.e. height above geoid. Therefore it is almost always needed to use EGM96 geoid grid. I plan to deduce default from reference frame's public SRS (i.e. the SRS coordinates are presented to the user) in the future, however now we have to live with this vexing geoidGrid parameter.

Wrong interpretation of heights from DEM leads to shift in generated meshes above/below real surface. For example, in the case of the cadastre example the terain would sink some 40 meters below true 3D data if it were misconfigured.

BTW, full mapproxy resource configuration (authoritative) documentation is available at https://github.com/Melown/vts-mapproxy/blob/master/docs/resources.md .

[fnicollet]

Thanks for the details. I have quite a lot to learn :)

I added my tiff layer as a "free layer" because so far I only wanted to display that one. Here is my TIFF in QGIS:

and here is the result in melown browser: zoomed out:

I'm not really surprised about the rendering, it seems that the original TIFF is not really good. The black parts seem to hold a (low) value instead of NODATA, which melown tries to interpret as a sudden fall. In the definition, I left the egm95_15.gtx reference, not sure if that would change anything in my case.

I am going to try and play more with other datasets, see if I can achieve something nicer looking :)

Again, thanks for your help!

[fnicollet]

I could drape Google Maps tiles on the TIFF, it already looks nicer :)

[ladislavhorky]

Hi, as for missing NODATA in your dataset, it is possible to fix that even without modifying original data. NODATA can be optionally overridden in generatevrtwo by --nodata parameter. Snippet from generatevrtwo --help:

  --nodata arg            Optional nodata value override. Can be NONE (to 
                          disable any nodata value) or a (real) number. 
                          Input dataset's nodata value is used if not used.

So the only thing you need to find out is the 'low' value you mentioned.

[fnicollet]

When I query the nodata pixels in QGIS, I get "-32767" as a value, which seem to be the "classic" NODATA value. I tried forcing it with the option:

generatevrtwo cherbourg_MNT_5m_32b_nodata.tif overview --resampling dem --tileSize 1024x1024 --nodata -32767 --overwrite
generatevrtwo cherbourg_MNT_5m_32b_nodata.tif overview.min --resampling min --tileSize 1024x1024 --nodata -32767 --overwrite
generatevrtwo cherbourg_MNT_5m_32b_nodata.tif overview.max --resampling max --tileSize 1024x1024 --nodata -32767 --overwrite

But there doesn't seem to be any change. I executed the "mapproxy-tiling" again (not sure if necessary, I am still trying to figure out what each process do), but no change Do I need to remove+add the tileset to the store? or empty a cache or something?

Thanks, Fabien

[ladislavhorky]

A good practice for testing and experimenting is to set up a new resource in mapproxy every time you change underlying data. This is easily done by just adding/changing version in id of the resource in mapproxy resource configuration and running

/etc/init.d/vts-backend-mapproxy force-update

Then it is also reasonable to stop using the old resource because down the network it becomes an unusable mix of old cached and new fresh data.

As for store, you can just add the tileset of the same tilesetId as the old one with --bumpVersion parameter. Example for SRTM from tutorial:

vts /var/vts/store/stage.melown2015
# Tilesets: 
# ...
#    cadastre-srtm [remote (URL= ...)]
# ...
vts /var/vts/store/stage.melown2015 --add \
--tileset http://127.0.0.1:8070/mapproxy/melown2015/surface/cadastre/srtm-v1 --bottom \
--tilesetId cadastre-srtm --bumpVersion

This will prevent the new tileset from merging with old one. Then just change the mentions of the tileset in storage view from <tileset> to <tileset>@1. This is the simplest way to solve all the caching issues.

As for mapproxy-tiling, in this case you need to run it. You need new tileindex whenever you change the shape of covered area.

Ladislav