Minimum WKT string for LAS 1.4 files

[Loren Dawe]

I am programming LAS 1.4 support into some in-house software and am wondering what are the minimum fields required in the WKT string so that it will be considered a valid CRS. With LAS 1.0-1.3 geoTiff tags I used EPSG codes to produce a fairly generalized CRS and am hoping that I can do the same with WKT using something like the following string:

PROJCS["EPSG:2270", AUTHORITY["EPSG","2270"]]

Would the above string be valid? If not, could someone point me to some documentation that describes minimum required PROJCS fields? I have looked through "12-063r5_CRS_Well-known_Text.pdf" and "01-009_OpenGIS_Implementation_Specification_Coordinate_Transformation_Services_Revision_1.00.pdf" but couldnt find such a section.

Thanks in Advance,
Loren.

[Martin Isenburg]

Hello,

I'm not the authority on that but I am tempted to say yes (please). At the moment the EPSG code is mainly what LAStools is trying to parse from the OCG WKT string for most horizontal CRS this gives a robust and unique specification.

Regards,

Martin

--
--
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gottfried Mandlburger]

Loren, Martin,

My understanding of the OGC CT Services WKT specification is that the
authority names and codes (first of all EPSG and the corresponding EPSG
codes) are only intended as meta data. They are definitely not an
integral part of the WKT string. The following python code example using
the Spatial Reference Classes of the GDAL library illustrates that:

---
from osgeo import osr, ogr

# load from EPSG code
srs=osr.SpatialReference()
srs.ImportFromEPSG(2270)
res = srs.Validate() #returns 0 = OGRERR_NONE
wkt = srs.ExportToWkt()

# load from full WKT string
srs.ImportFromWkt(wkt)
res = srs.Validate() #returns 0 = OGRERR_NONE

# load from WKT string omitting Authority info
srs.ImportFromWkt('PROJCS["NAD83 / Oregon South
(ft)",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS
1980",6378137,298.257222101],TOWGS84[0,0,0,0,0,0,0]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",44],PARAMETER["standard_parallel_2",42.33333333333334],PARAMETER["latitude_of_origin",41.66666666666666],PARAMETER["central_meridian",-120.5],PARAMETER["false_easting",4921259.843],PARAMETER["false_northing",0],UNIT["foot",0.3048],AXIS["X",EAST],AXIS["Y",NORTH]]')
res = srs.Validate() #returns 0 = OGRERR_NONE

# load from WKT string stub
srs.ImportFromWkt('PROJCS["EPSG:2270", AUTHORITY["EPSG","2270"]]')
res = srs.Validate() #returns 5 = OGRERR_CORRUPT_DATA
---

Thus, from the OGC standard perspective your stub WKT string is not
valid. I would suggest to use GDAL or any library with EPSG support to
construct the WKT string from the EPSG code.

@Martin: Would it be good idea to suggest direct EPSG support for LAS?

Kind regards,
Gottfried

--
#Dr. Gottfried Mandlburger

Tel.: +43 1 58801 12235
Fax.: +43 1 58801 12299
http://www.ipf.tuwien.ac.at
_____ _____ _____
/____// ___// / TU Vienna
// __ / /__ / // / Department of Geodesy and Geoinformation
//__/// /__ / // / Research Group Photogrammetry
/____//____//____/ Gusshausstrasse 27-29, A-1040 Vienna

On 13.10.2017 05:08, Martin Isenburg wrote:
> Hello,
>
> I'm not the authority on that but I am tempted to say yes (please). At
> the moment the EPSG code is mainly what LAStools is trying to parse from
> the OCG WKT string for most horizontal CRS this gives a robust and
> unique specification.
>
> Regards,
>
> Martin
>
> On Oct 12, 2017 2:27 AM, "Loren Dawe" <loren...@shaw.ca

> <mailto:loren...@shaw.ca>> wrote:
>
> I am programming LAS 1.4 support into some in-house software and am
> wondering what are the minimum fields required in the WKT string so
> that it will be considered a valid CRS. With LAS 1.0-1.3 geoTiff
> tags I used EPSG codes to produce a fairly generalized CRS and am
> hoping that I can do the same with WKT using something like the
> following string:
>
> PROJCS["EPSG:2270", AUTHORITY["EPSG","2270"]]
>
> Would the above string be valid? If not, could someone point me to
> some documentation that describes minimum required PROJCS fields? I
> have looked through "12-063r5_CRS_Well-known_Text.pdf" and
> "01-009_OpenGIS_Implementation_Specification_Coordinate_Transformation_Services_Revision_1.00.pdf"
> but couldnt find such a section.
>
> Thanks in Advance,
> Loren.
>
> --
> --
> 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
> <http://groups.google.com/group/lasroom>
> Post to this group with an email to las...@googlegroups.com

> <mailto:las...@googlegroups.com>
> Unsubscribe by email to lasroom+u...@googlegroups.com
> <mailto:lasroom%2Bunsu...@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
> <mailto:lasroom+u...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> --
> 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
> <mailto:lasroom+u...@googlegroups.com>.

[Terry Dotson]

On Wednesday, October 11, 2017 at 4:57:38 PM UTC-4, Loren Dawe wrote:

 

I used EPSG codes to produce a fairly generalized CRS ...

We would also like to see a standardized field for EPSG code in LAS/LAZ files.  If there was an integer field that was non-zero it could represent the EPSG code, a default of zero means it's absent.  The ability to obtain a quick EPSG would mean not having to parse WKT content, especially for those of us that do not use GDAL.

[Howard Butler]

> On Oct 13, 2017, at 3:54 AM, Gottfried Mandlburger <gottfried....@geo.tuwien.ac.at> wrote:
>
> # load from WKT string stub
> srs.ImportFromWkt('PROJCS["EPSG:2270", AUTHORITY["EPSG","2270"]]')
> res = srs.Validate() #returns 5 = OGRERR_CORRUPT_DATA
> ---
>
> Thus, from the OGC standard perspective your stub WKT string is not valid. I would suggest to use GDAL or any library with EPSG support to construct the WKT string from the EPSG code.

This doesn't look valid. You might try another parser besides GDAL for independent confirmation.

> @Martin: Would it be good idea to suggest direct EPSG support for LAS?

Not every coordinate system is represented by EPSG, and EPSG definitions have epoch considerations. EPSG codes alone were not sufficient to improve LAS' situation over the GeoTIFF SRS representation it previously used. WKT is the least-worst approach available with the most coordinate system definition coverage, which is why the LAS specification went with it going forward.

If there's to be another revision of the LAS specification, I think the committee should consider OGC's WKT2, and it should have a discussion about datum time realizations. The latter topic isn't well covered, but it is a significant challenge lidar now that we are starting to capture things more than one time and want to mix data together more completely.

Howard

[Loren Dawe]

Thanks everyone for your comments. Im going to try to integrate the GDAL objects into my applications (thanks Gottfried for the code sample), if that doesn't work I'll just hard wire the common projections we use and come up with some other method for those not so common.

Martin - could you supply more specific info on how lasvalidate decides weather a WKT string is valid or not?
I currently get two CRS warnings on the same LAS file:

    1) <CRS>not valid or not specified</CRS>
    2) <note>there is a OGC WKT string but its check is not yet implemented</note>

On Thursday, October 12, 2017 at 8:09:04 PM UTC-7, Martin Isenburg wrote:

Hello,

I'm not the authority on that but I am tempted to say yes (please). At the moment the EPSG code is mainly what LAStools is trying to parse from the OCG WKT string for most horizontal CRS this gives a robust and unique specification.

Regards,

Martin

On Oct 12, 2017 2:27 AM, "Loren Dawe" <loren...@shaw.ca> wrote:

I am programming LAS 1.4 support into some in-house software and am wondering what are the minimum fields required in the WKT string so that it will be considered a valid CRS. With LAS 1.0-1.3 geoTiff tags I used EPSG codes to produce a fairly generalized CRS and am hoping that I can do the same with WKT using something like the following string:

PROJCS["EPSG:2270", AUTHORITY["EPSG","2270"]]

Would the above string be valid? If not, could someone point me to some documentation that describes minimum required PROJCS fields? I have looked through "12-063r5_CRS_Well-known_Text.pdf" and "01-009_OpenGIS_Implementation_Specification_Coordinate_Transformation_Services_Revision_1.00.pdf" but couldnt find such a section.

Thanks in Advance,
Loren.

--
--
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.

[Martin Isenburg]

Hello,

lasvalidate does not attempt to parse and validate the CRS at the moment. It merely checks presence of a GeoTiff tag or a OGK WKT string. The lasvalidator was part of our bit for the ASPRS tender to create a LAS validation tool for the LAS format. While the bid of my little company, rapidlasso GmbH, was initially awarded by the ASPRS. this project was later cancelled again. As I had already started implementing a prototype for the LVS (LAS Validation Suite) I decided to turn what I had already implemente into an open source LAS validator. See these discussion threads for some history:

http://groups.google.com/d/topic/lastools/PMHT3q_rygc/discussion

http://groups.google.com/d/topic/lastools/_jB7ohdreqA/discussion

Implementing a full fledged CRS checking is not a trivial task so once the awarded bid was retracted we focused to complete the easier-to-accomplish tasks of validating a LAS file (but not the CRS).

Regards,

Martin @rapidlasso 

Unsubscribe by email to lasroom+unsubscribe@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+unsubscribe@googlegroups.com.

[Loren Dawe]

After downloading and reviewing the latest GDAL code, It looks like GDAL is using various out-of-date and incomplete text files (found in gdal-data folder) to build it's WKT strings (regardless if the source is from an EPSG code or not).

For this reason I am not going to use the GDAL library and have decided to develop a method using the EPSG dataset which is far more complete and is updated on a regular basis ( currently v9.2 released Oct 16 2017)/

Depending on my success I may publish my methods/source here so that others do not have to go through the same effort. If anyone comes up with or finds an existing method to create LAS WKT strings please let me know.

--------------------------------------------------------------------------------------------------------------------

[Loren Dawe]

Hi Martin,
Could I then request a message change for the next release of lasvalidate? Specifically please omit the message "<CRS>not valid or not specified</CRS>"  for those LAS 1.4 files that DO have a WKT CRS. The second message "there is a OGC WKT string but its check is not yet implemented" is more appropriate. Many of our clients rely on lasvalidate to QC our delivered data and when they see "not valid or not specified" they may question or even revoke our data based on the lasvalidate report.
Thanks, Loren.

[Wes Toews]

For fun, there would be a few simple methods to get WKT strings from EPSG without having to integrate GDAL into code.

1) Use the gdalsrsinfo utility as a process (gdalsrsinfo -o wkt EPSG:25832)

2) Create a lookup from the PostGIS database, even just export that to a semicolon-delimited file (select * from spatial_ref_sys, export to file).

3) For probably the most current sources, make a web request to spatialreference.org (http://spatialreference.org/ref/epsg/25832/ogcwkt/) or epsg.io (http://epsg.io/25832.wkt), so in naive python3 this looks like

srs_content=urllib.request.urlopen(whatever_epsg_src_url).read().decode('utf-8').

or use libcurl or whatever in C/C++.

Note that from the official online EPSG registry you can do the same thing but will get you content from the updated WKT spec which doesn't necessarily meet the LAS 1.4 spec (asks for rev1.00 2001), which somehow we haven't heard too much about here.

Wes

[Loren Dawe]

Thanks Wes!

This is perfect!
I will be using method 2 which creates an ascii look-up table similar to the incomplete/out-of-date support files that GDAL uses. If any readers of this post are involved with GDAL development, perhaps they could suggest this as an update for GDAL's methods as well and we can all be on the same page.

I have attached the PostgreSQL extract text file to this message for any who would like to use method 2.

Loren.

[Loren Dawe]

I have opened an enhancement request on the GDAL wiki and uploaded the ascii look up table. We may see this in GDAL soon.

[Loren Dawe]

I have just received a reply from Even Rouault (GDAL commiter and PSC chair), who has clarified a few things regarding the GDAL WKT strings; it turns out that the spatial_ref_sys table I referenced above and used for my ASCII look up table is actually generated by GDAL using the EPSG data. The ASCII files I thought were the entire GDAL WKT dataset are just supplemental files to add to the GDAL CRS dataset:

those files are just extra sources of CRS for GDAL. But from EPSG based CRS, the sources are in the .csv files (pcs.csv, gcs.csv, unit_of_measure.csv, prime_meridian.csv, ellipsoid.csv, coordinate_axis.csv, vertcs.csv, compdcs.csv, geoccs.csv, and their .override.csv variants) and they are used dynamically by the importFromEPSG() file to reconstruct the WKT string. So there's no text file in GDAL data with a dump of the WKT strings from EPSG, as this is done each time importFromEPSG() is invoked.

Thanks to Even for his quick response. There is an open ticket to update GDAL with EPSG v9.2 from v9.0 so we should see the most current WKT strings in GDAL in a future release.

So in conclusion, developers can use any of the three methods described by Wes Toews above and be confident that the WKT strings generated are complete and derived from the same EPSG source.