[GRASS-dev] Different CRS matching in 7.2 and trunk

GRASS GRASS developer
1

Hi all,

I’m trying to understand a change of behavior between 7.2 and trunk. With 7.2, I can do the following:

curl -SL http://fatra.cnr.ncsu.edu/foss4g2017/nc_tile_0793_016_spm.zip \

nc_tile_0793_016_spm.zip && unzip nc_tile_0793_016_spm.zip

grass72 -c EPSG:3358 ~/grassdata/crs_test -e
grass72 ~/grassdata/crs_test2/PERMANENT/ --exec r.in.lidar input=nc_tile_0793_016_spm.las output=count_10 method=n -e -n resolution=10

The last step (r.in.lidar) fails in current trunk because the projection don’t match. Here is the difference (name, datum and swapped lat_1 and lat_2):

GRASS LOCATION PROJ_INFO is:
name: NAD83(HARN) / North Carolina
datum: nad83harn
lat_1: 36.16666666666666
lat_2: 34.33333333333334

Import dataset PROJ_INFO is:
name: NAD_1983_StatePlane_North_Carolina_FIPS_3200
datum: nad83
lat_1: 34.33333333333334
lat_2: 36.16666666666666

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

Here is the lasinfo reference:

PROJCS[“NAD_1983_StatePlane_North_Carolina_FIPS_3200”,
GEOGCS[“GCS_North_American_1983”,
DATUM[“North_American_Datum_1983”,
SPHEROID[“GRS_1980”,6378137,298.257222101]],
PRIMEM[“Greenwich”,0],
UNIT[“Degree”,0.0174532925199432955]],
PROJECTION[“Lambert_Conformal_Conic_2SP”],
PARAMETER[“False_Easting”,609601.22],
PARAMETER[“False_Northing”,0],
PARAMETER[“Central_Meridian”,-79],
PARAMETER[“Standard_Parallel_1”,34.33333333333334],
PARAMETER[“Standard_Parallel_2”,36.16666666666666],
PARAMETER[“Latitude_Of_Origin”,33.75],
UNIT[“Meter”,1]]

r.in.lidar -p in both 7.2 and trunk gives:

+proj=lcc +lat_1=34.33333333333334 +lat_2=36.16666666666666 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +datum=NAD83 +units=m +no_defs

g.proj -p gives the following in 7.2 and trunk in locations created by 7.2 and trunk:

-PROJ_INFO-------------------------------------------------
name : NAD83(HARN) / North Carolina
datum : nad83harn
ellps : grs80
proj : lcc
lat_1 : 36.16666666666666
lat_2 : 34.33333333333334
lat_0 : 33.75
lon_0 : -79
x_0 : 609601.22
y_0 : 0
no_defs : defined
-PROJ_EPSG-------------------------------------------------
epsg : 3358
-PROJ_UNITS------------------------------------------------
unit : meter
units : meters
meters : 1

I don’t know how to resolve it besides using -o but I don’t know how to justify it and why there is a difference (I don’t see it in the recent proj-related commits).

Thank you,
Vaclav

2

On Fri, Nov 10, 2017 at 6:08 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

Hi all,

I’m trying to understand a change of behavior between 7.2 and trunk. With 7.2, I can do the following:

curl -SL http://fatra.cnr.ncsu.edu/foss4g2017/nc_tile_0793_016_spm.zip \

nc_tile_0793_016_spm.zip && unzip nc_tile_0793_016_spm.zip

grass72 -c EPSG:3358 ~/grassdata/crs_test -e
grass72 ~/grassdata/crs_test2/PERMANENT/ --exec r.in.lidar input=nc_tile_0793_016_spm.las output=count_10 method=n -e -n resolution=10

The last step (r.in.lidar) fails in current trunk because the projection don’t match. Here is the difference (name, datum and swapped lat_1 and lat_2):

GRASS LOCATION PROJ_INFO is:
name: NAD83(HARN) / North Carolina
datum: nad83harn
lat_1: 36.16666666666666
lat_2: 34.33333333333334

Import dataset PROJ_INFO is:
name: NAD_1983_StatePlane_North_Carolina_FIPS_3200
datum: nad83
lat_1: 34.33333333333334
lat_2: 36.16666666666666

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. projections would be regarded as matching even with e.g. nad27 and nad83.

The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Markus M

Here is the lasinfo reference:

PROJCS[“NAD_1983_StatePlane_North_Carolina_FIPS_3200”,
GEOGCS[“GCS_North_American_1983”,
DATUM[“North_American_Datum_1983”,
SPHEROID[“GRS_1980”,6378137,298.257222101]],
PRIMEM[“Greenwich”,0],
UNIT[“Degree”,0.0174532925199432955]],
PROJECTION[“Lambert_Conformal_Conic_2SP”],
PARAMETER[“False_Easting”,609601.22],
PARAMETER[“False_Northing”,0],
PARAMETER[“Central_Meridian”,-79],
PARAMETER[“Standard_Parallel_1”,34.33333333333334],
PARAMETER[“Standard_Parallel_2”,36.16666666666666],
PARAMETER[“Latitude_Of_Origin”,33.75],
UNIT[“Meter”,1]]

r.in.lidar -p in both 7.2 and trunk gives:

+proj=lcc +lat_1=34.33333333333334 +lat_2=36.16666666666666 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +datum=NAD83 +units=m +no_defs

g.proj -p gives the following in 7.2 and trunk in locations created by 7.2 and trunk:

-PROJ_INFO-------------------------------------------------
name : NAD83(HARN) / North Carolina
datum : nad83harn
ellps : grs80
proj : lcc
lat_1 : 36.16666666666666
lat_2 : 34.33333333333334
lat_0 : 33.75
lon_0 : -79
x_0 : 609601.22
y_0 : 0
no_defs : defined
-PROJ_EPSG-------------------------------------------------
epsg : 3358
-PROJ_UNITS------------------------------------------------
unit : meter
units : meters
meters : 1

I don’t know how to resolve it besides using -o but I don’t know how to justify it and why there is a difference (I don’t see it in the recent proj-related commits).

Thank you,
Vaclav

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

3

On Fri, Nov 10, 2017 at 6:43 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Fri, Nov 10, 2017 at 6:08 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

Hi all,

I’m trying to understand a change of behavior between 7.2 and trunk. With 7.2, I can do the following:

curl -SL http://fatra.cnr.ncsu.edu/foss4g2017/nc_tile_0793_016_spm.zip \

nc_tile_0793_016_spm.zip && unzip nc_tile_0793_016_spm.zip

grass72 -c EPSG:3358 ~/grassdata/crs_test -e
grass72 ~/grassdata/crs_test2/PERMANENT/ --exec r.in.lidar input=nc_tile_0793_016_spm.las output=count_10 method=n -e -n resolution=10

The last step (r.in.lidar) fails in current trunk because the projection don’t match. Here is the difference (name, datum and swapped lat_1 and lat_2):

GRASS LOCATION PROJ_INFO is:
name: NAD83(HARN) / North Carolina
datum: nad83harn
lat_1: 36.16666666666666
lat_2: 34.33333333333334

Import dataset PROJ_INFO is:
name: NAD_1983_StatePlane_North_Carolina_FIPS_3200
datum: nad83
lat_1: 34.33333333333334
lat_2: 36.16666666666666

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. projections would be regarded as matching even with e.g. nad27 and nad83.
The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Fixed in trunk r71656.

The test for different datum names has been disabled again in trunk r71657. There are several different datum names in lib/gis/datum.table that apparently mean the same: same ellipsoid and same transformation parameters. Apparently, GRASS does not provide a datum name when converting projection information from GRASS to proj4 for reprojecting data.

Markus M

Here is the lasinfo reference:

PROJCS[“NAD_1983_StatePlane_North_Carolina_FIPS_3200”,
GEOGCS[“GCS_North_American_1983”,
DATUM[“North_American_Datum_1983”,
SPHEROID[“GRS_1980”,6378137,298.257222101]],
PRIMEM[“Greenwich”,0],
UNIT[“Degree”,0.0174532925199432955]],
PROJECTION[“Lambert_Conformal_Conic_2SP”],
PARAMETER[“False_Easting”,609601.22],
PARAMETER[“False_Northing”,0],
PARAMETER[“Central_Meridian”,-79],
PARAMETER[“Standard_Parallel_1”,34.33333333333334],
PARAMETER[“Standard_Parallel_2”,36.16666666666666],
PARAMETER[“Latitude_Of_Origin”,33.75],
UNIT[“Meter”,1]]

r.in.lidar -p in both 7.2 and trunk gives:

+proj=lcc +lat_1=34.33333333333334 +lat_2=36.16666666666666 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +datum=NAD83 +units=m +no_defs

g.proj -p gives the following in 7.2 and trunk in locations created by 7.2 and trunk:

-PROJ_INFO-------------------------------------------------
name : NAD83(HARN) / North Carolina
datum : nad83harn
ellps : grs80
proj : lcc
lat_1 : 36.16666666666666
lat_2 : 34.33333333333334
lat_0 : 33.75
lon_0 : -79
x_0 : 609601.22
y_0 : 0
no_defs : defined
-PROJ_EPSG-------------------------------------------------
epsg : 3358
-PROJ_UNITS------------------------------------------------
unit : meter
units : meters
meters : 1

I don’t know how to resolve it besides using -o but I don’t know how to justify it and why there is a difference (I don’t see it in the recent proj-related commits).

Thank you,
Vaclav

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

4

On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. projections would be regarded as matching even with e.g. nad27 and nad83.
The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Fixed in trunk r71656.

The test for different datum names has been disabled again in trunk r71657. There are several different datum names in lib/gis/datum.table that apparently mean the same: same ellipsoid and same transformation parameters. Apparently, GRASS does not provide a datum name when converting projection information from GRASS to proj4 for reprojecting data.

Thank you so much, Markus. This saves me a lot of trouble.

(I’m working on a Jupyter Notebook where I need trunk.)

https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS

Markus M

5

On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. projections would be regarded as matching even with e.g. nad27 and nad83.
The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Fixed in trunk r71656.

The test for different datum names has been disabled again in trunk r71657. There are several different datum names in lib/gis/datum.table that apparently mean the same: same ellipsoid and same transformation parameters. Apparently, GRASS does not provide a datum name when converting projection information from GRASS to proj4 for reprojecting data.

Thank you so much, Markus. This saves me a lot of trouble.

About avoiding trouble, the motivation of the stricter CRS comparison is to avoid subsequent geolocation errors. If data have been imported and differences in the CRS were not detected, it can become very difficult later on in the processing to figure out the reason for geolocation errors (different data not matching each other spatially). I’m not sure what to do about different datum names. The current check relies on the test for differences in ellipsoids.

Markus M

(I’m working on a Jupyter Notebook where I need trunk.)
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS

Markus M

6

Please note, that in spite of the fact that the datum.table shows same transformation parameters,
different nad83 datums are different (it is not just a different name for the same datum) and there are different EPSG codes associated
with the relevant CRS.
You can find more about it here (or just google it)
https://confluence.qps.nl/pages/viewpage.action?pageId=29855153

Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the NGS NADCON program (I have not checked it out)
(http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml).

Helena

On Nov 10, 2017, at 5:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz markus.metz.giswork@gmail.com wrote:

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. projections would be regarded as matching even with e.g. nad27 and nad83.
The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Fixed in trunk r71656.

The test for different datum names has been disabled again in trunk r71657. There are several different datum names in lib/gis/datum.table that apparently mean the same: same ellipsoid and same transformation parameters. Apparently, GRASS does not provide a datum name when converting projection information from GRASS to proj4 for reprojecting data.

Thank you so much, Markus. This saves me a lot of trouble.

About avoiding trouble, the motivation of the stricter CRS comparison is to avoid subsequent geolocation errors. If data have been imported and differences in the CRS were not detected, it can become very difficult later on in the processing to figure out the reason for geolocation errors (different data not matching each other spatially). I’m not sure what to do about different datum names. The current check relies on the test for differences in ellipsoids.

Markus M

(I’m working on a Jupyter Notebook where I need trunk.)
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS

Markus M

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

7

On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

Please note, that in spite of the fact that the datum.table shows same transformation parameters,
different nad83 datums are different (it is not just a different name for the same datum) and there are different EPSG codes associated
with the relevant CRS.
You can find more about it here (or just google it)
https://confluence.qps.nl/pages/viewpage.action?pageId=29855153

Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the NGS NADCON program (I have not checked it out)
(http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml).

There are 12 (!) different definitions for NAD83. What to do about this? Regard these 12 definitions as different datums? In this case I would need to reinstate the datum check and we need to add more entries to datum.table.

Markus M

Helena

On Nov 10, 2017, at 5:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. projections would be regarded as matching even with e.g. nad27 and nad83.
The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Fixed in trunk r71656.

The test for different datum names has been disabled again in trunk r71657. There are several different datum names in lib/gis/datum.table that apparently mean the same: same ellipsoid and same transformation parameters. Apparently, GRASS does not provide a datum name when converting projection information from GRASS to proj4 for reprojecting data.

Thank you so much, Markus. This saves me a lot of trouble.

About avoiding trouble, the motivation of the stricter CRS comparison is to avoid subsequent geolocation errors. If data have been imported and differences in the CRS were not detected, it can become very difficult later on in the processing to figure out the reason for geolocation errors (different data not matching each other spatially). I’m not sure what to do about different datum names. The current check relies on the test for differences in ellipsoids.

Markus M

(I’m working on a Jupyter Notebook where I need trunk.)
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS

Markus M

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

8

On Nov 10, 2017, at 7:20 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

Please note, that in spite of the fact that the datum.table shows same transformation parameters,
different nad83 datums are different (it is not just a different name for the same datum) and there are different EPSG codes associated
with the relevant CRS.
You can find more about it here (or just google it)
https://confluence.qps.nl/pages/viewpage.action?pageId=29855153

Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the NGS NADCON program (I have not checked it out)
(http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml).

There are 12 (!) different definitions for NAD83. What to do about this? Regard these 12 definitions as different datums? In this case I would need to reinstate the datum check and we need to add more entries to datum.table.

Markus, we absolutely need to have a datum check - although the differences between different NAD83 datums are less than a meter, differences between NAD27 and NAD83 are over hundred meters in some areas. Anything that has a different EPSG should be treated as different CRS exactly for the reasons you mentioned in your answer to Vasek.

Helena

Markus M

Helena

On Nov 10, 2017, at 5:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. projections would be regarded as matching even with e.g. nad27 and nad83.
The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Fixed in trunk r71656.

The test for different datum names has been disabled again in trunk r71657. There are several different datum names in lib/gis/datum.table that apparently mean the same: same ellipsoid and same transformation parameters. Apparently, GRASS does not provide a datum name when converting projection information from GRASS to proj4 for reprojecting data.

Thank you so much, Markus. This saves me a lot of trouble.

About avoiding trouble, the motivation of the stricter CRS comparison is to avoid subsequent geolocation errors. If data have been imported and differences in the CRS were not detected, it can become very difficult later on in the processing to figure out the reason for geolocation errors (different data not matching each other spatially). I’m not sure what to do about different datum names. The current check relies on the test for differences in ellipsoids.

Markus M

(I’m working on a Jupyter Notebook where I need trunk.)
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS

Markus M

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu

http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

9

On Sat, Nov 11, 2017 at 8:05 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

On Nov 10, 2017, at 7:20 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

Please note, that in spite of the fact that the datum.table shows same transformation parameters,
different nad83 datums are different (it is not just a different name for the same datum) and there are different EPSG codes associated
with the relevant CRS.
You can find more about it here (or just google it)
https://confluence.qps.nl/pages/viewpage.action?pageId=29855153

Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the NGS NADCON program (I have not checked it out)
(http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml).

There are 12 (!) different definitions for NAD83. What to do about this? Regard these 12 definitions as different datums? In this case I would need to reinstate the datum check and we need to add more entries to datum.table.

Markus, we absolutely need to have a datum check

This datum check has been first added in Oct 2003 and has been quickly removed again in Jan 2004. As long as we do not have proj-style definitions reflecting the differences in the various nad83 datums, it does not make sense to differentiate between say nad83 and nad83harn.

  • although the differences between different NAD83 datums are less than a meter, differences between NAD27 and NAD83 are over hundred meters in some areas. Anything that has a different EPSG should be treated as different CRS exactly for the reasons you mentioned in your answer to Vasek.

GRASS does not use EPSG to construct proj-style definitions.

Markus M

Helena

Markus M

Helena

On Nov 10, 2017, at 5:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. projections would be regarded as matching even with e.g. nad27 and nad83.
The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Fixed in trunk r71656.

The test for different datum names has been disabled again in trunk r71657. There are several different datum names in lib/gis/datum.table that apparently mean the same: same ellipsoid and same transformation parameters. Apparently, GRASS does not provide a datum name when converting projection information from GRASS to proj4 for reprojecting data.

Thank you so much, Markus. This saves me a lot of trouble.

About avoiding trouble, the motivation of the stricter CRS comparison is to avoid subsequent geolocation errors. If data have been imported and differences in the CRS were not detected, it can become very difficult later on in the processing to figure out the reason for geolocation errors (different data not matching each other spatially). I’m not sure what to do about different datum names. The current check relies on the test for differences in ellipsoids.

Markus M

(I’m working on a Jupyter Notebook where I need trunk.)
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS

Markus M

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

10

On Sun, Nov 12, 2017 at 12:21 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Nov 11, 2017 at 8:05 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

On Nov 10, 2017, at 7:20 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

Please note, that in spite of the fact that the datum.table shows same transformation parameters,
different nad83 datums are different (it is not just a different name for the same datum) and there are different EPSG codes associated
with the relevant CRS.
You can find more about it here (or just google it)
https://confluence.qps.nl/pages/viewpage.action?pageId=29855153

Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the NGS NADCON program (I have not checked it out)
(http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml).

There are 12 (!) different definitions for NAD83. What to do about this? Regard these 12 definitions as different datums? In this case I would need to reinstate the datum check and we need to add more entries to datum.table.

Markus, we absolutely need to have a datum check

This datum check has been first added in Oct 2003 and has been quickly removed again in Jan 2004. As long as we do not have proj-style definitions reflecting the differences in the various nad83 datums, it does not make sense to differentiate between say nad83 and nad83harn.

Apparently there is a way to construct different proj-style definitions for different nad83 datums:

This looks like users might need to modify proj-style definitions manually, after the appropriate grids have been manually obtained/created.

Markus M

  • although the differences between different NAD83 datums are less than a meter, differences between NAD27 and NAD83 are over hundred meters in some areas. Anything that has a different EPSG should be treated as different CRS exactly for the reasons you mentioned in your answer to Vasek.

GRASS does not use EPSG to construct proj-style definitions.

Markus M

Helena

Markus M

Helena

On Nov 10, 2017, at 5:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. projections would be regarded as matching even with e.g. nad27 and nad83.
The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Fixed in trunk r71656.

The test for different datum names has been disabled again in trunk r71657. There are several different datum names in lib/gis/datum.table that apparently mean the same: same ellipsoid and same transformation parameters. Apparently, GRASS does not provide a datum name when converting projection information from GRASS to proj4 for reprojecting data.

Thank you so much, Markus. This saves me a lot of trouble.

About avoiding trouble, the motivation of the stricter CRS comparison is to avoid subsequent geolocation errors. If data have been imported and differences in the CRS were not detected, it can become very difficult later on in the processing to figure out the reason for geolocation errors (different data not matching each other spatially). I’m not sure what to do about different datum names. The current check relies on the test for differences in ellipsoids.

Markus M

(I’m working on a Jupyter Notebook where I need trunk.)
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS

Markus M

11

On Sun, Nov 19, 2017 at 10:33 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sun, Nov 12, 2017 at 12:21 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Nov 11, 2017 at 8:05 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

On Nov 10, 2017, at 7:20 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

Please note, that in spite of the fact that the datum.table shows same transformation parameters,
different nad83 datums are different (it is not just a different name for the same datum) and there are different EPSG codes associated
with the relevant CRS.
You can find more about it here (or just google it)
https://confluence.qps.nl/pages/viewpage.action?pageId=29855153

Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the NGS NADCON program (I have not checked it out)
(http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml).

There are 12 (!) different definitions for NAD83. What to do about this? Regard these 12 definitions as different datums? In this case I would need to reinstate the datum check and we need to add more entries to datum.table.

Markus, we absolutely need to have a datum check

This datum check has been first added in Oct 2003 and has been quickly removed again in Jan 2004. As long as we do not have proj-style definitions reflecting the differences in the various nad83 datums, it does not make sense to differentiate between say nad83 and nad83harn.

Apparently there is a way to construct different proj-style definitions for different nad83 datums:

This looks like users might need to modify proj-style definitions manually, after the appropriate grids have been manually obtained/created.

With PROJ 5, you can now define custom projection pipelines [0] in r.proj (trunk r72598) and v.proj (trunk r72599). I hope this solves issues with different NAD83 datum definitions.

Markus M

[0] https://proj4.org/usage/transformation.html#transformation

Markus M

  • although the differences between different NAD83 datums are less than a meter, differences between NAD27 and NAD83 are over hundred meters in some areas. Anything that has a different EPSG should be treated as different CRS exactly for the reasons you mentioned in your answer to Vasek.

GRASS does not use EPSG to construct proj-style definitions.

Markus M

Helena

Markus M

Helena

On Nov 10, 2017, at 5:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

7.2 considers this OK while trunk considers this different. I’m not sure which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. projections would be regarded as matching even with e.g. nad27 and nad83.
The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Fixed in trunk r71656.

The test for different datum names has been disabled again in trunk r71657. There are several different datum names in lib/gis/datum.table that apparently mean the same: same ellipsoid and same transformation parameters. Apparently, GRASS does not provide a datum name when converting projection information from GRASS to proj4 for reprojecting data.

Thank you so much, Markus. This saves me a lot of trouble.

About avoiding trouble, the motivation of the stricter CRS comparison is to avoid subsequent geolocation errors. If data have been imported and differences in the CRS were not detected, it can become very difficult later on in the processing to figure out the reason for geolocation errors (different data not matching each other spatially). I’m not sure what to do about different datum names. The current check relies on the test for differences in ellipsoids.

Markus M

(I’m working on a Jupyter Notebook where I need trunk.)
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS

Markus M