search

ASPRSorg / LAS

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

Standardization of common extrabytes #37

Open esilvia opened 6 years ago

esilvia commented 6 years ago

We've discussed listing some standardized extrabytes either in the specification itself or a supplementary document. This would encourage their adoption by the community and formalize common extrabytes as a guideline to future implementations.

We need to figure out the following:

  1. Which extrabytes merit standardization?
  2. Which fields should be formalized? e.g., optional fields like min, max, and nodata might not make sense.
  3. Should data_type be formalized?
  4. Where will this list live? Will it formally be included in the specification itself (thereby requiring ASPRS approval every time one gets added), or perhaps as a wiki page on GitHub with a link from the specification? I propose the latter.
  5. What will be the approval process for new additions? (I propose people submit new Issues and then LWG votes yes/no).
  6. Should units be formalized? For example, will we have to have separate entries for "refracted depth" in meters and feet?

Below is a link to what I think is a decent start to the standardized extrabytes. Once we get some agreement on a few of these I can start building a wiki page or contribute to Martin's pull request. Which one we do depends on the answer to the 4th question.

Standard ExtraBytes v1.docx

abellgithub commented 11 months ago

Spaces in names is yuck. Other than that, I have no opinion.

rapidlasso commented 11 months ago

Thanks Evon for sharing this conversation. Thanks @all for the comments and the input. Just to make my opinion known: I also think the naming of extra bytes is not part of the specifiaction. On the other hand it would be good to have an orientation how to name fields with a certain content. Therefore the Wiki seems to be a good place. About "good" names I think it is worth to avoid spaces in names when names come close to identifiers or tokens which are may also used in programming languages, databases and so on. As soon we list those names in a wiki it is not a very good argument to say "Is was like this in the past..." So I would prefer names in camel case or with "_" instead of a space.

esilvia commented 9 months ago

Spaces in names is yuck. Other than that, I have no opinion.

I'm at JALBTCX this week discussing the LDP v2 that was developed in #117 and approaching publication. This includes updates to the ExtraBytes being used, and I'm trying to decide whether or not I should rename the ExtraByte fields in the v2 upgrade.

Can @abellgithub or anyone elaborate on "spaces in names is yuck"? I get that the dev community has historically avoided spaces like the plague (windows path errors, anyone?), but any sane language or library should be able to handle spaces in a char array, especially one that interacts with LAS which explicitly specifies that its char arrays are null-terminated.

Why would removing spaces be a need here? Are folks trying to use ExtraByte names as variable names or key values? Or is this not a need I should attempt to support?

kjwaters commented 9 months ago

My main reason to avoid spaces is that they mean you have to remember to quote or escape them any time you might want to use that name in a command line interface.

Kirk

On Thursday, November 30, 2023, Evon Silvia @.***> wrote:

Spaces in names is yuck. Other than that, I have no opinion.

I'm at JALBTCX this week discussing the LDP v2 that was developed in #117 https://github.com/ASPRSorg/LAS/issues/117 and approaching publication. This includes updates to the ExtraBytes being used, and I'm trying to decide whether or not I should rename the ExtraByte fields in the v2 upgrade.

Can @abellgithub https://github.com/abellgithub or anyone elaborate on "spaces in names is yuck"? I get that the dev community has historically avoided spaces like the plague (windows path errors, anyone?), but any sane language or library should be able to handle spaces in a char array, especially one that interacts with LAS which explicitly specifies that its char arrays are null-terminated.

Why would removing spaces be a need here? Are folks trying to use ExtraByte names as variable names or key values? Or is this not a need I should attempt to support?

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

-- Sent from a mobile device subject to autocorrect errors.

esilvia commented 9 months ago

My main reason to avoid spaces is that they mean you have to remember to quote or escape them any time you might want to use that name in a command line interface. Kirk

@kjwaters OH that makes total sense. I'll propose that change in the Bathy Working Group meeting tonight, if I get a chance.