Ambiguity of Creation Day of Year and Creation Year

[hobu]

What is the issue about?

Inquiry about the specification

Issue description

I am wondering if there is an ambiguity in the language of these two header items. I have always taken "the file was created" to mean "when the point data stored in this LAS file were captured", not "when this file was written to disk".

Which is it?

File Creation Day of Year

Day, expressed as a uint16_t, on which this file was created. Day is computed as the Greenwich Mean Time (GMT) day. January 1 is considered day 1.

File Creation Year

The year, expressed as a four digit number, in which the file was created.

[kjwaters]

I've always understood it to be the day the file is created and not the date of point capture. Date of point capture could be different for every point and is part of the point record. A tile that mixes points from multiple flights will not have a sensible date to use for the file header. I've also usually found these header fields of little or no use.

Kirk Waters, PhD NOAA Office for Coastal Management Applied Sciences Program ‪Phone: 843-284-6962‬ (email preferred) coast.noaa.gov/digitalcoast

On Mon, Oct 2, 2023 at 11:23 AM Howard Butler @.***> wrote:

What is the issue about?

Inquiry about the specification Issue description

I am wondering if there is an ambiguity in the language of these two header items. I have always taken "the file was created" to mean "when the point data stored in this LAS file were captured", not "when this file was written to disk".

Which is it? File Creation Day of Year

Day, expressed as a uint16_t, on which this file was created. Day is computed as the Greenwich Mean Time (GMT) day. January 1 is considered day 1.

File Creation Year

The year, expressed as a four digit number, in which the file was created.

— Reply to this email directly, view it on GitHub https://github.com/ASPRSorg/LAS/issues/138, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5B33MQKUCKTK7BWEPW6Q3X5LL7TAVCNFSM6AAAAAA5PTCX22VHI2DSMVQWIX3LMV43ASLTON2WKOZRHEZDEMJTG4ZTKNQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[esilvia]

I agree with Kirk on all points, although I have seen it used both ways. I agree that the current writing leaves room for interpretation.

[hobu]

I've also usually found these header fields of little or no use.

Me too, other than using them to calculate which GPSWeek.

[connormanning]

When the GPS Time Type bit is not set, then "the GPS time in the point record fields is GPS Week Time". If the header values don't give you the basis for the GPS week offset, then how can you determine the timestamp for a point? What are the GPS time attributes (per-point) relative to?

[kjwaters]

Connor, I think that is aligned with initial reasoning for the field, assuming you're working with swath data. The data with GPS seconds of the week is (hopefully) older data. In my experience it is rarely found in swath format and even when it is, this field is often not filled out such that you can figure out the week. That's why I don't usually find it useful.

Kirk

On Mon, Oct 2, 2023 at 12:04 PM Connor Manning @.***> wrote:

When the GPS Time Type bit is not set, then "the GPS time in the point record fields is GPS Week Time". If the header values don't give you the basis for the GPS week offset, then how can you determine the timestamp for a point? What are the GPS time attributes (per-point) relative to?

— Reply to this email directly, view it on GitHub https://github.com/ASPRSorg/LAS/issues/138#issuecomment-1743296646, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5B33IK5Q6R5E2LYDS4AYLX5LQXXAVCNFSM6AAAAAA5PTCX22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBTGI4TMNRUGY . You are receiving this because you commented.Message ID: @.***>

[mgswartz1]

Suggestion: If GPS Week Time is used, The GPS Week should be included in a VLR or EVLR.

[esilvia]

I have always liked the idea of a lookup table VLR that matched PtSourceID with GPS Weeks. Having a single value for an entire file does not work because of prolonged large scale collections spanning many weeks/months/years.

[abellgithub]

One could clarify that the day/year should be the date the file was produced.

One could also take a few bits from global encoding to specify the GPS week range. I'm sure 4 bits would do or would get us by until we're all dead and it's someone else's problem.