Send Liblas-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
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. Squeeze me (Howard Butler)
2. Re: libLAS SRS Reprojection Support and Compiling From Source
(Howard Butler)
3. Re: Squeeze me (Etienne Bellemare Racine)
4. Re: Squeeze me (Howard Butler)
5. Re: Squeeze me (Etienne Bellemare Racine)
6. Re: Full Wave Form LiDAR Samples (Jinha Jung)
7. Re: Squeeze me (Martin Isenburg)
----------------------------------------------------------------------
Message: 1
Date: Mon, 8 Mar 2010 12:29:03 -0600
From: Howard Butler <[email protected]>
Subject: [Liblas-devel] Squeeze me
To: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
All,
I would like to announce an upcoming development effort to bring
Martin Isenburg's laszip [1] [2] [3] to libLAS. I'll let Martin
explain laszip algorithms, benefits, and performance in more detail,
but this email is going to outline the development effort within
libLAS and describe how the pieces are going to hook together.
Over the past couple of months, I have been laying the groundwork for
this effort by internally refactoring a number of elements. The first
is the internal LAS reader and writers were reimplemented to behave as
a few independent units rather than a monolithic class for each format
file type (1.0 file, 1.1 file, etc). Instead of
liblas::detail::writer10, we now have something like
liblas::detail::writer::Header and liblas::detail::writer::Point.
This decoupling allows a developer to implement their own point writer
but still use our existing header writer.
The mechanism by which this will work in the upcoming release are the
new ReaderI and WriterI interfaces. We will implement ReaderI and
WriterI classes that will work with the laszip code to compress and
decompress LAS data through the regular libLAS interface. A few of
the details have yet to be worked out, and I would like to hear some
feedback on our proposal.
First, a LAS file that has been compressed with laszip is much like a
regular LAS file except the points have been compressed. The header
would be very much the same as a regular LAS file with a few
exceptions. Our current plan is to set the high bit on the point
format id of the header so that instead of format 0, 1, 2, 3, ... we'd
now have 128, 129, 130, ... as their compressed doppelg�nger. This
would hopefully prevent any unaware client from attempting to read
into the point data. Second, we would add a few liblas.org VLR
records that would describe some parameters of the compression (chunk
size, verification bits, algorithm version, and so on). The
combination of the VLR records plus the point format high bit would
trigger libLAS to use the laszip-enabled readers and writers.
The laszip code has been released as LGPL, and this prevents inclusion
of it directly in libLAS source tree unless we were to make that LGPL
as well (I'm not in favor of this at all). Our current thinking is to
initially allow a user to include support for it at compile time. We
hope to have the integration work done soon, but I would like to get
your feedback on the effort and hear if we're planning to do something
really silly before we do it.
Is seamless, lossless compression of LAS data through a libLAS
interface very appealing?
Howard
[1]
[2]
[3]
------------------------------
Message: 2
Date: Mon, 8 Mar 2010 12:35:48 -0600
From: Howard Butler <[email protected]>
Subject: Re: [Liblas-devel] libLAS SRS Reprojection Support and
Compiling From Source
To: Dan Bellinski <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Mar 8, 2010, at 10:23 AM, Dan Bellinski wrote:
Hey Howard,
I was unable to find any references to lasfile.obj in the current
makefile.vc (thus couldn't get past the build error).
most likely src/lasfile.obj I will try to clean up the windows
building stuff. Another alternative you might try is the cmake build.
I think Mateusz has it working on windows. This is where I would
ultimately plan to go with our windows build stuff.
I just
back-dated the source I was building from to the 1.2 release (1496)
and I was able to compile libLAS against GeoTiff 1.2.5 (from the
mapserver buildkit) and gdal 1.7.1 trunk.
I now have two questions:
1. Should the libLAS code version I used to compile be new enough to
be able to do the LAS re-projections? If not, do you have any other
hints as to fixing the lasfile.obj build error (how I can remove it
from trying to build)?
You need something relatively recent. I think I added support for it
around December and then made it actually work in the January timeframe.
2. Assuming everything is compiled right, I now have 2 ways to change
the projections on my LAS files. I am unsure how I will do this as I
couldn't find any documentation on it (other than the blip on the main
liblas page). Could you offer insight as to how I should go about
doing this with either method? It would be helpful to know what .exes
I will need to use and if you have accomplished this before maybe any
example notes you have?
With a recent checkout:
las2las -v in.las output.las -xyz_offset 0 0 0 -t_srs EPSG:4326
--xyz_scale 0.0000001 0.0000001 0.0000001 -s_srs EPSG:26915
This would override the existing SRS description of the file to
EPSG:26915 and transform it to EPSG:4326. As part of the process it
will also set the scale to seven decimals. Perhaps this file had only
two decimals of scale, which would clearly not be enough to store
meaningful decimal degree data.
I would note that this operation currently does not take into account
vertical datum transformation operations. That's in the works though,
and will hopefully be enabled in a future version of GDAL/proj.4/libLAS/etc
Howard
------------------------------
Message: 3
Date: Mon, 08 Mar 2010 13:52:41 -0500
From: Etienne Bellemare Racine <[email protected]>
Subject: Re: [Liblas-devel] Squeeze me
To: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
That seems like a good idea. I was wondering if it would be possible,
to
add an option to also order the points coordinates in a spatial order
instead of (I think) a temporal one, it would be much faster to scan
the
file that way to extract any point. within a given coordinate. Would
it
enter in the laszip specifications ? Of course, it would be much
slower
to write, I know, but it would be for a longtime gain in speed of
reading. What do you think ?
Etienne
Howard Butler wrote :
All,
I would like to announce an upcoming development effort to bring
Martin Isenburg's laszip [1] [2] [3] to libLAS. I'll let Martin
explain laszip algorithms, benefits, and performance in more detail,
but this email is going to outline the development effort within
libLAS and describe how the pieces are going to hook together.
Over the past couple of months, I have been laying the groundwork
for this effort by internally refactoring a number of elements. The
first is the internal LAS reader and writers were reimplemented to
behave as a few independent units rather than a monolithic class for
each format file type (1.0 file, 1.1 file, etc). Instead of
liblas::detail::writer10, we now have something like
liblas::detail::writer::Header and liblas::detail::writer::Point.
This decoupling allows a developer to implement their own point writer
but still use our existing header writer.
The mechanism by which this will work in the upcoming release are
the new ReaderI and WriterI interfaces. We will implement ReaderI and
WriterI classes that will work with the laszip code to compress and
decompress LAS data through the regular libLAS interface. A few of
the details have yet to be worked out, and I would like to hear some
feedback on our proposal.
First, a LAS file that has been compressed with laszip is much like
a regular LAS file except the points have been compressed. The header
would be very much the same as a regular LAS file with a few
exceptions. Our current plan is to set the high bit on the point
format id of the header so that instead of format 0, 1, 2, 3, ... we'd
now have 128, 129, 130, ... as their compressed doppelg�nger. This
would hopefully prevent any unaware client from attempting to read
into the point data. Second, we would add a few liblas.org VLR
records that would describe some parameters of the compression (chunk
size, verification bits, algorithm version, and so on). The
combination of the VLR records plus the point format high bit would
trigger libLAS to use the laszip-enabled readers and writers.
The laszip code has been released as LGPL, and this prevents
inclusion of it directly in libLAS source tree unless we were to make
that LGPL as well (I'm not in favor of this at all). Our current
thinking is to initially allow a user to include support for it at
compile time. We hope to have the integration work done soon, but I
would like to get your feedback on the effort and hear if we're
planning to do something really silly before we do it.
Is seamless, lossless compression of LAS data through a libLAS
interface very appealing?
Howard
[1]
[2]
[3]
Liblas-devel mailing list
[email protected]
------------------------------
Message: 4
Date: Mon, 8 Mar 2010 12:52:20 -0600
From: Howard Butler <[email protected]>
Subject: Re: [Liblas-devel] Squeeze me
To: Etienne Bellemare Racine <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Mar 8, 2010, at 12:52 PM, Etienne Bellemare Racine wrote:
That seems like a good idea. I was wondering if it would be
possible, to add an option to also order the points coordinates in a
spatial order instead of (I think) a temporal one, it would be much
faster to scan the file that way to extract any point. within a given
coordinate. Would it enter in the laszip specifications ? Of course,
it would be much slower to write, I know, but it would be for a
longtime gain in speed of reading. What do you think ?
You really mean you wish that fast spatial indexing and retrieval were
available for LAS files :) The next version of libLAS will have that
too, actually. I have already coded up some special cased examples of
it (using parallel file storage of libspatialindex indexes), but I am
hoping to implement something more generic. This also might fall
across the liblidar/lidarformat line as well, I don't know.
Howard
------------------------------
Message: 5
Date: Mon, 08 Mar 2010 14:34:06 -0500
From: Etienne Bellemare Racine <[email protected]>
Subject: Re: [Liblas-devel] Squeeze me
To: Howard Butler <[email protected]>,
"[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Howard Butler wrote :
On Mar 8, 2010, at 1:09 PM, Etienne Bellemare Racine wrote:
On Mar 8, 2010, at 12:52 PM, Etienne Bellemare Racine wrote:
That seems like a good idea. I was wondering if it would be
possible, to add an option to also order the points coordinates in a
spatial order instead of (I think) a temporal one, it would be much
faster to scan the file that way to extract any point. within a given
coordinate. Would it enter in the laszip specifications ? Of course,
it would be much slower to write, I know, but it would be for a
longtime gain in speed of reading. What do you think ?
Howard Butler wrote :
You really mean you wish that fast spatial indexing and retrieval
were available for LAS files :) The next version of libLAS will have
that too, actually. I have already coded up some special cased
examples of it (using parallel file storage of libspatialindex
indexes), but I am hoping to implement something more generic. This
also might fall across the liblidar/lidarformat line as well, I don't
know.
Howard
Yey ! So it's going to be in the code, not in the file... If I get
it right.
yes. you'd run 'lasindex myfile.las' and that would provide an
index file alongside the las file that would support fast window searching
Could it be squeezed inside the laszip so you could carry only one
file ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 6
Date: Mon, 08 Mar 2010 15:25:07 -0500
From: Jinha Jung <[email protected]>
Subject: Re: [Liblas-devel] Full Wave Form LiDAR Samples
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I wonder if you have heard about LVIS. LVIS waveform data are open to
public.
You can visit below for more information.
Jinha
On 03/08/2010 12:00 PM, [email protected] wrote:
[Liblas-devel] Full Wave Form LiDAR Samples
------------------------------
Message: 7
Date: Mon, 8 Mar 2010 14:59:07 -0500 (EST)
From: Martin Isenburg <[email protected]>
Subject: Re: [Liblas-devel] Squeeze me
To: Etienne Bellemare Racine <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
hi,
i would like to follow up in detail ... i just need a few days of
breezing
room to check things with the lab. my idea to combine laser research
with
goat hugging kids seems to have hit the nerve of the current zeitgeist.
i will focus on developping laszip & lastools in the future ... i just
need to see how the lab wants to be involved. i just want to make
everyone
happy and not step on anyone's toes.
want to see the future place of las development ... check the link below.
(-:
martin
--
scientist in data visualization - facilitator for sustainable community
------------------------------
_______________________________________________
Liblas-devel mailing list
[email protected]
End of Liblas-devel Digest, Vol 27, Issue 4
*******************************************
