>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?
msr
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, February 18, 2009 9:00 AM
To: [email protected]
Subject: Liblas-devel Digest, Vol 14, Issue 7
Send Liblas-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.osgeo.org/mailman/listinfo/liblas-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Liblas-devel digest..."
Today's Topics:
1. LAS 1.2 and SRS improvements (Howard Butler)
2. Re: LAS 1.2 and SRS improvements (Hamish)
3. Re: LAS 1.2 and SRS improvements (Howard Butler)
4. Re: LAS 1.2 and SRS improvements (Hamish)
----------------------------------------------------------------------
Message: 1
Date: Tue, 17 Feb 2009 14:19:15 -0600
From: Howard Butler <[email protected]>
Subject: [Liblas-devel] LAS 1.2 and SRS improvements
To: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
All,
I think the dust has finally settled on a number of improvements I've
made to the SRS handling. Right now, only the C++ code has been
changed, but I plan to implement C and Python API for it in the next
couple of days as well. Here's a summary of the changes:
- a new class, LASSRS has been created. It is instantiated with a
list of VLRs, and if any of those VLRs are GeoTIFF-key related, they
are copied into the LASSRS.
- if neither libgeotiff nor GDAL are compiled in, the LASSRS is
supposed to do nothing.
- if GDAL is compiled in, it is used for SRS translation from the
GeoTIFF keys
- otherwise, if libgeotiff is available, but not GDAL, it is used as
before
One problem I would like some ideas on is how to describe what is
available. Because the SRS handling can be so different depending on
what is available, I think it would be good for us to allow the user
to ask what was activated at compile time? Any thoughts on how to do
so? Other than static strings, which might cause cross-dll heap
troubles, the only other approach I could think of is something like
MapServer's:
http://trac.osgeo.org/mapserver/browser/trunk/mapserver/maperror.c#L490
but it seems like a crime against nature ;)
Please give trunk a test and let me know if you have any troubles with
it. LAS 1.2 read/write support should also be active now, and 1.2 is
now the default version when creating new files, etc.
Howard
------------------------------
Message: 2
Date: Tue, 17 Feb 2009 14:44:31 -0800 (PST)
From: Hamish <[email protected]>
Subject: Re: [Liblas-devel] LAS 1.2 and SRS improvements
To: "[email protected]" <[email protected]>,
Howard Butler <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Howard Butler wrote:
> One problem I would like some ideas on is how to describe
> what is available. Because the SRS handling can be so
> different depending on what is available, I think it would
> be good for us to allow the user to ask what was activated
> at compile time?
like some sort of gdal-config app or just a lib function that returns an
int "level" code? (or both?) Part of (eg) 'las2las --help' text?
I am just thinking about end-users who had nothing to do with the compile
and so are at the mercy of READMEs being accurate & aware. e.g. I hope
that the DebianGIS team (or anybody) can officially package liblas for
Debian & Ubuntu users who wouldn't know to check.
fwiw, IMO consistent methodology is the only path to software sanity.
but you can't make everyone happy that way :)
Hamish
------------------------------
Message: 3
Date: Tue, 17 Feb 2009 16:48:18 -0600
From: Howard Butler <[email protected]>
Subject: Re: [Liblas-devel] LAS 1.2 and SRS improvements
To: [email protected]
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On Feb 17, 2009, at 4:44 PM, Hamish wrote:
>
> Howard Butler wrote:
>> One problem I would like some ideas on is how to describe
>> what is available. Because the SRS handling can be so
>> different depending on what is available, I think it would
>> be good for us to allow the user to ask what was activated
>> at compile time?
>
> like some sort of gdal-config app or just a lib function that
> returns an
> int "level" code? (or both?) Part of (eg) 'las2las --help' text?
>
> I am just thinking about end-users who had nothing to do with the
> compile
> and so are at the mercy of READMEs being accurate & aware. e.g. I hope
> that the DebianGIS team (or anybody) can officially package liblas for
> Debian & Ubuntu users who wouldn't know to check.
>
>
> fwiw, IMO consistent methodology is the only path to software sanity.
> but you can't make everyone happy that way :)
Yes I agree. Debian has the luxury of using GDAL by default, which is
the only sane way this should go. But I can't make GDAL a hard
requirement for libLAS. Another complication is likely to arise when
GDAL in turn starts linking against libLAS, but we'll burn that bridge
when we need to :)
liblas-config is one place you can get this information, but it
doesn't help the person who's coding to decide how to treat the srs.
Thanks for your input.... still chewing on this chewy one.
Howard
------------------------------
Message: 4
Date: Tue, 17 Feb 2009 15:35:00 -0800 (PST)
From: Hamish <[email protected]>
Subject: Re: [Liblas-devel] LAS 1.2 and SRS improvements
To: Howard Butler <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Howard Butler wrote:
> Debian has the luxury of using GDAL by default, which is the only sane
> way this should go. But I can't make GDAL a hard requirement for libLAS.
how about some sort of "SRS crippled" warning to the user if libgeotiff-
only or without either of gdal/libgeotiff. (I expect the low-cal users
don't want to see that over and over though :)
> Another complication is likely to arise when GDAL in turn starts
> linking against libLAS, but we'll burn that bridge when we need to :)
we solved that circular dependency in GRASS by way of the gdal-plugin*.
before that it was a complete nightmare for Debian to auto-build the
packages. Both due to the order of compiling things**, and e.g. if a new
grass package came out, GDAL had to be rebuilt, and so the many packages
depending on GDAL had to be rebuilt, and so on, and so on.
[*] http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz
see also http://packages.debian.org/lenny/libgdal1-1.5.0-grass
and the qgis-plugin-grass package (similar problem for QGIS<->GRASS)
[**] the old method IIRC was to 1) build gdal without grass support, 2)
build grass with gdal support, 3) remove & rebuild gdal with grass support.
on 11+ hardware platforms.
Hamish
------------------------------
_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
End of Liblas-devel Digest, Vol 14, Issue 7
*******************************************
_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
