Add Timestamp Min/Max to LAS 1.5 header

[esilvia]

I think it might be worthwhile to add a Min/Max Timestamp to the LAS 1.5 header. It would share encoding with the PDRF timestamps, including the new encoding format from #6.

Because of the diversity of interpretation of several of the fields (e.g., PtSourceID), it's probably not realistic to add MBRs for every field to the LAS header itself. We can use a VLR for that, as in #39. This thread should be constrained to discussing adding just the timestamp range to the header.

[esilvia]

Added clarifying language for the aggregate model systems, typo fixes, during today's LWG call. Merged into 1.5 draft and complete!

[wiesehahn]

Do I understand it correct that with the upcoming 1.5 standard we can finally extract the date range a pointcloud file was acquired just by reading the header (without having a look at every single points gpstime)?

(also refers to #138 and PDAL/wrench#36)

[kjwaters]

That's certainly the idea. Like everything else in the header, it depends on the writer of the file to put the correct values in. Kirk

…

On Fri, Nov 8, 2024 at 6:13 AM Jens Wiesehahn ***@***.***> wrote: Do I understand it correct that with the upcoming 1.5 standard we can finally extract the date range a pointcloud file was recorded just by reading the header (without having a look at every single points gpstime)? (also refers to #138 <#138> and PDAL/wrench#36 <PDAL/wrench#36>) — Reply to this email directly, view it on GitHub <#118 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5B33PV5JSLZTLI7QDVFQLZ7SMDTAVCNFSM6AAAAABRNIGPOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRUGQZTIMRUHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hobu]

Do I understand it correct that with the upcoming 1.5 standard we can finally extract the date range a pointcloud file was acquired just by reading the header (without having a look at every single points gpstime)?

copc.io has gpstime ranges in its VLR info if you want a jump start on that capability.

[wiesehahn]

Oh thanks, didn't knew it was implemented in COPC.

Is there an estimated release time for 1.5?

[esilvia]

The draft version of LAS 1.5 should be ready in time for GeoWeek 2025, February 10-12.

[wiesehahn]

copc.io has gpstime ranges in its VLR info if you want a jump start on that capability.

Not sure if this is correct, but if I understand it correctly we cant get the gpstime range from older las files where it is not yet encoded as the adjusted Standard GPS time. In this case we would need additional information about gps week which is not available in the las file. Correct?
If yes what happens if we want to convert these to COPC?

[hobu]

If yes what happens if we want to convert these to COPC?

Yes, you'll need the gps week to be able get to standard time.

The ranges are intended to provide the domain of the time values in the file, just like min/max x,y,z that's been in the header since 1.0. Scaling and offset, in the case of xyz, or gpstime offset, for gpsweek or the upcoming 1.5 time offset value, need to be applied by the consumer of the data as needed.