[Liblas-devel] LAS 1.2 and SRS improvements

[Howard Butler]

On Feb 18, 2009, at 5:29 PM, Howard Butler wrote:

>
> On Feb 18, 2009, at 4:48 PM, Michael Rosen wrote:
>
>>> I think it would be good for us to allow the user to ask what was  
>>> activated at compile time.
>>
>> I concur.  Perhaps a static method, "LASSRS::SupportLevel  
>> LasSRS::GetSRSSupportLevel();" ?
>>
>>> Please give trunk a test and let me know if you have any troubles  
>>> with  it.
>>
>> I'm running into compilation problems using GDAL 1.4.2.   
>> gt_citation.cpp, line 281 fails on win32:
>>       osCitation = szName;
>>       if(osCitation[n-1] != '|') //// ambiguous:
>>
>>
>> gt_citation.cpp(281) : error C2666:  
>> 'std::basic_string<_Elem,_Traits,_Ax>::operator []' : 3 overloads  
>> have similar conversions
>>       with
>>       [
>>           _Elem=char,
>>           _Traits=std::char_traits<char>,
>>           _Ax=std::allocator<char>
>>       ]
>>       E:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE 
>> \xstring(1576): could be 'const char &std::basic_string<_El
>> em,_Traits,_Ax>::operator [](unsigned int) const'
>>       with
>>       [
>>           _Elem=char,
>>           _Traits=std::char_traits<char>,
>>           _Ax=std::allocator<char>
>>       ]
>>       E:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE 
>> \xstring(1556): or       'char &std::basic_string<_Elem,_Tr
>> aits,_Ax>::operator [](unsigned int)'
>>       with
>>       [
>>           _Elem=char,
>>           _Traits=std::char_traits<char>,
>>           _Ax=std::allocator<char>
>>       ]
>>       or       'built-in C++ operator[(const char *, int)'
>>       while trying to match the argument list '(CPLString, int)'
>> gt_citation.cpp(518) : error C2370: 'cpl_cvsid' : redefinition;  
>> different storage class
>>       gt_citation.cpp(38) : see declaration of 'cpl_cvsid'
>> gt_citation.cpp(518) : error C2084: function 'char *cvsid_aw(void)'  
>> already has a body
>> ...
>>
>> Note that gt_citation.cpp is not in the 1.6 version of gdal (latest  
>> stable).  The only other non-1.4.2 issue I've had so far is the use  
>> of OGR::SetEquarectangular2.  What version of GDAL should we require?
>
> lassrs.cpp has a copy of the code from gt_wkt_srs.cpp as of about a  
> week ago. As a GDAL dev, I track trunk, so I obviously swiped the  
> latest and greatest.  If you copy/paste gt_wkt_srs.cpp from your  
> version of gdal in the appropriate place in lassrs.cpp, you should  
> be able to compile.  Please note that I didn't say it works quite  
> yet though ;)  I'm having trouble with libgeotiff's simple keys api  
> and ascii geotiff keys.  I think it's a bug in libgeotiff, but I  
> haven't quite nailed it down yet.

Indeed it was a bug in libgeotiff.  libgeotiff wasn't appropriately  
calculating a string size in ST_SetKey, which was causing things to  
blow up.  libgeotiff has been fixed upstream, but this means we now  
require a very recent, unreleased libgeotiff to do anything with SRSs  
for libLAS :(

>
>
> Ideally, I'd like to make whatever Debian would support (please let  
> me know Hamish) as the required version, but I'm flexible.  Maybe we  
> should just nab gt_wkt_srs.cpp entirely whole instead of embedding  
> it in lassrs.cpp so it is easy to swap out with whatever GDAL  
> version is desired (or using GDAL's versions directly could work,  
> but since the functions we're using aren't part of any sort of  
> public API, that proposition is not as desirable).	

r1053 pulls gt_wkt_srs.cpp into its own file so that it should be easy  
to swap out with a version that matches whatever GDAL version you are  
operating with.  You might need to remove the CVS_ID stuff at the top  
of the file to get it to compile, however.