Re: [The LAS room] How to manage unexistent Coordinate Reference System?

[Martin Isenburg]

Hello Guillaume,

This is an excellent question. What to do with LAS / LAZ files that *cannot* have a Coordinate Reference System.

We would need an agreed-upon mechanism in order to distinguish those LAS / LAZ files that cannot have CRS information from those LAS / LAZ files that the LASvalidator check was designed to "fail":  files that are missing the mandatory CRS information altogether, that have incomplete or corrupt GeoTIFF tags, or - someday in the future - have incompatible information between the GeoTIFF tags in the OGC WKT definition.

I think your suggestion of using the GeoTIFF key GTModelTypeGeoKey with value 0 (undefined) is great. We could then turn the "fail" into a "warning" to accomodate doftware such as Trimble Real Works that want to leverage the popularity of the LAS / LAZ format but whose exports would otherwise be damned forever due to the systematic lack of CRS information.

Unless i hear vehement disagreement i will enhance the CRS check of the LASvalidator such that LAS / LAZ files that *explicitely* specify that they do not have CRS information will get only a "warning" instead of a "fail" by the LASvalidator ...

Regards,

Martin @rapidlasso

--
http://rapidlasso.com - fast tools to validate your LiDARs

On Oct 3, 2014 5:17 PM, "Guillaume Tremblay" <guillaume...@trimble.com> wrote:

Some software, like Trimble RealWorks for instance, do not work with Coordinate Reference System. However, LAS specification says "There is one mandatory Variable Length Record, GeoKeyDirectoryTag".

How should software vendors exporting in LAS format without supporting the go-referencing system handle this? Should a software without CRS leave the field empty (that makes lasvalidate.exe from LAStools complain) or should it fill it with a structure like this:


        // Set GeoTiff parameters
        laszip_geokey_struct key_entries[1];

        // projected coordinates
        key_entries[0].key_id = 1024; // GTModelTypeGeoKey
        key_entries[0].tiff_tag_location = 0;
        key_entries[0].count = 1;
        key_entries[0].value_offset = 0; // Undefined


Which, in other words, says explicitly that the GeoTIFF coordinate fields are irrelevant and the file cannot have geo-referencing info. This option also makes lasvalidate.exe from LAStools complain.

It seemed to me that GeoTiff specification mentioned in the ASPRS LAS format document (http://www.remotesensing.org/geotiff/geotiff.html) says that a value of 0 for fields such tiff_tag_location means a value that should not be interpreted.

Is it better to put no information even though it is required by standard or to put information that cannot be exploited?

--
--
You are subscribed to "The LAS room - a friendly place to discuss the the LAS or LAZ formats" for those who want to see LAS or LAZ succeed as open standards. Go on record with bug reports, suggestions, and concerns about current and proposed specifications.
 
Visit this group at http://groups.google.com/group/lasroom
Post to this group with an email to las...@googlegroups.com
Unsubscribe by email to lasroom+u...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "The LAS room - a friendly place to discuss the LAS and LAZ formats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lasroom+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Guillaume Tremblay]

Martin,

Trimble RealWorks has implemented the above solution when exporting LAS 1.2 files to clearly state that the Coordinate Reference System has been intentionally left blank and that seems to be working fine.

I wonder how this could be done for LAS 1.4 files with point type in the 6-10 range. ASPRS says we must use WKT and so does lasvalidate.exe (libLAS seems to have a different opinion, cf: Georeferencing LAS files with LAS 1.4, but I am not sure it is widely shared among LAS community members).

As long as version 140704 of lasvalidate.exe is concerned, setting the WKT bit and writing a non-empty VLR is enough to pass the test. The code snipet below makes lasvalidate happy.

However, if the payload is 0 byte (instead of "N/A" for instance in the example) lasvalidate complains about empty payload. I would have think that setting an empty WKT header would have the same meaning as setting GTModelTypeGeoKey  to 0 for GeoTiff: the case where the file cannot have a CRS.

What do you think?

                header->global_encoding |= ( 0x1 << 4 ); // Set bit for WKT

                laszip_vlr wkt_vlr;
                memset( &wkt_vlr, 0, sizeof( laszip_vlr ) );
                strcpy( wkt_vlr.user_id, "LASF_Projection" );
                wkt_vlr.record_id = 2112;
                strcpy( wkt_vlr.description, "Coordinate System WKT" );
                wkt_vlr.data = ( laszip_U8* )"N/A";
                wkt_vlr.record_length_after_header = (laszip_U16)strlen( (char*)wkt_vlr.data );
                if ( laszip_add_vlr( laszip, &wkt_vlr ) )
                {
                    throw( "DLL ERROR: adding WKT to the header" );
                }

[Martin Isenburg]

Hello folks,

unless I hear strong protests I am planning to follow Guillaume suggestion. I will change lasvalidate so that it will only emits a "WARNING" instead of a "FAIL" if the OGC WKT VLR of a LAS 1.4 file that uses the new point types is there but has an empty payload making this the (inofficially) accepted way to leave the Coordinate Reference System be intentionally left blank (as it may not exist like in local project space).

In order to prevent lazy export software from simply always adding an empty payload to their LAS/LAZ files and then continue using only GeoTIFF tags even with the new point types (which would make Lewis very unhappy (-;) I suggest that such an intentionally left blank CRS in the OCG WKT will only be acceptable (-> only a "WARNING" in lasvalidate) if

(a) there is no other CRS specified via GeoTIFF tag

(b) there are GeoTIFF tags and the GTModelTypeGeoKey is set to the value 0 (undefined). 

Comments?

Martin

[Evon Silvia]

I agree with this principle to have an empty payload to convey the "intentionally left blank" concept, with a couple reservations.

My reading of the specification gave me the impression that the GeoTIFF and WKT VLRs would be mutually exclusive. Table 4 of the LAS 1.4 specification states...

If set, the Coordinate Reference System (CRS) is WKT. If not set, the CRS is GeoTIFF. It should not be set if the file writer wishes to ensure legacy compatibility (which means the CRS must be GeoTIFF).

Additionally, the Coordinate Reference System Information section on page 21 of R13 states (emphasis added)...

The Coordinate Reference System (CRS) information for the point data is required for all data. The CRS information will be placed in Variable Length Records or Extended Variable Length Records... The CRS is represented by either GeoTIFF or Well Know [sic] Text as indicated by the WKT Global Encoding bit. Point Record Formats 0-5 can use either GeoTIFF or WKT (but not both simultaneously). Point Record Formats 6-10 must use WKT.

Therefore, I would suggest that case (b) that Martin proposed should be considered invalid. Including both GeoTIFF and WKT VLRs would be invalid by virtue of this discussion. Since we are saying that an empty or "n/a" payload has a valid use case, including both could be construed as using both simultaneously, which is expressly forbidden.

Evon

[Martin Isenburg]

Evon,

GeoTIFF tags are very widely supported. Omitting them and storing only WKT in the VLRs only because the specification states it is invalid (does it? i think it does not!) to provide the CRS info in two different ways would seem silly. Because it would  mean in practise that more often than needed there is some software does not manage to parse the (otherwise available) projection information from a LAS or LAZ file made to conform to an overly strict spec ...

Martin

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

[Evon Silvia]

Martin,

Good points. I don't dispute how widely supported the GeoTIFF CRS is. The validator's concern, though, should be whether or not the spec allows both to be defined. Apparently, you think it does. I think it does not. Whether or not that's too strict is a legitimate discussion for the ASPRS LWG.

In my opinion, including both introduces the possibility of conflicts between the definitions and leaves it up to the programmer which definition to use. Given the option, I would imagine that most software would simply keep using the GeoTIFF definition and ignore the WKT definitions since, as you observed, they are so widely supported.

For example, all the time I see LAS 1.2 files encoded as simply UTM10, NAD83 when what they really mean is UTM10, NAD83(2011) for the simple reason that their software doesn't recognize the EPSG codes for the NAD83(2011) realizations. If the files are defined as UTM10 NAD83 (no vertical) in GeoTIFF and UTM10 NAD83(2011) + NAVD88 in WKT, there's an inherent ambiguity.

I can see good reasons to go either way. You asked for comments, so you have my $0.02. :-)

Evon

[Martin Isenburg]

Hello Evon,

at the time when the LASvalidator was contracted out by the ASPRS (and I won the bid) it was specified that the validator should check that the following is true or the CRS handling in LAS 1.4 files

(a) there must be a CRS 

(b) can be there as both GeoTIFF tags and OGC WKT 

(c) but requires to be OGC WKT for the newer point types (6 and up)

(d) in case both are there they should be identical

option (d) is the hardest to check for *all* cases but we can probably cover the most common 98% with relative ease.

A large number of LAS / LAZ tiles on the Web do not seems to have any CRS info. In particular those using the Terrasolid software seem to have a hard time to correctly add and populate the "LASF_Projection" VLR(s). Hence I do not want to be too strict with those using GeoTIFF only. The GeoTIFF tags versus OGC WKT strings is still the smallest of my everyday issues when it comes to geo-referencing ... (-:

Martin

--

[Martin Isenburg]

Hello,

the LASvalidator has been updated to allow the "intentional lack of a CRS" in the OGC WKT as suggested by Guillaume from Trimble. Guillaume, maybe you could check whether lasvalidate.exe now has the desired behaviour. This version of lasvalidate is also included in the latest release of LAStools from two days ago (150803).

Regards,

Martin @rapidlasso

[Guillaume Tremblay]

Hi all,

Latest lasvalidate.exe has the expected behavior for the new LAS 1.4 files created from TRW: a warning saying "Coordinate Reference System was intentionally not specified (according to the empty OGC WKT)". Then empty payload is actually an empty string in the WKT text field.

Thank you Martin for this update.

Guillaume