[Liblas-devel] Improved SRS support in liblas

[Howard Butler]

On Feb 10, 2009, at 6:51 PM, Michael Rosen wrote:

>> 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.

We should provide direct access to the GTIF* then.  I think any other  
translation operation is likely to mangle the tags in some way,  
although it may not be important for most of the cases.  I suspect  
GDAL's WKT with GTIF[S|G]etFromOGISDefn is going to get us most of the  
way.

I don't know what your usage scenario is, but if it is simply copying  
data from one file to another, raw VLR access and copying is going to  
be transitive and no worries for that scenario.  Avoiding any  
translation in that case is going to be the best way to go.

> 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?

GTIF[S|G]etFromOGISDefn will not be available, even if we provide our  
own copies in libLAS, unless GDAL is available.  This is because  
GTIF[S|G]etFromOGISDefn requires a significant portion of CPL and OSR,  
which we are not going to also embed into libLAS.

I think our strategy is four-fold:

1) Do not mangle existing VLR records describing the coordinate system  
until we actually write the header.  This will prevent unnecessary  
loss of descriptive power that might be in the GTIF* description  
already.  For the copying scenario I described above, this is the best  
way to go.

2) Use libLAS' internal copies of GTIF[S|G]etFromOGISDefn to go/from  
WKT if GDAL is available and the user has issued any [S|G]etWKT methods

3) Use libgeotiff if available to allow naked access to the GTIF*  Use  
libgeotiff for any [S|G]etProj4 method calls if GDAL is not around,  
otherwise slide the proj4 through GDAL's OSR.  GTIF* access and usage  
would be up to the client code to figure out.

4) Encapsulate all of this misery in a LASSRS class that can be get/ 
set on the LASHeader so users don't have to worry about the details of  
all of this.

>
>
>> 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?
>

cs-map is not quite open development friendly yet.   There's  
practically no docs and it only purports to work on linux and windows  
(Solaris SPARC usage was a driver of libLAS, so this would be a  
regression, and I develop on a Mac ;).  cs-map also only supports a  
few vertical datums for transformation, and only a few descriptive  
vertical datums for translation.  From what I understand, it is  
practically in the same boat as GDAL in that regard.  Quite  
disruptive, given our current trajectory.

> - should we look to GDAL to provide vertical datum support?

Not in the near (1-4 years) future.  It depends also what you mean by  
"support."  Describing the datums or supporting transforming points  
are two very different levels of support.  GDAL does handle GTIF* with  
GTIF[S|G]etFromOGISDefn, while cs-map does not.
>
> - 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.

hehe.  I think libLAS will be the driver of doing SRS support in LAS.   
GeoTIFF is hard and painful, and Frank helped us out significantly to  
make libLAS easy to use with libgeotiff.  I suspect your sample data  
is descriptive of the current situation with regard to LAS SRS  
descriptions.  The files we use for testing in svn are files that I  
wrote myself.

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

Excellent.  I look forward to seeing you there. LAS 1.2 read support  
is mostly done in trunk right now, and I am finishing up write  
support.  I am refactoring the internals a bit now that we have yet  
another implementation to inform us of how things should look.  I plan  
to start in on refactoring the SRS description stuff soon.

Howard