[Liblas-devel] Improved SRS support in liblas

[Howard Butler]

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

>
> After discuss this offline with Howard, I'm posting this here for  
> further discussion.
>
> A design limitation of liblas 1.0.0 is that we store the SRS  
> information as a PROJ4 string.  This precludes the ability to  
> reference non-proj4 data like the SRSName or the EPSG code.  An  
> alternative might be to store this as a WKT string and use GDAL's  
> global-but-not-exposed function "GTIFGetOGISDefn" to convert from  
> the (libgeotiff) GTIFDefn structure to a WKT.  Similarly, I think  
> GTIFSetFromOGISDefn (in libgeotiff) could reverse the operation.
>

...

>
> There appears to be no way to recover the EPSG code or "NAD83 /  
> Washington North."  As it stands now, I think (but don't have a test  
> case) that if we use liblas to read a file with this SRS and then  
> write it out again, we can't keep the original SRS intact.


Michael,

This is a bug and a feature of libLAS :)  The original client needed  
UTM Zone 15 support and the proj4 definition was expressive enough and  
also kept us from having a GDAL dependency for libLAS.  On the windows  
side this was important because of the hassle of setting GDAL_DATA,  
etc, and because their most common use case was to be  
manipulating .las files through ArcGIS Python GeoProcessing.  Putting  
GDAL into that mix can cause a lot of trouble, especially because a  
version of GDAL is already there, but we've no way to link against it  
to use it.  Using proj4 strings made things simple, but as you clearly  
describe, limited.

I would be more apt to pull the GTIFGetOGISDefn and GTIFGetOGISDefn  
code from GDAL (renamed, obviously) and put it into libLAS.  It would  
not eliminate the dependency on GDAL, but it would protect us from  
GDAL changing anything and us depending on any non-standard linkage.

On Feb 4, 2009, at 12:33 AM, Hamish wrote:

> Hi,
>
> FWIW, WKT is no panacea. BUT you can embed the +proj string as a WKT
> extension, which may suit as a compromise.
>
> see
>  http://trac.osgeo.org/gdal/changeset/15681
>
> pages down? maybe Frank knows where they got to...
>  http://gdal.velocet.ca/~warmerda/wktproblems.html
>  http://home.gdal.org/warmerda/wktproblems.html
>
>  http://article.gmane.org/gmane.comp.gis.grass.devel/2971/
>  http://thread.gmane.org/gmane.comp.gis.grass.devel/30047
>  http://thread.gmane.org/gmane.comp.gis.grass.user/26612/focus=26615
>
> (these may be more OGR parser centric than GDAL/raster or PROJ.4)
>

And this is the other side of the problem, but I don't know that this  
is libLAS' problem.  Proj.4 can be more expressive than WKT in many  
instances, but the GeoTIFF keys are our limiting factor.   
Additionally, I do know that GDAL doesn't support many of the vertical  
datums descriptions that GeoTIFF keys have.  Maybe we should be  
looking at something else entirely like CS-Map.  I'll go ask on their  
list and see if it would be a fit for us.

Howard