ASPRSorg / LAS

LAS Specification
https://www.asprs.org/committee-general/laser-las-file-format-exchange-activities.html
151 stars 17 forks source link

Add "extended statistics" standard VLR #39

Open esilvia opened 7 years ago

esilvia commented 7 years ago

Currently the header lists statistics like pt count by return and min/max XYZ, but it'd be useful to have stats for other attributes. Examples:

  1. Point counts by point source ID
  2. Point counts by class
  3. Point counts by channel
  4. Min/max scan angle
  5. Min/max intensity
  6. Min/max GPS time
  7. Intensity histogram (might need to be its own VLR)

I know there's existing implementations of something like this, so ideally we could adopt/extend one of those to encourage adoption.

nkules commented 4 years ago

Evon this is definitely something that I am in support of! Without these there are a lot of full file reads to get these values and to double check them for changes. One question I do have, is how best could version control be implemented here to ensure the VLR is actually up to date with the file?

The case I see happening is a software updates the point cloud (e.g. classification) but doesn't repopulate the VLR. It would be good to have some sort of information tied to the VLR to verify it still matches the file (without reading the full file). I cant think of a mechanism off the top of my head other than some sort of edited timestamp tag, but these are not foolproof. Something like a checksum will require a full file read to verify anyways.

hobu commented 4 years ago

/me votes for JSON format and a JSON Schema describing those statistics with clear demarcation of required and optional stats.

esilvia commented 4 years ago

@hobu I really like that idea! There's no need for a short record like this to be as compact as possible, so it can afford to be self-describing.