Re: [LAStools] EPSG code 6140 for NAD83/CSRS GeogGeodeticDatumGeoKey?

293 views
Skip to first unread message

Martin Isenburg

unread,
Jan 4, 2017, 5:45:18 PM1/4/17
to LAStools - efficient command line tools for LIDAR processing
Hello Michael,

folks working for your government have told be the following:

"EPSG 6140 is the code for the NAD83/CSRS datum: https://epsg.io/6140-datum. It is a replacement of the previous NAD83 datum for Canadian region.

 

Most of the Canadian projections we are now using are defined according to this new datum. It would be nice if you could support it natively in LAStools.

 

Regarding 4140, it seems to be a deprecated code https://epsg.io/4140 that we are still using. It was the former reference to the Geodetic CRS under some early adopted NAD83/CSRS projections. I will make sure we update such definitions in our processes. The new value should be 4617."


Usually I try to support all the datum that are listed in the 'gcs.csv' file of GDAL that you can find here:


and this lists these two datums for Canada:

4140,"NAD83(CSRS98)",6140,NAD83 Canadian Spatial Reference System,6140,9108,7019,8901,1,1,6402,1473,0,9603,0,0,0,,,,

4617,"NAD83(CSRS)",6140,NAD83 Canadian Spatial Reference System,6140,9122,7019,8901,1,0,6422,1842,1,9603,0,0,0,,,,

I guess once I support those two all should be good - at least for the troublesome file that I had received that gives me this projection in the lasinfo report.

[...]
variable length header record 1 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34735
  length after header  136
  description          'GeoTIFF GeoKeyDirectoryTag'
    GeoKeyDirectoryTag version 1.1.0 number of keys 16
      key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
      key 1025 tiff_tag_location 0 count 1 value_offset 1 - GTRasterTypeGeoKey: RasterPixelIsArea
      key 1026 tiff_tag_location 34737 count 27 value_offset 0 - GTCitationGeoKey: NAD83(CSRS) / UTM zone 20N
      key 2048 tiff_tag_location 0 count 1 value_offset 4140 - GeographicTypeGeoKey: look-up for 4140 not implemented
      key 2049 tiff_tag_location 34737 count 14 value_offset 27 - GeogCitationGeoKey: NAD83(CSRS98)
      key 2050 tiff_tag_location 0 count 1 value_offset 6140 - GeogGeodeticDatumGeoKey: look-up for 6140 not implemented
      key 2052 tiff_tag_location 0 count 1 value_offset 9001 - GeogLinearUnitsGeoKey: Linear_Meter
      key 2054 tiff_tag_location 0 count 1 value_offset 9102 - GeogAngularUnitsGeoKey: Angular_Degree
      key 2056 tiff_tag_location 0 count 1 value_offset 7019 - GeogEllipsoidGeoKey: Ellipse_GRS_1980
      key 2057 tiff_tag_location 34736 count 1 value_offset 1 - GeogSemiMajorAxisGeoKey: 6378137
      key 2058 tiff_tag_location 34736 count 1 value_offset 2 - GeogSemiMinorAxisGeoKey: 6356752.314
      key 2059 tiff_tag_location 34736 count 1 value_offset 0 - GeogInvFlatteningGeoKey: 298.2572221
      key 3072 tiff_tag_location 0 count 1 value_offset 2961 - ProjectedCSTypeGeoKey: NAD83(CSRS) / UTM zone 20N
      key 3073 tiff_tag_location 34737 count 27 value_offset 41 - PCSCitationGeoKey: NAD83(CSRS) / UTM zone 20N
      key 3074 tiff_tag_location 0 count 1 value_offset 16020 - ProjectionGeoKey: look-up for 16020 not implemented
      key 3076 tiff_tag_location 0 count 1 value_offset 9001 - ProjLinearUnitsGeoKey: Linear_Meter
variable length header record 2 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34736
  length after header  24
  description          'GeoTIFF GeoDoubleParamsTag'
    GeoDoubleParamsTag (number of doubles 3)
      298.257 6.37814e+006 6.35675e+006
variable length header record 3 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34737
  length after header  69
  description          'GeoTIFF GeoAsciiParamsTag'
    GeoAsciiParamsTag (number of characters 69)
      NAD83(CSRS) / UTM zone 20N|NAD83(CSRS98)|NAD83(CSRS) / UTM zone 20N|
[...]

The two red lines would be solved with the only remaining offender being the line marked in violet. What is that for anyways? Anyone knows how I can (correctly) add the value for 16020 to lasinfo?

Martin

On Tue, Dec 6, 2016 at 7:32 AM, Michael Perdue <michael...@gmail.com> wrote:

Hello,

A quick word of discretion for users of epsg NAD83CSRS codes…

IMHO the EPSG database has poor support for NAD83CSRS. The geodetic datum entry for 6140 explicitly defines the epoch of realization for this datum as 1998. The problem is that I don’t know of any official entities that use that realization. The most common realizations are epoch’s 1997, 2002 and 2010; none of which are found anywhere in the EPSG registry. Admittedly, the horizontal differences between these realizations are small and inconsequential for most users, but the vertical component can be meaningful as some parts of Canada are experiencing significant post-glacial rebound (Hudson Bay) and/or tectonic upheaval (St. Elias range). Since the new vertical datum (CGVD2013) is a gravimetric datum rather than being based on a levelling network (CGVD28), the epoch of realization becomes important. In some regions, the vertical difference between the 1997 and 2010 epochs is > 15cm.

This makes the SRS ambiguous whenever NAD83(CSRS) is referenced. You also need the epoch of realization in order to remove the ambiguity. Unfortunately, I don’t know of a better option. The situation is even worse for WGS84, which has at least 6 different realizations that I'm aware of, but uses the same geodetic datum entry for all (6326).

 Cheers,

 Mike




Sent from my iPad
On Mon, Dec 5, 2016 at 11:24 AM, Evon Silvia <esi...@quantumspatial.com> wrote:
According to the EPSG registry, EPSG code 6140 is the NAD83 Geodetic Datum (GeogGeodeticDatumGeoKey) as implemented in Canada and known as NAD83(CSRS).

Its derivative geographic coordinate systems are 4617 (2D) and 4955 (3D).

Using 4617 as the base, the derivative projected UTM coordinate systems in Canada are 3154-3157 (UTM7-10N), 2955-2957 (UTM11-13N), 3158-3160 (UTM14-16N), 2958-2962 (UTM17-21N), 3761 (UTM22N).

There's more than just that, but that should about cover it for most people. CompoundCRS definitions with CGVD2013 also exist.

Evon
--
Quantum Geospatial Logo
Evon Silvia PLS
Solutions Developer
517 SW 2nd Street, Suite 400, Corvallis, OR 97333
P: (541) 452-8502



On Mon, Dec 5, 2016 at 7:05 AM, Martin Isenburg <martin....@gmail.com> wrote:
Hello,

Hello,

a client is requesting for LAStools to support one seemingly missing value for the GeoTIFF tag GeogGeodeticDatumGeoKey that is currently not implemented. Here is the "meaning" of GeographicTypeGeoKey.


The value 6140 seems to refer to a Datum that is Ellispoid only in the definition files and therefore not listed.

What are the correct codes for the NAD83 (CSRS) datum? It seems the listed GeoTIFF codes do not cover the current values and do not have an entry for NAD83 (CSRS). Is it different from NAD 83? The client states that EPSG 6140 is the code for the NAD83/CSRS datum according to https://epsg.io/6140-datum and it is a replacement of the previous NAD83 datum for Canadian region.

Here is what lasinfo currently reports:

variable length header record 1 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34735
  length after header  136
  description          'GeoTIFF GeoKeyDirectoryTag'
    GeoKeyDirectoryTag version 1.1.0 number of keys 16
      key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
      key 1025 tiff_tag_location 0 count 1 value_offset 1 - GTRasterTypeGeoKey: RasterPixelIsArea
      key 1026 tiff_tag_location 34737 count 27 value_offset 0 - GTCitationGeoKey: NAD83(CSRS) / UTM zone 20N
      key 2048 tiff_tag_location 0 count 1 value_offset 4140 - GeographicTypeGeoKey: look-up for 4140 not implemented
      key 2049 tiff_tag_location 34737 count 14 value_offset 27 - GeogCitationGeoKey: NAD83(CSRS98)
      key 2050 tiff_tag_location 0 count 1 value_offset 6140 - GeogGeodeticDatumGeoKey: look-up for 6140 not implemented
      key 2052 tiff_tag_location 0 count 1 value_offset 9001 - GeogLinearUnitsGeoKey: Linear_Meter
      key 2054 tiff_tag_location 0 count 1 value_offset 9102 - GeogAngularUnitsGeoKey: Angular_Degree
      key 2056 tiff_tag_location 0 count 1 value_offset 7019 - GeogEllipsoidGeoKey: Ellipse_GRS_1980
      key 2057 tiff_tag_location 34736 count 1 value_offset 1 - GeogSemiMajorAxisGeoKey: 6378137
      key 2058 tiff_tag_location 34736 count 1 value_offset 2 - GeogSemiMinorAxisGeoKey: 6356752.314
      key 2059 tiff_tag_location 34736 count 1 value_offset 0 - GeogInvFlatteningGeoKey: 298.2572221
      key 3072 tiff_tag_location 0 count 1 value_offset 2961 - ProjectedCSTypeGeoKey: NAD83(CSRS) / UTM zone 20N
      key 3073 tiff_tag_location 34737 count 27 value_offset 41 - PCSCitationGeoKey: NAD83(CSRS) / UTM zone 20N
      key 3074 tiff_tag_location 0 count 1 value_offset 16020 - ProjectionGeoKey: look-up for 16020 not implemented
      key 3076 tiff_tag_location 0 count 1 value_offset 9001 - ProjLinearUnitsGeoKey: Linear_Meter

Regards from Costa Rica,

Martin @rapidlasso

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

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


Perdue, Michael

unread,
Jan 16, 2017, 4:14:18 AM1/16/17
to last...@googlegroups.com

Hi Martin,

 

WRT EPSG 6140… What the folks from my government have stated is partly true; 6140 is the code for one of the NAD83CSRS datum. The problem is that, like in the US with the NSRS, NAD83CSRS has multiple realizations. Consider the geodetic control monument below.

 

If a LiDAR survey were differentially tied to these coordinates and output in utm17, then the proper EPSG code would be 2958. This uses a base geodetic CRS of 4617 and references the datum 6140. All is good up to now.

cid:image002.png@01D26D97.9DF90E40

 

My question is what do I do if my survey is tied to the coordinates below? This is the exact same station (963010). However, after 13 years of time, we know that this station has risen by ~12.1cm (plus a 2.3cm*2.0cm horizontal shift) due to glacial rebound and new coordinates were published in the 2010 realization of the datum. If we assume that the epsg code 6140 is targeted towards the 1997 realization, then there are no entries in the epsg database to differentiate this datum.

cid:image003.png@01D26D97.9DF90E40

 

All of the NAD83 coordinate systems that we refer to as datums (NAD83 original,  HARN, CORS96, NAD83(2011), NAD83CSRS(2010), etc) are technically the same datum. IE, they all share the same ellipsoid, origin, orientation and scale. Where they differ is in the realization of the coordinates on the ground. So NAD83CSRS(1997) and NAD83CSRS(2010) are different realizations of the same datum and the biggest difference between them is due to tectonic motions.

 

The  Canadian Spatial Reference System (CSRS) and the National Spatial Reference System (NSRS) are intentionally aligned. As a result, there should be a high level of consistency between the following datums.

NAD83(CORS96) ~= NAD83CSRS (1997)

NAD83(NSRS2007) ~= NAD83CSRS (2002)

NAD83(2011) ~= NAD83CSRS (2010)

On the US side, there are epsg entries for CORS96, NSRS2007 and NAD83(2011), but on the Canadian side, there is only one entry for NAD83CSRS. Due to the epoch of realization listed in the EPSG, I understand this to mean that epsg:6140 represents NAD83CSRS(1997).

 

This is why I feel the use of epsg 6140 results in ambiguity. Until there is a mechanism to properly differentiate the different realizations , there will continue to be ambiguity in la[sz] files that use this datum definition as a reference.

 

I don’t see this as something that LAStools can/should fix. IMHO, I believe that two new datums need to be submitted to the EPSG for inclusion and then all the relevant CRS need to be built to support the other two epochs in common use (2002 & 2010). To be absolutely correct, a correction also needs to be submitted for datum 6140. It currently states that the epoch of realization is 1998-01-01, which is erroneous IMHO. It should be 1997-01-01 (looking through the epsg, it seems that this field is being populated in a very in-consistent manner for the US datums as well).

 

I’m fine with making the submissions for the corrections and new datum realizations. I have started exploring what I need to do to make it happen. The issue that I have is the marriage of datums to projections to create CRS in the EPSG means that you have to create a submission for every permutation of datum/projection that you want supported. That means that there are 54 pages of submissions, just to cover the 27 projections that we commonly use in house… ugh.

 

Cheers,

 

Mike

Reply all
Reply to author
Forward
0 new messages