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."
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 iPadOn 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--
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 0user ID 'LASF_Projection'record ID 34735length after header 136description 'GeoTIFF GeoKeyDirectoryTag'GeoKeyDirectoryTag version 1.1.0 number of keys 16key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjectedkey 1025 tiff_tag_location 0 count 1 value_offset 1 - GTRasterTypeGeoKey: RasterPixelIsAreakey 1026 tiff_tag_location 34737 count 27 value_offset 0 - GTCitationGeoKey: NAD83(CSRS) / UTM zone 20Nkey 2048 tiff_tag_location 0 count 1 value_offset 4140 - GeographicTypeGeoKey: look-up for 4140 not implementedkey 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 implementedkey 2052 tiff_tag_location 0 count 1 value_offset 9001 - GeogLinearUnitsGeoKey: Linear_Meterkey 2054 tiff_tag_location 0 count 1 value_offset 9102 - GeogAngularUnitsGeoKey: Angular_Degreekey 2056 tiff_tag_location 0 count 1 value_offset 7019 - GeogEllipsoidGeoKey: Ellipse_GRS_1980key 2057 tiff_tag_location 34736 count 1 value_offset 1 - GeogSemiMajorAxisGeoKey: 6378137key 2058 tiff_tag_location 34736 count 1 value_offset 2 - GeogSemiMinorAxisGeoKey: 6356752.314key 2059 tiff_tag_location 34736 count 1 value_offset 0 - GeogInvFlatteningGeoKey: 298.2572221key 3072 tiff_tag_location 0 count 1 value_offset 2961 - ProjectedCSTypeGeoKey: NAD83(CSRS) / UTM zone 20Nkey 3073 tiff_tag_location 34737 count 27 value_offset 41 - PCSCitationGeoKey: NAD83(CSRS) / UTM zone 20Nkey 3074 tiff_tag_location 0 count 1 value_offset 16020 - ProjectionGeoKey: look-up for 16020 not implementedkey 3076 tiff_tag_location 0 count 1 value_offset 9001 - ProjLinearUnitsGeoKey: Linear_MeterRegards 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
--
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
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.
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.
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