Clean up heading heirarchy and organization

[esilvia]

The headings and text file division don't really make a lot of logical sense to me, weren't really properly implemented in the original spec, and seem hard to maintain in the long run. It should be pretty straightforward to redo the headings and text file divisions into something more sensible.

I'm thinking something like the attached organization should work fine, with one text file for each major section except number 2, which will have a text file for each subsection:

1. Introduction
2. LAS Format Definition 2.1. Legacy Compatibility (LAS 1.1 - LAS 1.3) 2.2. Coordinate Reference System (CRS) Representation 2.3. Data Types 2.4. Public Header Block 2.5. Variable Length Records (VLRs) 2.6. Point Data Records 2.7. Extended Variable Length Records (EVLRs)
3. Coordinate Reference System VLRs (required)
4. Other Specification Defined VLRs (optional)
5. Defined Extended Variable Length Records (EVLRs)
6. LAS Domain Profiles

Can probably be implemented alongside #28. Note that the TOC only shows sections and subsections, so 3-digit sub-sub-sections won't appear on the TOC, such as 2.6.7 (PDRF6). las toc.docx

[esilvia]

Solidifies #49 into something that'll last longer.

[hobu]

I'm 👎 on refactoring the headings in a revision. Doing so makes referencing the same thing very difficult. Now we will have to be very specific about revision too, and this is not a distinction anyone beyond the LAS committee practically makes.

I'm definitely 👍 on refactoring the heading organization when we +1 the minor_version. I agree it is kind of haphazard, and I would suspect this is due to just natural growth of the document.

[esilvia]

Well, when I browse through the original docs (R13) I only see section numbers on 1. Purpose, Scope (etc), 2. Conformance, 3. Authority, and 4. Requirements. After that it looks like the numbers drop off, so R14 is really the first time they've appeared, which means no one's using them yet.

For that reason, I'm wondering whether now's a good time to implement them "for the first time." Maybe R14 is the better revision for this? AFAIK it hasn't been formally approved yet.

[esilvia]

@hobu Any other thoughts on this? I'm still thinking it's worth doing since the section numbers from R13 and before were essentially nonexistent. As far as I can tell it'll mostly be a change in heading for the sake of the TOC, which is getting added in this revision anyway.

[hobu]

Adjust the headings and arrangement as you see fit so long as people can conveniently navigate the document. The linked ToC helps a ton with this, and that didn't exist before.

[esilvia]

Agree 100%. I'll have a draft of this up soon.

[esilvia]

@hobu Can you take a look at the file structure of 951cec0d240e29f464427bd26a5772a214331a8f and make sure it makes sense to someone besides me? It took a few tries to get right because I couldn't split the 02.xx files into separate files without inlining them in 02.00 instead of listing them in the TOC as before.

One thing I'm on the fence about is having a new section number for every point/header attribute vs. simply formatting it with bold-underline.

With headings (951cec0d240e29f464427bd26a5772a214331a8f): https://s3.amazonaws.com/asprs-las/LAS-specification-951cec0d240e29f464427bd26a5772a214331a8f.pdf

Without headings (8dfc1b028c5841ac93bf43c4367cb1f60a4df605): https://s3.amazonaws.com/asprs-las/LAS-specification-8dfc1b028c5841ac93bf43c4367cb1f60a4df605.pdf

Can you or someone else take a look? I was very careful to use git mv while renaming the files so that the commit history stayed very clean and doesn't break merges.

[esilvia]

Even cleaner version (0f9d5b52d6d36a00cb108cf3b2839f7483f6766e): https://s3.amazonaws.com/asprs-las/LAS-specification-0f9d5b52d6d36a00cb108cf3b2839f7483f6766e.pdf

[esilvia]

It seemed sensible to also swap the order of 1.1.2 and 1.1.1 so that the revisions of the current version are front and center. See the pull request for more info.