[Liblas-devel] Improved SRS support in liblas

[Michael Rosen]

> If GDAL is linked in, we embed/compile our own copies of  GTIFGetOGISDefn and GTIFSetFromOGISDefn and use GDAL's wkt as the  primary storage mechanism (new functionality).

My highest priority is the ability to preserve the SRS data in the TIFF tags.  So while using GDAL's wkt as the primary storage mechanism is good, can we expect GTIF[S|G]etFromOGISDefn to work for Vertical Datum?  Do we need to use cs-map? For this?

> If no GDAL is not linked, but libgeotiff is, revert to using proj4 libgeotiff (current behavior) and provide naked access to the interpreted/converted GTIF* (new functionality).

If we've got our own copy of GTIF[S|G]etFromOGISDefn, perhaps we can migrate from storing the proj4 string to the wkt entirely.  Are others concerned about having two different ways of storing the SRS, depending on whether or not GDAL is available?

> Provide a flag on the LASReader/LASWriter that skips the interpretation of the SRS VLR records entirely (new functionality) so  
people who just want/need to blindly copy data can do so without penalty

Yes.  I think this makes a lot of sense.

> If GDAL is linked in, provide the ability to set coordinate system  definitions on a LASReader or LASWriter to define the output  
coordinate system

For me, this is secondary priority.  But I would definitely like to know more.  Does anyone have any insight into any of 
 - how disruptive it would be to use cs-map for this?  
 - should we look to GDAL to provide vertical datum support?
 - how often are vertical datum used in practice?  Here's my one data point for this.  Of the 642 samples I have ready access to, 3 of them have SRSs defined.  All three are Horizontal only.

Finally, I'll be at the Code Sprint in Torronto next month.  I'd love to help with any of this or related items.

msr

-----Original Message-----
From: Howard Butler [mailto:hobu.inc at gmail.com] 
Sent: Friday, February 06, 2009 2:03 PM
To: Michael Rosen
Cc: 'Liblas-devel at lists.osgeo.org'
Subject: Re: [Liblas-devel] Improved SRS support in liblas


On Feb 6, 2009, at 3:16 PM, Michael Rosen wrote:

>> Proj.4 can be more expressive than WKT in many instances, but the  
>> GeoTIFF keys are our limiting factor.
>
> If we store the SRS as a WKT can we, in principle, store all the  
> GeoRef info in the LAS file?

If GTIFSetFromOGISDefn and GTIFGetOGISDefn allow us to transitively  
preserve authority names going in and out of GTIF*, I think we're  
good.  I propose that we implement the following for the next libLAS  
release:

- If GDAL is linked in, we embed/compile our own copies of  
GTIFGetOGISDefn and GTIFSetFromOGISDefn and use GDAL's wkt as the  
primary storage mechanism (new functionality).
- If GDAL is linked in, provide the ability to set coordinate system  
definitions on a LASReader or LASWriter to define the output  
coordinate system.  If an output coordinate system is set, the points  
will be reprojected (from what is defined in the LASHeader to what is  
defined on the LASWriter/LASReader).  If nothing is set on either the  
LASReader or LASWriter, no projection happens.  (GDAL's lack of  
vertical datum translation support complicates this... maybe we should  
use cs-map, which provides VERTCON which should be what most people  
need)
- If no GDAL is not linked, but libgeotiff is, revert to using proj4/ 
libgeotiff (current behavior) and provide naked access to the  
interpreted/converted GTIF* (new functionality).
- Provide a flag on the LASReader/LASWriter that skips the  
interpretation of the SRS VLR records entirely (new functionality) so  
people who just want/need to blindly copy data can do so without penalty
- If no GDAL or libgeotiff is linked, ignore srs information in the  
header entirely (current behavior).

I'd be interested to hear if people think these ideas are a good  
approach.  They are mostly (better) extensions of what we're doing now.

>
>
>> I do know that GDAL doesn't support many of the vertical datums  
>> descriptions that GeoTIFF keys have.
>
> Are you sure?  Perhaps that was only true of older versions?
> Here's the list of VCRS that geotiff supports: http://www.remotesensing.org/geotiff/spec/geotiff6.html#6.3.4.1
> I think this is the VCRS that gdal 1.5.2 supports:  http://gdal.sourcearchive.com/documentation/1.5.2-2/epsg__vertcs_8inc-source.html

Both of these are links to GeoTIFF's epsg_vert file, not GDAL's.     
Geotiff supports the description of a few vertical datums, but GDAL/ 
OSR doesn't do anything with them.

>
>
> According to the Geotiff spec, there are no specific Vertical Datum  
> codes currently defined.
>


I think there's a few.  The URLs you linked have:

00041 ValuePair(VertCS_North_American_Vertical_Datum_1929,  5102)
00042 ValuePair(VertCS_North_American_Vertical_Datum_1988,  5103)