[Liblas-devel] LAS 1.2 and SRS improvements
Michael Rosen
mrosen at lizardtech.com
Wed Feb 18 17:48:21 EST 2009
>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: liblas-devel-bounces at lists.osgeo.org [mailto:liblas-devel-bounces at lists.osgeo.org] On Behalf Of liblas-devel-request at lists.osgeo.org
Sent: Wednesday, February 18, 2009 9:00 AM
To: liblas-devel at lists.osgeo.org
Subject: Liblas-devel Digest, Vol 14, Issue 7
Send Liblas-devel mailing list submissions to
liblas-devel at lists.osgeo.org
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
liblas-devel-request at lists.osgeo.org
You can reach the person managing the list at
liblas-devel-owner at lists.osgeo.org
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 <hobu.inc at gmail.com>
Subject: [Liblas-devel] LAS 1.2 and SRS improvements
To: "Liblas-devel at lists.osgeo.org" <liblas-devel at lists.osgeo.org>
Message-ID: <258933BC-27A5-44F6-B6CE-1DAA192BFB2D at gmail.com>
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 <hamish_b at yahoo.com>
Subject: Re: [Liblas-devel] LAS 1.2 and SRS improvements
To: "Liblas-devel at lists.osgeo.org" <liblas-devel at lists.osgeo.org>,
Howard Butler <hobu.inc at gmail.com>
Message-ID: <755492.67369.qm at web110003.mail.gq1.yahoo.com>
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 <hobu.inc at gmail.com>
Subject: Re: [Liblas-devel] LAS 1.2 and SRS improvements
To: hamish_b at yahoo.com
Cc: "Liblas-devel at lists.osgeo.org" <liblas-devel at lists.osgeo.org>
Message-ID: <A15DA51C-0076-4FD0-A62B-CA20FE5FA448 at gmail.com>
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 <hamish_b at yahoo.com>
Subject: Re: [Liblas-devel] LAS 1.2 and SRS improvements
To: Howard Butler <hobu.inc at gmail.com>
Cc: "Liblas-devel at lists.osgeo.org" <liblas-devel at lists.osgeo.org>
Message-ID: <271284.84890.qm at web110012.mail.gq1.yahoo.com>
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
Liblas-devel at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/liblas-devel
End of Liblas-devel Digest, Vol 14, Issue 7
*******************************************
More information about the Liblas-devel
mailing list