[Liblas-devel] Full waveform lidar data
Jason.Woolard at noaa.gov
Jason.Woolard at noaa.gov
Tue Mar 9 09:23:00 EST 2010
Hi all -
Just wanted to mention that I have access to a full waveform lidar dataset that I can share. The data are not in LAS format and looking at the 1.3 spec I don't see a compelling reason to go in that direction for the waveforms. What I have is from Optech's digitizer in DDF (old digitizer format) or NDF (new digitizer format). Their format is published but it has changed twice since they introduced the waveform system. My colleague has matlab code to read an NDF or DDF and write the waveforms out as cell arrays stored in matlab's .mat format, but it could easily be modified to output ascii or any other format. Not sure if this is what you are looking for or if it would be useful but I can make the data are available with no restrictions.
Just thought I'd throw that out there.
Cheers,
Jason
----- Original Message -----
From: liblas-devel-request at lists.osgeo.org
Date: Monday, March 8, 2010 3:44 pm
Subject: Liblas-devel Digest, Vol 27, Issue 4
To: liblas-devel at lists.osgeo.org
> Send Liblas-devel mailing list submissions to
> liblas-devel at lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> 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. 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 <hobu.inc at gmail.com>
> Subject: [Liblas-devel] Squeeze me
> To: "Liblas-devel at lists.osgeo.org" <liblas-devel at lists.osgeo.org>
> Message-ID: <6F095280-142D-4361-8169-B2116582643E at gmail.com>
> 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 <hobu.inc at gmail.com>
> Subject: Re: [Liblas-devel] libLAS SRS Reprojection Support and
> Compiling From Source
> To: Dan Bellinski <bellindj at gmail.com>
> Cc: liblas-devel at lists.osgeo.org
> Message-ID: <110FC3EF-060B-49F8-B0D3-89200A53C168 at gmail.com>
> 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 <etiennebr at gmail.com>
> Subject: Re: [Liblas-devel] Squeeze me
> To: "Liblas-devel at lists.osgeo.org" <liblas-devel at lists.osgeo.org>
> Message-ID: <4B954779.3050107 at gmail.com>
> 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
> > Liblas-devel at lists.osgeo.org
> >
> >
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 8 Mar 2010 12:52:20 -0600
> From: Howard Butler <hobu.inc at gmail.com>
> Subject: Re: [Liblas-devel] Squeeze me
> To: Etienne Bellemare Racine <etiennebr at gmail.com>
> Cc: "Liblas-devel at lists.osgeo.org" <liblas-devel at lists.osgeo.org>
> Message-ID: <09884E9D-B830-4BAB-805D-ED80DEE5F40C at gmail.com>
> 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 <etiennebr at gmail.com>
> Subject: Re: [Liblas-devel] Squeeze me
> To: Howard Butler <hobu.inc at gmail.com>,
> "Liblas-devel at lists.osgeo.org" <liblas-devel at lists.osgeo.org>
> Message-ID: <4B95512E.2060005 at gmail.com>
> 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 <hamdori at gmail.com>
> Subject: Re: [Liblas-devel] Full Wave Form LiDAR Samples
> To: liblas-devel at lists.osgeo.org
> Message-ID: <4B955D23.70007 at gmail.com>
> 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, liblas-devel-request at lists.osgeo.org wrote:
> > [Liblas-devel] Full Wave Form LiDAR Samples
> >
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 8 Mar 2010 14:59:07 -0500 (EST)
> From: Martin Isenburg <isenburg at cs.unc.edu>
> Subject: Re: [Liblas-devel] Squeeze me
> To: Etienne Bellemare Racine <etiennebr at gmail.com>
> Cc: "Liblas-devel at lists.osgeo.org" <liblas-devel at lists.osgeo.org>
> Message-ID: <Pine.LNX.4.64.1003081456190.8403 at swan5.cs.unc.edu>
> 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
> Liblas-devel at lists.osgeo.org
>
>
>
> End of Liblas-devel Digest, Vol 27, Issue 4
> *******************************************
More information about the Liblas-devel
mailing list