Can GeoTiffs be present in las 1.4, PDRF 6-10 as long as WKT is being used?

[MelissaJames21]

My interpretation of the spec is that GeoTIFFs should not be present in PDRF 6-10, but if they were, they should be set to superseded. However, I've recently heard a different perspective from a software company we work with. Their perspective is that it should not matter if there is a valid GeoTIFF in a las 1.4 PDRF 6-10 file alongside valid WKT, because a software reader is set to follow the spec and only read the WKT.

The specification says:

It is considered a file error to have more than one GeoTIFF (E)VLR or more than one WKT (E)VLR in the file. A writer can append a new CRS EVLR to a file by “superseding” the existing CRS (E)VLR.

But is it a file error to have both a GeoTIFF and WKT in las 1.4, PDRF 6-10 with neither set to superseded?

[nkules]

Melissa in my opinion would say yes it would be an error to have more than one CRS in a file (VLR,EVLR,WKT,or geotiff tag) without all set as superseded except for the one that supersedes.

This is not the LAS spec but the 3DEP base specification that states something similar:

A given LAS file may contain any number of CRS entries, as VLRs and (or) EVLRs in any combination, as WKT and (or) GeoTIFF in any combination, regardless of the PDRF, provided that:

•ALL entries shall be tagged as “Superseded”—EXCEPT for the single valid entry to be used. See LAS specification version 1.4–R13 (ASPRS, 2011) for further details.

For machine readability it would only make sense to have one superseding value, otherwise there is a conflict. I would be curious if anyone had any differing views.

I do see the need to maybe clear up the specification verbiage shown above for the LAS specification. It does make it sound like it is a file error to have more than one CRS in the file, when I believe it is trying to say its a file error if there are more than one without superseding.

[MelissaJames21]

Thanks for the feedback Nick. I'm aware of the 3DEP spec, and I would like to determine if the 3DEP spec is more restrictive or in-line with the LAS spec. I didn't even think of clarifying the LAS specification in the manner that you said, though I do agree with it! The part I think needs clarified is whether you can have both a GeoTIFF and WKT with neither superseded. It says you cannot have more than 1 GeoTIFF or more than 1 WKT, but it doesn't say you cannot have 1 of each. I also would be curious what others have to say.

[abellgithub]

I don't think there is any prohibition on having both VLRs in a file, but you shouldn't expect any reader that follows the standard to use the geotiff VLR in any way.

[nkules]

@abellgithub I believe Melissa is asking in the case that there are both one WKT and one Geotiff, should one be required to be denoted as superseded.

Also @MelissaJames21 with thinking about it, technically the global encoding flag for WKT should resolve the conflict in the case that you have a single instance of both. However I would think its always safer to to have less ambiguity with having explicit superseding. I'd be curious if the software vendors we have on here have good examples where there is the need to have both set and use the global WKT flag as the only control.

[abellgithub]

The specification is clear on this. When your file data is dataformat ID 6-10 and has an SRS, the WKT bit in the global encoding field must be set and the SRS must be specified in a WKT VLR.

[rapidlasso]

My tools tend to store both as older software tends to parse the good old GeoTIFF tags with more success than the new OGC WKT strings.

[nkules]

@abellgithub you are correct that the specification defines that a reader should report an error in this case. However that doesn't guarantee that all readers abide by that rule.

Another non automated example is an end user may have a tool that prints out all VLRs/EVLRs, and it may not be clear to the human reader which CRS the file has set, unless they understand the PDRF rule. Granted they still need to understand what supersede means, and the geotiff tag isnt really going to be readable to the human anyways.

My point is that isnt it much more type safe to state that in any case, any multiple crs cases must be superseded? In the case of PDRF 0-5 it does not clearly state that you cannot have this same scenario (one wkt and one gtif), and only the global bit is controlling this.

However at the same time I find it messy to even have files with multiple CRS records in the first place, but thats just my opinion :)

[nkules]

@rapidlasso Martin that is great info. In your particular reader case, will you still read geotiff tags on pdrf 6-10 if wkt bit is set to false? Not trying to call out if you are following the error spec, just genuinely curious since I haven't tested that case with your tools.

I agree that WKT can be difficult to parse, particularly since there are huge inconsistencies across the industry in adoption. But thats its own topic!

[rapidlasso]

My tools first try the OCG WKT (for point types 6 and higher) and if it fails they try the GeoTIFF tags.

[nkules]

Thanks Martin! Thats great info to know. So in your case prescribing superseding of the geotiff actually breaks your fallback option.

[MelissaJames21]

Thanks for the feedback everyone. It sounds like it is not a file error to have both a Geotiff and WKT in pdrf 6-10 (neither superseded). It is up to the software reader to correctly follow the las spec and only read the WKT. Nick, I agree with you, it does seem messy, but apparently there are uses for it. For what it's worth, USGS will continue to require anything other than 1 valid WKT be set to superseded in pdrf 6-10.

[esilvia]

Great question. I’ll be referencing R15, which is the latest.

Section 2.2 is silent on the issue. However, a paragraph in section 3.1 does explicitly clarify that PDRF 0-5 “can use either GeoTIFF or WKT, but not both simultaneously.” This paragraph existed in R13 under the section entitled “Coordinate Reference System Information” on page 21.

This sort of implies that PDRF 6-10 shouldn't have both, either, but doesn't explicitly prohibit it as long as the WKT bit is set in the header. As long as the WKT bit is set, the GeoTiff CRS VLR should be ignored.

Personally, I’ve always considered it an either-or situation. The premise is that the WKT and GeoTIFF definitions are nearly impossible to match exactly, so allowing both to exist in a file will inevitably result in an implicit conflict between the two.

Martin's approach of using GeoTiff as a fallback seems valid to me, however, as there's no restrictions against "unused" VLRs coming along for the ride.

[esilvia]

In this situation, it seems to me that the spec is a little confusing, but I don't believe that it requires correction in the text at this time. In light of the conversation, I don't believe that a revision to the specification is required to provide further clarity.

[MelissaJames21]

Thanks for the clarification Evon. Do you see this being clarified in conjunction with a future update of the spec?

[esilvia]

@MelissaJames21 sorry I missed your question somehow.

I can see clarifying this in LAS 1.5 as part of the WKTv2 update in #95. I would recommend that the spec state that the global encoding bits indicate which CRS VLR set (geotiff, WKTv1, WKTv2) is authoritative and required, but that the other CRS encoding VLRs can still be present so long as the global encoding bits are not set.

This would affirm that CRS global encoding bits are mutually exclusive and avoid conflicting but equally valid CRS definitions, while still allowing the "fallback" option when/if the primary CRS definition is unsupported or corrupt.

[MelissaJames21]

@esilvia thanks for the follow-up! Sounds like a good solution.