Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "extended statistics" standard VLR #39

Open
esilvia opened this issue Oct 18, 2017 · 3 comments
Open

Add "extended statistics" standard VLR #39

esilvia opened this issue Oct 18, 2017 · 3 comments

Comments

@esilvia
Copy link
Member

esilvia commented Oct 18, 2017

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.

@esilvia esilvia added this to the v1.4 R14 milestone Oct 18, 2017
@esilvia esilvia removed this from the v1.4 R14 milestone Oct 19, 2018
@nkules
Copy link

nkules commented Mar 20, 2020

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
Copy link
Contributor

hobu commented Mar 20, 2020

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

@esilvia
Copy link
Member Author

esilvia commented Jul 15, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants