[Liblas-devel] Vertical Datum Transformation

[Frank Warmerdam]

David C. Finnegan wrote:
> Frank,
> 
> The work you have done to incorporate vertical datum support is really 
> great!
> 
> Is it possible for users to incorporate their own vertical datum 
> descriptions beyond what is supported by default.

Dave,

Yes, there are some mechanisms to do that.

For EPSG based vertical coordinate systems, the definitions are
driven by the GDAL vertcs.csv and vertcs.override.csv files.  The
vertcs.csv file derived from the EPSG database directly but currently
hasn't got any information on how to actually transform things.

The vertcs.override.csv file provides for giving a list of .gtx files
that can be used to get to/from the datum in question from WGS84
ellipsoidal.

The override file looks like this currently, showing that only three
vertical datum have transformation info available.

"COORD_REF_SYS_CODE","COORD_REF_SYS_NAME","DATUM_CODE","DATUM_NAME","UOM_CODE","SHOW_CRS","DEPRECATED","COORD_SYS_CODE","COORD_OP_METHOD_CODE_1","PARM_1_1"
#
# NOTICE: The master version of this file is in the libgeotiff subversion at:
#
# https://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/vertcs.override.csv
#
# Do *not* change other copies without upstreaming the results to libgeotiff.
#
# Use the Geoid 2003 files to translated from NAVD88 to WGS84 (approx. NAD83)
#
5703,NAVD88 height,5103,North American Vertical Datum 
1988,9001,1,0,6499,9665,"g2003conus.gtx,g2003alaska.gtx,g2003h01.gtx,g2003p01.gtx"
#
# Use the EGM 96 geoid grid for translation from EGM96 to WGS84.
#
5773,EGM96 geoid height,5171,EGM96 geoid,9001,1,0,6499,9665,egm96_15.gtx
#
# Use the EGM 2008 geoid grid for translation from EGM08 to WGS84.
#
3855,EGM2008 geoid height,1027,EGM2008 geoid,9001,1,0,6499,9665,egm08_25.gtx


In the case of the proj-vdatum package on OSGeo4W we do not distribute
the egm08_25.gtx file since it is quite large.  So only the other two
work.   You can add additional entries in this file if you have gtx
files for the vertical datum shift.  There is also some support within
GDAL itself for producing .gtx files from some other vertical datum
grid shift file formats.  I thought I had some writeup on that, but I
can't find it at the moment.  Ask if you are interested.

The GeoTIFF tags represent vertical datums by EPSG code, so if possible
it is best to associate the transformation grids with an EPSG code.  If
that isn't practical it may also be possible apply vertical datum
conversions by providing the definition directly to las2las in
"PROJ.4 format".

This done by providing a PROJ.4 string for the coordinate system
including a +geoidgrids directive indicating the grid shift files
to use.  For instance something like:

+proj=utm +zone=11 +datum=NAD83 \
+geoidgrids=g2003conus.gtx,g2003alaska.gtx,g2003h01.gtx,g2003p01.gtx

would be UTM 11 NAD83 + NAVD88.

This can be passed in a quoted string to the --t_srs switch to
las2las.

Currently I suspect this will fail because I think that las2las
will use it to write the VLR on the target file, and then recreate
the spatialreference from that VLR - discarding the geoidgrids
portion - however, I haven't actually tested that.  But other
contexts this can work.  I'll actually set myself a TODO item to
investigate this issue, but if you want to try it poke me to get
details.

Does that help?  Are there parts you would like me to expand on?

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent