should legacy counters be zero for new LAS 1.4 point types (6 and up)?

[Martin Isenburg]

Hello,

Properly populated 32 bit legacy counters are only useful for LAS 1.4 files that are forward-compatible with older LAS formats, hence that store less than 4 billion LiDAR returns and use the old point type 0 to 5.

I think the understanding was that we set these 32 bit legacy counters to zero when the new LAS 1.4 point types 6 and higher are used. However, I have now come across "test content" from two large companies where the legacy  counters were populated for point types 6, 8, and 9.

Currently the LASvalidator does not fail such LAS files but I propose to add this as another way to fail the validation. Keeping two sets of non-zero counters around *without* the opportunity of forward compatibility (that can only happen for point types 0 to 5) is pointless.

Unless I hear strong opposition I will add these cases as a "fail" to lasvalidate ...

Regards,

Martin

[Lewis Graham]

I would interpret the spec as you state below.  We indicate the legacy fields should be zero when not in legacy mode.  We also directly state that the non-legacy fields must always indicate the number of point records.

 

 

Legacy Number of point records:  This field contains the total number of point records within the file if the file is maintaining legacy compatibility and the number of points is no greater than UINT32_MAX.  It must be zero otherwise.

 

Legacy Number of points by return:  These fields contain an array of the total point records per return if the file is maintaining legacy compatibility and the number of points is no greater than UINT32_MAX.  The first value will be the total number of records from the first return, the second contains the total number for return two, and so on up to five returns.  If the file is not maintaining legacy compatibility, each member of the array must be set to zero. 

 

 

 

Number of point records: This field contains the total number of point records in the file.  Note that this field must always be correctly populated, regardless of legacy mode intent.

 

Number of points by return: These fields contain an array of the total point records per return.  The first value will be the total number of records from the first return, the second contains the total number for return two, and so on up to fifteen returns.  Note that these fields must always be correctly populated, regardless of legacy mode intent.

 

 

 

Lewis Graham

GeoCue Group

9668 Madison Blvd., Suite 202

Madison, AL USA 35758

01-256-461-8289

www.geocue.com

www.airgon.com

www.LP360.com

 

LIDAR and Image Production Workflow Tools

Terrasolid sales and support

LP360 point cloud tools for ArcGIS

Small unmanned aerial systems hardware, processing software and services

Holder of FAA Section 333 sUAS exemption

--
--
You are subscribed to "The LAS room - a friendly place to discuss the the LAS or LAZ formats" for those who want to see LAS or LAZ succeed as open standards. Go on record with bug reports, suggestions, and concerns about current and proposed specifications.
 
Visit this group at http://groups.google.com/group/lasroom
Post to this group with an email to las...@googlegroups.com
Unsubscribe by email to lasroom+u...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "The LAS room - a friendly place to discuss the LAS and LAZ formats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lasroom+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Evon Silvia]

​Good question! Let's check the text from pages 7-8 (italics emphasis mine):

Legacy Number of point records: This field contains the total number of point records within the file if the file is maintaining legacy compatibility and the number of points is no greater than UINT32_MAX. It must be zero otherwise.

Legacy Number of points by return: These fields contain an array of the total point records per return if the file is maintaining legacy compatibility and the number of points is no greater than UINT32_MAX. The first value will be the total number of records from the first return, the second contains the total number for return two, and so on up to five returns. If the file is not maintaining legacy compatibility, each member of the array must be set to zero.

My reading of the LAS 1.4 specification is that the legacy point counters are optional, regardless​ of which point formats are being used. This allows older readers that don't support LAS 1.4 to still get insight into the contents of the file. If the legacy counters are non-zero or would exceed the UINT32_MAX value, though, they must be exactly the same as the Extended point counters, so that's what I would say is the basis for a pass/fail determination.

You could argue that if you're using point formats 6-10 then you can't be maintaining legacy compatibility, but I think that making the header compatible is a separate issue from a particular point data format being supported. Others are free to disagree.

In my opinion, the legacy counters should have been deprecated in the LAS 1.4 specification in the first place, but that's not how the specification is currently written. Any distinction of "valid" versus "invalid" should reflect the current state of the specification, though, not our opinion of an ideal LAS file. If you want to give a warning, though, that's fine. I just wouldn't call it invalid.

Evon

--

Evon Silvia PLS Solutions Developer 517 SW 2nd Street, Suite 400, Corvallis, OR 97333 P: (541) 452-8502 E: esi...@quantumspatial.com

--

[Martin Isenburg]

Evon,

The legacy counters exist mainly because I made forward-compatibility a big deal when we discussed this in 2011. These counters can only create forward-compatibility for the old point types if there are less than 4 billion points. There is absolutely no necessity to set them to anything but zero for the new point types. You will also do any software a favor that does uses an if (point type == 0) { } else if (point type == 1) { } else if (point type == 2) { } else if (point type == 3) { } else if (point type == 4) { } else { } statement or similar as you prevent it from reading unknown LAS 1.4 point types as point type 5 ... (-:

> My reading of the LAS 1.4 specification is that the legacy point counters are optional, regardless​ of which point formats are being used.

That was not what I was fighting the great laser war of 2011 for ... (-; ... it was only to remain compatible - if you want to do so - on case the old point types are used. And those old point types remain the main requested point types in the international (non-US) tenders that I know about ...

Come on guys ... Lewis and me agree for once. Let's make this happen ... (-;

Regards,

Martin @rapidlasso

[Terje Mathisen]

I have to agree with Martin here:

A valid 1.4 file should have all the old 32-bit counters set to zero
UNLESS BOTH the following requirements are met:

a) All internal data types are compatible with pre-1.4 formats.

b) All counts (including the total point count) fits in 32-bit.

Setting all those counts to zero is a very strong indicator to old sw
that it probably shouldn't try to read the file!

Terje

> Regards,
>
> Martin @rapidlasso

>
> --
> --
> You are subscribed to "The LAS room - a friendly place to discuss the
> the LAS or LAZ formats" for those who want to see LAS or LAZ succeed
> as open standards. Go on record with bug reports, suggestions, and
> concerns about current and proposed specifications.
>
> Visit this group at http://groups.google.com/group/lasroom
> Post to this group with an email to las...@googlegroups.com
> Unsubscribe by email to lasroom+u...@googlegroups.com
> ---
> You received this message because you are subscribed to the Google
> Groups "The LAS room - a friendly place to discuss the LAS and LAZ
> formats" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to lasroom+u...@googlegroups.com

> <mailto:lasroom+u...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
- <Terje.M...@tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Evon Silvia]

Works for me. 

Evon

To unsubscribe from this group and stop receiving emails from it, send an email to lasroom+u...@googlegroups.com.

[Martin Isenburg]

Hello,

this was added to the newest version of the LASvalidator. The error will show up like this in the XML file:

[...]

     <fail>

       <variable>legacy number of point records</variable>

       <note>should be 0 for LAS 1.4 files that contain point type 8</note>

     </fail>

     <fail>

       <variable>legacy number of points by return[0]</variable>

       <note>should be 0 for LAS 1.4 files that contain point type 8</note>

     </fail>
[...]

I have also added a new check that fails files where any single "number of points by return" entry reported in the header is bigger than the total number of returns in the file. the same check is also done for the sum of all "number of points by return" entry reported in the header.

The new lasvalidate.exe is already up on github and will be included in the next verison of LAStools ....

http://github.com/LASvalidator/lasvalidate/commit/22963ea69e28ae360cd3690bd846a599a9a08d1e

Regards,

Martin @rapidlasso