[Liblas-devel] RFC 2 - Overhaul to SpatialReference

[Howard Butler]

On Nov 26, 2010, at 1:19 PM, Frank Warmerdam wrote:

> Folks,
> 
> At Howards request I have been looking at ways to extend the SpatialReference
> class in liblas, and the way of representing coordinate systems in liblas.
> I have written up a rather haphazard RFC on the topic, and I have a local
> implementation of the discussed changes.  I'd like a bit of feedback before
> I push this up and I understand that future changes are likely still to be
> needed as we go through teething pains.
> 


> 
> 
> Justification for Minimized GeoTIFF / GDAL Include Flow Through
> ------------------------------------------------------------------------------
> 
> Currently the lasspatialreference.hpp and a few other include files
> pull in libgeotiff, and GDAL include files somewhat gratuitously if
> these sublibraries are enabled in the build.
> 
> This introduces a lot of cruft into the global namespace.  Also due to the
> "C" style includes of these sublibraries, it introduces a lot of junk that
> might interfere in suprising ways and in contrast to how the rest of
> liblas in very careful to put things into namespaces and otherwise be
> somewhat sparing of includes.

Unfortunate carelessness on my part. 

> 
> Currently the liblas::SpatialReference class converts passed in WKT
> coordinate system definitions into a GeoTIFF VLR and future requests for
> the WKT are created by converting the GeoTIFF VLR back into WKT.  This
> makes it essentially impossible currently for las2las to perform
> transformations between coordinate systems not representable in GeoTIFF
> terms even if the source and destination are provided on the commandline in
> WKT format.
> 

It is expected that future versions of the LAS format will have some form of OGC WKT in a VLR, but not set in stone.  To keep compatibility, we are likely to have to write both GeoTIFF keys and a WKT VLR for some time, with the expectation that the WKT is to be used if you can interpret it.  Other softwares will probably start copying what we're doing too.

> 
> Now, if you want *only* GeoTIFF VLRs you should normally generate the
> SpatialReference and then call "ClearVLRs(eOGRWKT);" before setting the
> SpatialReference on the header being written.  If you want *only* a WKT
> VLR then you should call "ClearVLRs(eGeotIFF);" at the same point.
> 

What is expected to happen in a typical file copy scenario?  We read a GeoTIFF definition from the file, transform it into WKT internally in liblas::SpatialReference, and then write out what by default?  Both the WKT and the GeoTIFF keys VLRs?  I would be completely ok with that scenario.


> WKT VLR
> ------------------------------------------------------------------------------
> 
> 
> Currently the OGR WKT VLR is currently being written with a UserId of
> "LASF_Projection" like the GeoTIFF VLRs, and with a RecordId of 2112 to
> distingish it from the GeoTIFF VLRs.

We can't use "LASF_Projection" for the UserId of any WKT VLRs we write.  At least not until LAS 1.4 decides what to do.  The spec reserves the "LASF_Projection" UserId for "official" coordinate system description VLRs.  Until that time, we must use "liblas" (which is registered) for the UserId.  2112 is an excellent RecordId, however :)

> 
> The data is the OGR WKT string with a terminating zero byte.
> 

A small concern, but can the WKT get larger than 64k?  We'll need to throw an exception in that case.  VLRs have a 64k size limitation.  The VLR class does not throw right now when you try to put more than 64k in it.  Maybe it should...

> Is there any scheme to assign RecordIds?  

Nope.  We pick them within our UserId domain however we wish.

As of right now, the 'liblas' UserId domain has the following RecordId's assigned:

7 -- liblas schema record
42 - liblas index header
43 - liblas index entry
2112 - liblas OGC WKT SRS

> Perhaps we should pick a value
> outside the normal legal range for TIFF tags?  

This may be prudent, but 2112 seems fine to me.  Only code looking to identify VLRs to process is going to worry about the UserId/RecordId combo, however.