interesting comments in ancient "lasformat" yahoo group
83 views
Skip to first unread message
Martin Isenburg
Aug 2, 2011, 2:08:02 PM8/2/11
to The LAS room - a friendly place to discuss specifications of the LAS format
hello,
i recently came across an older yahoo group the LAS format between
2004 and 2006. you can read up on all 77 comments here [1]. that forum
was then closed and discussions moved over to a bulletin board hosted
by the USGS [2]. below are some interesting ones. raised as early as
2004 some of the issues are still relevant. sorry for length &
formatting but i'm sure some of you will re-appreciate these - by LAS
time - "ancient" comments ... (-:
regards,
martin @lastools
[1] http://tech.groups.yahoo.com/group/lasformat/
[2] https://lidarbb.cr.usgs.gov/index.php?showforum=29
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/9
Wed May 5, 2004 8:30 am
FW: ASPRS Lidar Committee - Lack Of A Published, ASPRS-Accepted, In
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'm posting this so others can join the discussion. I've trimmed off
all
email addresses.
Doug
-----Original Message-----
From: Karl Heidemann
Sent: Friday, April 23, 2004 12:26 PM
To: Taylor, Doug; Karen Schuckman; Brad Herman; Martin Flood; Rob
Burrell;
Ty Naus; Jason Mann
Cc: Mike Renslow; Galla, Paul; Jeff Walker
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
Add to that the TerraScan default:
1 = Default (unclassified)
2 = Ground
4 = Medium Vegetation
5 = High Vegetation
6 = Building
7 = Low Point (noise)
8 = Model keypoint
And the EarthData standard:
0 = Unclassified
1 = Noise
2 = Water
3 = Top of Canopy (high vegetation)
4 = Intermediate Vegetation
5 = Buildings
6 = Misc Structures
7 = BareEarth
Except for issues dealing with legacy files (which every vendor will
have
and each vendor will have to work out for themselves anyway), I don't
think
we really care what internal codes are used for any given
classification. It
just has to be documented, consistent, and stable.
I see two solutions off-hand:
1) Develop a comprehensive lookup table that includes all the various
classifications being used by all the major users, reduced to
eliminate
duplications, but retaining each unique class. "User-defined" classes
should
not be included in this - any codes beyond those specified in the
standard
table are by definition "User-defined". This table must be widely
published
- in fact should be included in the standard itself. Each
Classification
should include some brief description of what is intended to be
included and
what is not.
2) Revise the standard so that the header includes a mandatory lookup
table
to translate the internal codes of that file into "plain English".
I favor Option 1. It should not take too much to gather this
information
from the various vendors and users and compile this table. Publication
is
simple. Option 2 would be complex, confusing, and unreliable. It would
be
difficult to enact, impossible to enforce, and does not ensure any
uniformity. One person's "plain English" class descriptions might be
meaningless to someone else. Everything would in fact become "user-
defined".
-----Original Message-----
From: Taylor, Doug
Sent: Friday, April 23, 2004 12:48 PM
To: Karen Schuckman; Brad Herman; Martin Flood
Cc: Mike Renslow; Galla, Paul; Karl Heidemann; Jeff Walker
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
It's a definite problem. I've seen one vendor using the following
classifications:
0 = Normalized Surface - gridded data (added after processing)
5 = Canopy - all LiDAR data above the ground
6 = Building
8 = Keypoints - the filtered, bald earth surface
10 = Powerline
11 = Bridge
12 = Breakpoints - breakline vectors converted into points
13 = Superceded
While another vendor uses the following classificaions:
0 = Unknown
1 = Surface
2 = Buildings
3 = Vegetation
4 = Roads
5 = Water
6 = Poles
7 = Highwire
8 = Otherstruct
9 = User1
10 = User2
11 = User3
12 = Noise
13 = Edgematch
14 = Duplicate
You'd think with 256 values, we could all agree on a scheme that would
work.
-----Original Message-----
From: Karen Schuckman
Sent: Friday, April 23, 2004 11:01 AM
To: Taylor, Doug; Brad Herman; Martin Flood
Cc: Mike Renslow; Galla, Paul; Karl Heidemann; Jeff Walker
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
The discussion group at Yahoo is fine. I just meant that anything like
a
draft set of classification codes or specs ought to be posted on the
ASPRS
site, so people can find out about that it exists and is being
discussed.
Don't rely on the discussion group alone as the only means for people
to
find out about it.
My suggestion is to post the current draft at ASPRS or LAS websites,
with a
notation it is a very preliminary draft, that the discussion group
exists,
and that people are invited to join in and comment. At the meeting in
Denver
we then can discuss how to move this effort from its current state to
something more official.
-----Original Message-----
From: Taylor, Doug
Sent: Friday, April 23, 2004 11:39 AM
To: Brad Herman; Martin Flood
Cc: Mike Renslow; Karen Schuckman; Galla, Paul
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
My goal in starting the Yahoo lasformat group was for the technical
issues
within the LAS spec that were not being discussed (such as those I've
already posted). Thus the group would be similar to other format
related
lists such as those for TIFF and JPEG2000. I would've preferred an
official
ASPRS Lidar Cmte LAS discussion group somewhere, but it just wasn't
happening quick enough (IMHO). Perhaps the Cmte can establish one or
more
official discussion groups to replace LidarTalk and my lasformat
group.
Until then, please encourage your technical LAS friends and neighbors
to
join the Yahoo group.
The LAS spec is still young and I fear that many compatibility issues
already exist among those vendors that claim to support LAS. If LAS is
to
succeed, we all need to work together to iron out the kinks.
Doug
-----Original Message-----
From: Brad Herman
Sent: Friday, April 23, 2004 9:01 AM
To: Martin Flood
Cc: Taylor, Doug; Mike Renslow; Karen Schuckman
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
Makes sense. As long as there is a central location that people can
find
easily, say from a link on the ASPRS site, that's fine. I was just
concerned about fragmenting things instead of centralizing.
-----Original Message-----
From: Martin Flood
Sent: Friday, April 23, 2004 7:57 AM
To: Brad Herman
Cc: Doug Taylor; Mike Renslow; Karen Schuckman
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
Sadly, I had to shut down the LidarTalk discussion board in February
since
it kept getting hacked by somebody. It is no longer set-up as a
discussion
group that people can post questions/comments to.
Martin
-----Original Message-----
From: Brad Herman
Sent: Friday, April 23, 2004 7:23 AM
To: Martin Flood; Mike Renslow
Cc: Karen Schuckman; Doug Taylor
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
How is this new discussion group different than the
http://www.lidarcentral.com/lidartalk/wwwboard.shtml group that is
linked to
directly from the ASPRS web site?
-----Original Message-----
From: Martin Flood
Sent: Thursday, April 22, 2004 5:05 PM
To: Mike Renslow
Cc: Karen Schuckman; Brad Herman; Doug Taylor
Subject: ASPRS Lidar Committee - Lack Of A Published, ASPRS-Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
Hi all;
I'll add this item to the agenda for the lidar committee meeting in
Denver.
Incidentally, Doug has started a .las format discussion group at
http://groups.yahoo.com/group/lasformat as an unofficial LAS format
discussion forum. This might be a good place to refer people for some
discussion or feedback on this topic.
Martin
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/10
Wed May 5, 2004 8:30 am
Code-To-Class Schemes in .LAS
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The following was sent out earlier today. I'm posting here for
anybody that might not be on the lidar committee e-mail list. --- mf
--------------------------------------------------------------------
FYI: To All ASPRS Lidar Committee Members
An issue has been raised about the lack of any standard code lookup
when writing .LAS format files. Currently, whatever codes are used
in the specific software package or set by the user (e.g.
TerraScan .ptc file) for the various classes of points is what is
written to the output .LAS file. While there are some default
schemes, for example the default TerraScan scheme is:
TerraScan Default:
1 = Default (unclassified)
2 = Ground
4 = Medium Vegetation
5 = High Vegetation
6 = Building
7 = Low Point (noise)
8 = Model keypoint
many organizations are implementing their own unique coding schemes
resulting in a lack of standardization across .LAS files from
different organizations. An obvious challenge for a "standard" data
exchange format. It has been noted this lack of an openly
published, ASPRS-accepted, industry-standard lookup table is going
to be a problem for industry-wide LAS implementation. As released,
the .LAS standard does not include any requirement for documenting
the code-to-class reference within the LAS file. Every vendor/user
is able to develop their own system based on their own logic and
needs. Without a standard table for a fairly comprehensive,
commonly agreed upon set of classes, nobody will easily know what
points have been classified as what. This could become a major
problem for large end user organizations, such as government
agencies, who deal with data files from numerous different vendors.
Even a simple difference such as what basic code is used
for "ground" will make for a lot of unnecessary inefficiency in
dealing with files from different vendors.
To address this issue it has been suggested that the Lidar Committee
develop a comprehensive lookup table that includes all the various
classifications being used by all the major users, reduced to
eliminate duplications, but retaining each unique class. "User-
defined" classes will not be included in these standard codes – any
codes beyond those specified in the standard table are by
definition "User-defined". This table will be published – and
included in the standard itself. To maintain the ability to
customize for a particular organizations needs, user defined codes
will still be included, but moved to the block above the
designated "ASPRS" codes. For example,
Codes 0-48: Each specifically assigned by ASPRS based on
current standard classifications.
Codes 49-127: Reserved for Future ASPRS Use.
Codes 128-255: User Defined
To assist in the compilation of the ASPRS basic code assignments,
the Lidar Committee is requesting that any organization or
stakeholder that has an interest in this issue please submit any
code scheme(s) they wish to be considered. You can submit via e-
mail to lidar_committee@... with "LAS Code Scheme" in the
subject line. This issue will be discussed at the upcoming
committee meeting in Denver.
Those interested in following informal discussion on the .LAS format
may want to check out the Yahoo discussion group at group at
http://groups.yahoo.com/group/lasformat.
Much of the above is based on discussions and communications with
Karl Heidemann (EarthData), Doug Taylor (Z/I), Brad Herman
(NIIRS10), Karen Schuckman (EarthData) and Mike Renslow (SBG).
Thanks to all for bringing this issue to the table and (more
importantly) suggesting a solution.
Martin Flood
Chair, ASPRS Lidar Committee
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/11
Wed May 5, 2004 2:58 pm
Start of discussion on storing waveform data in the LAS file.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
here has been lots of hype about waveform data with lidar. I
thought it made sense to start a discussion on what this data might
look like and how it might fit into the las file format.
For our system there is only one waveform per laser shot meaning one
waveform for each outbound laser pulse. In the las file, we have a
record for each return. Therefore, if you have a laser shot that
produces 3 returns, you will get one waveform and 3 returns (3 las
records).
The waveform data will be big and will be very system dependent. In
our system is will be user configurable. This means that the
resolution will be variable (8+ bits) and the length of the waveform
(the number of meters worth of time that the waveform is recorded)
may change depending on the terrain. So basically, there will be a
lot of data and you dont want to leave space in the point data of
return 2 and return 3 when the waveform data is attached to return
1. So, attaching the waveform data to the point data will give
something like this in a las point record.
RETURN1DATA TIME WAVEFORMDATA
RETURN2DATA TIME NULL
RETURN3DATA TIME NULL
RETURN1DATA TIME WAVEFORMDATA
RETURN2DATA TIME NULL
where you will end up with a lot of unused space.
What I am leaning towards is putting the waveform data in a VLR. We
would require some way to attach the waves to there corresponding
points (gps time or an index) and having a second VLR that describes
the data.
The following information would be a good start for the wave
description VLR. Keep in mind that the wave data is similar to
viewing a signal on an oscilloscope. Therefore, you will require
similar information to that of an oscilloscope.
Waveform Resolution (bits per record, most likely 8, 10 or 12)
Waveform resolution as stored in the file (most likely 8 or 16)
Min Y value (the minimum voltage...a value of zero may not
necessarily equal a return voltage of zero)
Y scale (Volts per bit)
Sample rate (probable between .5GHz and 2+ GHz from the marketing
information that I have seen)
# of samples per wave
NOTE: The combination of the sample rate and the # of samples would
be used to compute the length (in meters) of the waveform
To complicate things further, the wave for a return from a tree would
be much longer than the wave for a return from a flat surface.
Therefore, the flat surface would create a lot of useless data. It
may make sense to store the waveform data with a variable length to
eliminate this useless data. Many VLR's OR a VLR of VLR's could be
used.
As you can see, there are some things that need to be discussed.
This is based on how our system works with the assumption that others
are at least similar. This remains to be seen.
Your comments are welcome on this issue!!!
Paul
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/15
Fri Jun 25, 2004 1:23 pm
Re: Start of discussion on storing waveform data in the LAS file.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Interesting to think about adding waveforms to .LAS, but I don't
know how immediately that is needed. Has anybody in the commercial
topo world started delivering waveform data yet? And if so for what
applications? I think there's still a lot of work to be done before
waveforms reach the point where enough people are using them that
they need a common data format. Have you considered talking to the
bathymetry folks? They've been using them for years.
--- Martin
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/26
Wed Dec 15, 2004 2:52 pm
Reliable extraction of last returns
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'd like to be able to pull last returns from an LAS file. To
accomplish this I'd think I should pull point records with a return
number equal to the number of returns given for the pulse. But then I
see a LAS file with this return information:
----------------
header ->
Points by return:
[1]: 18913702
[2]: 0
[3]: 5167790
[4]: 0
[5]: 0
And point records with this with return info ->
Rtn Rtns
3 2
-----------------
Is this valid? To have a return number greater than the number of
returns? If this is valid, how does one quickly and reliably get at
the last return for a pulse?
Clayton Crawford
ESRI Software Products
Redlands, CA USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/41
Thu Apr 7, 2005 9:25 am
Trajectory information in the LAS header
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hello all,
Is anyone using the TRJ importer in TerraScan? If so, is seems like we
should open a discussion on a trajectory header in the las file. I was
thinking that including the trajectory at one seconds intervals might
do the job. We could use the TerraScan TRJ format as a starting point.
Any thoughts on this?
Pau;
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/46
Wed Jun 1, 2005 10:50 am
las format exporter
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hi All,
Just a quick check to see if anyone out there has any software or code
written that will allow me to import/export my exisiting lidar
datasets
to las format?
Thanks in advance for anything you might have to offer!
Dave
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/49
Fri Aug 26, 2005 5:16 pm
Enlarge LAS angle formatz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hi All,
I would like to suggest that the "Scan Angle Rank" in the 1.1 format
be changed to either a double (for the actual angle) or a long (for
encoder counts).
As a lidar provider having one byte for angle is pretty much useless
for us.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/54
Mon Jan 23, 2006 1:05 pm
LAS 1.1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'm having trouble finding data in 1.1 format despite the
specification
being published nearly a year ago. One major data provider told me
that
none of the software they use, including Terrascan, supports it.
Does anyone have a lead? Are LAS providers going to skip 1.1 and go
straight to 2.0?
Clayton Crawford
ESRI Software Products
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/64
Wed Mar 8, 2006 3:38 pm
LAS v2.0 Scan Angle Rank
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hi All,
I posted the following in regards to the v1.1 spec and my comments
still apply now that this issue has been ignored in the 2.0 draft:
"I would like to suggest that the "Scan Angle Rank" in the 1.1 format
be changed to either a double (for the actual angle) or a long (for
encoder counts).
As a lidar provider having one byte for angle is pretty much useless
for us."
I do realize that with the new point format I can create a user
defined field to hold the true angle but I think this should be built
in to the Airborne scanner packet as an officially recognized field.
Additionally the fields listed in the scanner spec look suspiciously
like they have been pulled from 1 particular scanner/software vendor
and I think we should concentrate on creating a more generic usage.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/73
Wed Apr 19, 2006 9:38 pm
LAS Import/Export Solution
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hello Everyone,
It is apparent from a few posts here, and others on the USGS LIDAR
board and elsewhere, that translation to and from LAS is a bit
problematic. We've decided to include our translator in the free
version of LASEdit. Look for the "Batch" menu when the program
starts, there you will find the "Export from LAS Format" and "Import
to LAS Format" menu items. We're currently supporting free-form ASCII
and ESRI Point and PointZ formats:
http://www.cloudpeaksoftware.com/download/LASEditSetupFree.exe
-Rob B.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/76
Mon May 1, 2006 10:56 am
Poll results for lasformat
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lasformat] Poll results for lasformat
With the poll now closed and the results so clear, I will be
closing the lasformat Yahoo group later this week.
Please direct your discussions to the USGS Center for
LIDAR Information Coordination and Knowledge at
http://lidar.cr.usgs.gov/. Once there, you will find a
Bulletin Board link near the top.
--
Doug Taylor
Creator of the lasformat Yahoo group
Love God.
Love others.
Any questions?
> The following lasformat poll is now closed. Here are the
> final results:
>
>
> POLL QUESTION: There is a new lidar forum and bulletin board being launched
> and hosted by the USGS called CLICK. You can find details at
> http://lidar.cr.usgs.gov/ . It has been suggested that this would be a
> better permanent home for this LAS discussion forum, allowing issues and
> discussions to take place in the context of a full lidar forum. As well as
> having USGS support for maintaining the board. If we move this forum to
> CLICK, we will close this Yahoo group. We would like to poll everybody to
> see if they feel this is a good idea.
>
> Are you in favor of moving the LAS discussion/support forum on Yahoo! to the
> USGS CLICK forum?
>
> Poll closes April 31st.
>
>
> CHOICES AND RESULTS
> - Yes, 19 votes, 100.00%
> - No, 0 votes, 0.00%
i recently came across an older yahoo group the LAS format between
2004 and 2006. you can read up on all 77 comments here [1]. that forum
was then closed and discussions moved over to a bulletin board hosted
by the USGS [2]. below are some interesting ones. raised as early as
2004 some of the issues are still relevant. sorry for length &
formatting but i'm sure some of you will re-appreciate these - by LAS
time - "ancient" comments ... (-:
regards,
martin @lastools
[1] http://tech.groups.yahoo.com/group/lasformat/
[2] https://lidarbb.cr.usgs.gov/index.php?showforum=29
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/9
Wed May 5, 2004 8:30 am
FW: ASPRS Lidar Committee - Lack Of A Published, ASPRS-Accepted, In
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'm posting this so others can join the discussion. I've trimmed off
all
email addresses.
Doug
-----Original Message-----
From: Karl Heidemann
Sent: Friday, April 23, 2004 12:26 PM
To: Taylor, Doug; Karen Schuckman; Brad Herman; Martin Flood; Rob
Burrell;
Ty Naus; Jason Mann
Cc: Mike Renslow; Galla, Paul; Jeff Walker
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
Add to that the TerraScan default:
1 = Default (unclassified)
2 = Ground
4 = Medium Vegetation
5 = High Vegetation
6 = Building
7 = Low Point (noise)
8 = Model keypoint
And the EarthData standard:
0 = Unclassified
1 = Noise
2 = Water
3 = Top of Canopy (high vegetation)
4 = Intermediate Vegetation
5 = Buildings
6 = Misc Structures
7 = BareEarth
Except for issues dealing with legacy files (which every vendor will
have
and each vendor will have to work out for themselves anyway), I don't
think
we really care what internal codes are used for any given
classification. It
just has to be documented, consistent, and stable.
I see two solutions off-hand:
1) Develop a comprehensive lookup table that includes all the various
classifications being used by all the major users, reduced to
eliminate
duplications, but retaining each unique class. "User-defined" classes
should
not be included in this - any codes beyond those specified in the
standard
table are by definition "User-defined". This table must be widely
published
- in fact should be included in the standard itself. Each
Classification
should include some brief description of what is intended to be
included and
what is not.
2) Revise the standard so that the header includes a mandatory lookup
table
to translate the internal codes of that file into "plain English".
I favor Option 1. It should not take too much to gather this
information
from the various vendors and users and compile this table. Publication
is
simple. Option 2 would be complex, confusing, and unreliable. It would
be
difficult to enact, impossible to enforce, and does not ensure any
uniformity. One person's "plain English" class descriptions might be
meaningless to someone else. Everything would in fact become "user-
defined".
-----Original Message-----
From: Taylor, Doug
Sent: Friday, April 23, 2004 12:48 PM
To: Karen Schuckman; Brad Herman; Martin Flood
Cc: Mike Renslow; Galla, Paul; Karl Heidemann; Jeff Walker
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
It's a definite problem. I've seen one vendor using the following
classifications:
0 = Normalized Surface - gridded data (added after processing)
5 = Canopy - all LiDAR data above the ground
6 = Building
8 = Keypoints - the filtered, bald earth surface
10 = Powerline
11 = Bridge
12 = Breakpoints - breakline vectors converted into points
13 = Superceded
While another vendor uses the following classificaions:
0 = Unknown
1 = Surface
2 = Buildings
3 = Vegetation
4 = Roads
5 = Water
6 = Poles
7 = Highwire
8 = Otherstruct
9 = User1
10 = User2
11 = User3
12 = Noise
13 = Edgematch
14 = Duplicate
You'd think with 256 values, we could all agree on a scheme that would
work.
-----Original Message-----
From: Karen Schuckman
Sent: Friday, April 23, 2004 11:01 AM
To: Taylor, Doug; Brad Herman; Martin Flood
Cc: Mike Renslow; Galla, Paul; Karl Heidemann; Jeff Walker
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
The discussion group at Yahoo is fine. I just meant that anything like
a
draft set of classification codes or specs ought to be posted on the
ASPRS
site, so people can find out about that it exists and is being
discussed.
Don't rely on the discussion group alone as the only means for people
to
find out about it.
My suggestion is to post the current draft at ASPRS or LAS websites,
with a
notation it is a very preliminary draft, that the discussion group
exists,
and that people are invited to join in and comment. At the meeting in
Denver
we then can discuss how to move this effort from its current state to
something more official.
-----Original Message-----
From: Taylor, Doug
Sent: Friday, April 23, 2004 11:39 AM
To: Brad Herman; Martin Flood
Cc: Mike Renslow; Karen Schuckman; Galla, Paul
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
My goal in starting the Yahoo lasformat group was for the technical
issues
within the LAS spec that were not being discussed (such as those I've
already posted). Thus the group would be similar to other format
related
lists such as those for TIFF and JPEG2000. I would've preferred an
official
ASPRS Lidar Cmte LAS discussion group somewhere, but it just wasn't
happening quick enough (IMHO). Perhaps the Cmte can establish one or
more
official discussion groups to replace LidarTalk and my lasformat
group.
Until then, please encourage your technical LAS friends and neighbors
to
join the Yahoo group.
The LAS spec is still young and I fear that many compatibility issues
already exist among those vendors that claim to support LAS. If LAS is
to
succeed, we all need to work together to iron out the kinks.
Doug
-----Original Message-----
From: Brad Herman
Sent: Friday, April 23, 2004 9:01 AM
To: Martin Flood
Cc: Taylor, Doug; Mike Renslow; Karen Schuckman
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
Makes sense. As long as there is a central location that people can
find
easily, say from a link on the ASPRS site, that's fine. I was just
concerned about fragmenting things instead of centralizing.
-----Original Message-----
From: Martin Flood
Sent: Friday, April 23, 2004 7:57 AM
To: Brad Herman
Cc: Doug Taylor; Mike Renslow; Karen Schuckman
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
Sadly, I had to shut down the LidarTalk discussion board in February
since
it kept getting hacked by somebody. It is no longer set-up as a
discussion
group that people can post questions/comments to.
Martin
-----Original Message-----
From: Brad Herman
Sent: Friday, April 23, 2004 7:23 AM
To: Martin Flood; Mike Renslow
Cc: Karen Schuckman; Doug Taylor
Subject: RE: ASPRS Lidar Committee - Lack Of A Published, ASPRS-
Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
How is this new discussion group different than the
http://www.lidarcentral.com/lidartalk/wwwboard.shtml group that is
linked to
directly from the ASPRS web site?
-----Original Message-----
From: Martin Flood
Sent: Thursday, April 22, 2004 5:05 PM
To: Mike Renslow
Cc: Karen Schuckman; Brad Herman; Doug Taylor
Subject: ASPRS Lidar Committee - Lack Of A Published, ASPRS-Accepted,
Industry-Standard Look-Up Table For Code-to-Class References In .LAS
Format
Hi all;
I'll add this item to the agenda for the lidar committee meeting in
Denver.
Incidentally, Doug has started a .las format discussion group at
http://groups.yahoo.com/group/lasformat as an unofficial LAS format
discussion forum. This might be a good place to refer people for some
discussion or feedback on this topic.
Martin
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/10
Wed May 5, 2004 8:30 am
Code-To-Class Schemes in .LAS
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The following was sent out earlier today. I'm posting here for
anybody that might not be on the lidar committee e-mail list. --- mf
--------------------------------------------------------------------
FYI: To All ASPRS Lidar Committee Members
An issue has been raised about the lack of any standard code lookup
when writing .LAS format files. Currently, whatever codes are used
in the specific software package or set by the user (e.g.
TerraScan .ptc file) for the various classes of points is what is
written to the output .LAS file. While there are some default
schemes, for example the default TerraScan scheme is:
TerraScan Default:
1 = Default (unclassified)
2 = Ground
4 = Medium Vegetation
5 = High Vegetation
6 = Building
7 = Low Point (noise)
8 = Model keypoint
many organizations are implementing their own unique coding schemes
resulting in a lack of standardization across .LAS files from
different organizations. An obvious challenge for a "standard" data
exchange format. It has been noted this lack of an openly
published, ASPRS-accepted, industry-standard lookup table is going
to be a problem for industry-wide LAS implementation. As released,
the .LAS standard does not include any requirement for documenting
the code-to-class reference within the LAS file. Every vendor/user
is able to develop their own system based on their own logic and
needs. Without a standard table for a fairly comprehensive,
commonly agreed upon set of classes, nobody will easily know what
points have been classified as what. This could become a major
problem for large end user organizations, such as government
agencies, who deal with data files from numerous different vendors.
Even a simple difference such as what basic code is used
for "ground" will make for a lot of unnecessary inefficiency in
dealing with files from different vendors.
To address this issue it has been suggested that the Lidar Committee
develop a comprehensive lookup table that includes all the various
classifications being used by all the major users, reduced to
eliminate duplications, but retaining each unique class. "User-
defined" classes will not be included in these standard codes – any
codes beyond those specified in the standard table are by
definition "User-defined". This table will be published – and
included in the standard itself. To maintain the ability to
customize for a particular organizations needs, user defined codes
will still be included, but moved to the block above the
designated "ASPRS" codes. For example,
Codes 0-48: Each specifically assigned by ASPRS based on
current standard classifications.
Codes 49-127: Reserved for Future ASPRS Use.
Codes 128-255: User Defined
To assist in the compilation of the ASPRS basic code assignments,
the Lidar Committee is requesting that any organization or
stakeholder that has an interest in this issue please submit any
code scheme(s) they wish to be considered. You can submit via e-
mail to lidar_committee@... with "LAS Code Scheme" in the
subject line. This issue will be discussed at the upcoming
committee meeting in Denver.
Those interested in following informal discussion on the .LAS format
may want to check out the Yahoo discussion group at group at
http://groups.yahoo.com/group/lasformat.
Much of the above is based on discussions and communications with
Karl Heidemann (EarthData), Doug Taylor (Z/I), Brad Herman
(NIIRS10), Karen Schuckman (EarthData) and Mike Renslow (SBG).
Thanks to all for bringing this issue to the table and (more
importantly) suggesting a solution.
Martin Flood
Chair, ASPRS Lidar Committee
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/11
Wed May 5, 2004 2:58 pm
Start of discussion on storing waveform data in the LAS file.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
here has been lots of hype about waveform data with lidar. I
thought it made sense to start a discussion on what this data might
look like and how it might fit into the las file format.
For our system there is only one waveform per laser shot meaning one
waveform for each outbound laser pulse. In the las file, we have a
record for each return. Therefore, if you have a laser shot that
produces 3 returns, you will get one waveform and 3 returns (3 las
records).
The waveform data will be big and will be very system dependent. In
our system is will be user configurable. This means that the
resolution will be variable (8+ bits) and the length of the waveform
(the number of meters worth of time that the waveform is recorded)
may change depending on the terrain. So basically, there will be a
lot of data and you dont want to leave space in the point data of
return 2 and return 3 when the waveform data is attached to return
1. So, attaching the waveform data to the point data will give
something like this in a las point record.
RETURN1DATA TIME WAVEFORMDATA
RETURN2DATA TIME NULL
RETURN3DATA TIME NULL
RETURN1DATA TIME WAVEFORMDATA
RETURN2DATA TIME NULL
where you will end up with a lot of unused space.
What I am leaning towards is putting the waveform data in a VLR. We
would require some way to attach the waves to there corresponding
points (gps time or an index) and having a second VLR that describes
the data.
The following information would be a good start for the wave
description VLR. Keep in mind that the wave data is similar to
viewing a signal on an oscilloscope. Therefore, you will require
similar information to that of an oscilloscope.
Waveform Resolution (bits per record, most likely 8, 10 or 12)
Waveform resolution as stored in the file (most likely 8 or 16)
Min Y value (the minimum voltage...a value of zero may not
necessarily equal a return voltage of zero)
Y scale (Volts per bit)
Sample rate (probable between .5GHz and 2+ GHz from the marketing
information that I have seen)
# of samples per wave
NOTE: The combination of the sample rate and the # of samples would
be used to compute the length (in meters) of the waveform
To complicate things further, the wave for a return from a tree would
be much longer than the wave for a return from a flat surface.
Therefore, the flat surface would create a lot of useless data. It
may make sense to store the waveform data with a variable length to
eliminate this useless data. Many VLR's OR a VLR of VLR's could be
used.
As you can see, there are some things that need to be discussed.
This is based on how our system works with the assumption that others
are at least similar. This remains to be seen.
Your comments are welcome on this issue!!!
Paul
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/15
Fri Jun 25, 2004 1:23 pm
Re: Start of discussion on storing waveform data in the LAS file.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Interesting to think about adding waveforms to .LAS, but I don't
know how immediately that is needed. Has anybody in the commercial
topo world started delivering waveform data yet? And if so for what
applications? I think there's still a lot of work to be done before
waveforms reach the point where enough people are using them that
they need a common data format. Have you considered talking to the
bathymetry folks? They've been using them for years.
--- Martin
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/26
Wed Dec 15, 2004 2:52 pm
Reliable extraction of last returns
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'd like to be able to pull last returns from an LAS file. To
accomplish this I'd think I should pull point records with a return
number equal to the number of returns given for the pulse. But then I
see a LAS file with this return information:
----------------
header ->
Points by return:
[1]: 18913702
[2]: 0
[3]: 5167790
[4]: 0
[5]: 0
And point records with this with return info ->
Rtn Rtns
3 2
-----------------
Is this valid? To have a return number greater than the number of
returns? If this is valid, how does one quickly and reliably get at
the last return for a pulse?
Clayton Crawford
ESRI Software Products
Redlands, CA USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/41
Thu Apr 7, 2005 9:25 am
Trajectory information in the LAS header
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hello all,
Is anyone using the TRJ importer in TerraScan? If so, is seems like we
should open a discussion on a trajectory header in the las file. I was
thinking that including the trajectory at one seconds intervals might
do the job. We could use the TerraScan TRJ format as a starting point.
Any thoughts on this?
Pau;
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/46
Wed Jun 1, 2005 10:50 am
las format exporter
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hi All,
Just a quick check to see if anyone out there has any software or code
written that will allow me to import/export my exisiting lidar
datasets
to las format?
Thanks in advance for anything you might have to offer!
Dave
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/49
Fri Aug 26, 2005 5:16 pm
Enlarge LAS angle formatz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hi All,
I would like to suggest that the "Scan Angle Rank" in the 1.1 format
be changed to either a double (for the actual angle) or a long (for
encoder counts).
As a lidar provider having one byte for angle is pretty much useless
for us.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/54
Mon Jan 23, 2006 1:05 pm
LAS 1.1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'm having trouble finding data in 1.1 format despite the
specification
being published nearly a year ago. One major data provider told me
that
none of the software they use, including Terrascan, supports it.
Does anyone have a lead? Are LAS providers going to skip 1.1 and go
straight to 2.0?
Clayton Crawford
ESRI Software Products
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/64
Wed Mar 8, 2006 3:38 pm
LAS v2.0 Scan Angle Rank
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hi All,
I posted the following in regards to the v1.1 spec and my comments
still apply now that this issue has been ignored in the 2.0 draft:
"I would like to suggest that the "Scan Angle Rank" in the 1.1 format
be changed to either a double (for the actual angle) or a long (for
encoder counts).
As a lidar provider having one byte for angle is pretty much useless
for us."
I do realize that with the new point format I can create a user
defined field to hold the true angle but I think this should be built
in to the Airborne scanner packet as an officially recognized field.
Additionally the fields listed in the scanner spec look suspiciously
like they have been pulled from 1 particular scanner/software vendor
and I think we should concentrate on creating a more generic usage.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/73
Wed Apr 19, 2006 9:38 pm
LAS Import/Export Solution
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hello Everyone,
It is apparent from a few posts here, and others on the USGS LIDAR
board and elsewhere, that translation to and from LAS is a bit
problematic. We've decided to include our translator in the free
version of LASEdit. Look for the "Batch" menu when the program
starts, there you will find the "Export from LAS Format" and "Import
to LAS Format" menu items. We're currently supporting free-form ASCII
and ESRI Point and PointZ formats:
http://www.cloudpeaksoftware.com/download/LASEditSetupFree.exe
-Rob B.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://tech.groups.yahoo.com/group/lasformat/message/76
Mon May 1, 2006 10:56 am
Poll results for lasformat
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lasformat] Poll results for lasformat
With the poll now closed and the results so clear, I will be
closing the lasformat Yahoo group later this week.
Please direct your discussions to the USGS Center for
LIDAR Information Coordination and Knowledge at
http://lidar.cr.usgs.gov/. Once there, you will find a
Bulletin Board link near the top.
--
Doug Taylor
Creator of the lasformat Yahoo group
Love God.
Love others.
Any questions?
> The following lasformat poll is now closed. Here are the
> final results:
>
>
> POLL QUESTION: There is a new lidar forum and bulletin board being launched
> and hosted by the USGS called CLICK. You can find details at
> http://lidar.cr.usgs.gov/ . It has been suggested that this would be a
> better permanent home for this LAS discussion forum, allowing issues and
> discussions to take place in the context of a full lidar forum. As well as
> having USGS support for maintaining the board. If we move this forum to
> CLICK, we will close this Yahoo group. We would like to poll everybody to
> see if they feel this is a good idea.
>
> Are you in favor of moving the LAS discussion/support forum on Yahoo! to the
> USGS CLICK forum?
>
> Poll closes April 31st.
>
>
> CHOICES AND RESULTS
> - Yes, 19 votes, 100.00%
> - No, 0 votes, 0.00%
Reply all
Reply to author
Forward
0 new messages