[GRASS5] Re: Vertical datum support for 5.7

[Paul Kelly]

Hello Helena

Helena wrote:
> 
> I would like to make a suggestion for adding support for vertical
> datum into GRASS or at least add the info to the PROJ_INFO file,
> so that the conversion can be added later without the need
> to change the PROJ_INFO file, e.g.:
> 
> name: State Plane
> datum: nad83
> vdatum: navd88
> ....

First of all I would add that I think this could be awkward as there is
no standard way for GRASS to know that a particular raster or sites
layer in the database actually contains height information, or what the
units would be. As far as I understand it each location could have any
number of raster layers representing a digital elevation model, but to
GRASS each would be just another floating point raster layer with no
information about what the numbers in it represent (that they are
elevation data for the location, or which units they are in). If
elevation data are coming from different sources (GPS, contours, raster
DEMs etc.) there may be raster layers representing lots of different
vertical datums contained in the same location. And there is no way of
marking a particular raster or sites layer to say that this is the
height layer for that location. I know I repeated what I said a bit
there but I hope it makes sense.

> 
> It would be great if this could go into 5.7 before we have a stable
> release with the new vector format.
> I noticed that PROJ supports only horizontal datum too,
> or am I missing something? Are there any plans to add it to PROJ?
> It is really important for working with elevation data -
> when the vertical datums are mixed up, place that is sinking may appear growing
> and the difference can be from few cm to several meters.

I don't think supporting vertical datums involves adding any extra
functionality to PROJ---really it only involves adding or substracting
data values and is independent of the 2-D location/projection of those
data values?

> 
> I looked for some public domain software - for USA, NOAA/USGS has some
> source code and grids available but the licence has some restrictions,
> I am not sure how to interpret it. Also, the software is FORTRAN.
> The conversion is relatively simple as it involves interpolation on a grid,
> but the grid files are rather large.
> 
> Below is a link and info about the NOAA programs, in case that somebody
> can look at it. I am not sure what would be available for Europe and other parts
> of the world,
>
> http://chartmaker.ncd.noaa.gov/bathytopo/vdatum.htm

I had a look at the link and as far as I can see, the software consists
of a selection of grid files (i.e. raster layers) and all it does is
interpolate these grids to find the height offset for a particular 2-D
position and add or subtract this. This is quite simple and the
functionality is in GRASS already (r.mapcalc).

There are lots of localised grids even to cover just a few parts of USA
as the NOAA software does---it uses an ASCII format which is quite large
and would be inefficient to re-distribute. I think any raster format
e.g. GeoTIFF would be appropriate. However there would be too much data
to include with GRASS---it is not something 'compact' that can be stored
in a short text file, like a list of 7 numbers associated with each
horizontal datum.

Something else similar is the OSGM02 Geoid model of the British
Isles---if you register on the Ordnance Survey of Great Britain website
you can download the data for free (see http://www.gps.gov.uk/ )---as I
remember it came in comma-separated variable ASCII text format.

I have used the OSGM02 model in the way I described (creating a GRASS
raster by interpolating the grid data using s.surf.rst, and then
subtracting this from GPS heights using r.mapcalc) with success to
create an orthometric height layer for parts of Northern Ireland.

So to summarise as far as I can see it: the required functionality is
already in GRASS---it is just a data processing/conversion job to import
the ASCII grids (.GTX files in the case of the NOAA software) as a GRASS
raster---or as sites and then interpolate with s.surf.rst.

In the long run perhaps the GRASS database could be extended to have a
facility to mark a specific raster layer (e.g. something with a special
name like is currently done for MASK) as representing a digital
elevation model for that location. Modules that currently have a
command-line parameter for the elevation could then be changed to use
that layer automatically. And the units of the elevation data and name
of the vertical datum could be stored somewhere else in the database.
I'm not sure if this is a good idea though. Has anybody experience of
how other GIS software handles this?

I hope my ideas are of some help and provoke further discussion.

Paul