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

Customizable metadata when writing COPC files #139

Closed
wonder-sk opened this issue May 1, 2023 · 3 comments · Fixed by #149
Closed

Customizable metadata when writing COPC files #139

wonder-sk opened this issue May 1, 2023 · 3 comments · Fixed by #149

Comments

@wonder-sk
Copy link
Contributor

Some pieces of metadata are not kept when a LAS/LAZ file is processed with untwine:

  • global encoding - the bit on GPS time shift is not preserved
  • creation time - hardcoded to day 1 of year 1
  • X/Y/Z offset - untwine picks the offset itself (in the center of the data) rather than reusing the original one
@abellgithub
Copy link
Collaborator

Is this request just in the case of a single input file?

@hobu
Copy link
Collaborator

hobu commented May 1, 2023

Is this request just in the case of a single input file?

Yeah. I was thinking of providing options to allow people to explicitly set the metadata rather than trying to mimic PDAL's forward behavior, which would be fraught.

@uclaros
Copy link
Contributor

uclaros commented Dec 18, 2023

Is this request just in the case of a single input file?

For the cases of a single input file, which is always the case in QGIS, I think it makes sense to default to the following:

  • preserving the gps time bit, as it allows proper interpretation of gps times for the file
  • Creation year/day for a single file should be updated, as the las spec states: Day, expressed as an unsigned short, on which this file was created. This file applies to the copc output file.
  • Since the scaling is preserved, it makes sense to also preserve the offsets.

I consider options to explicitly set the metadata as a quite advanced feature that the majority of users shouldn't need to deal with, as long as sane defaults are used.

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

Successfully merging a pull request may close this issue.

4 participants