[GRASS-user] v.proj fails: no shift table

GRASS GRASS user
1

   The target location has these PROJ_INFO parameters defined in a Shapefile
*.prj:

name: NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl
datum: nad83harn
ellps: grs80
proj: lcc
lat_1: 44.33333333333334
lat_2: 46
lat_0: 43.66666666666666
lon_0: -120.5
x_0: 2500000
y_0: 0
no_defs: defined

The source location has these PROJ_INFO parameters defined in the
metadata.xml with EPSG 2992:

name: NAD83 / Oregon Lambert (ft)
datum: nad83
ellps: grs80
proj: lcc
lat_1: 43
lat_2: 45.5
lat_0: 41.75
lon_0: -120.5
x_0: 399999.9999984
y_0: 0
no_defs: defined
nadgrids: WO

   When I imported this OFGDB source and selected epsg 2992 a window with 6
flavors appeared. I selected #6: Washington/Oregon HARM adjustment.
Apparently this was not used.

   From the target location/mapset I tried v.proj location=ODOT2014mapset=data_source.gdb input=state_roads_2014 (I renamed the long original name to this with g.rename.) and was told there
was no projection conversion table available.

   Should I re-import the data and try to ensure that the HARM adjustment is
accepted, or is there a way of reprojecting the source to match the target?

Rich

2

On Thu, Sep 15, 2016 at 1:02 AM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

The target location has these PROJ_INFO parameters defined in a Shapefile
*.prj:

name: NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl
datum: nad83harn
ellps: grs80
proj: lcc
lat_1: 44.33333333333334
lat_2: 46
lat_0: 43.66666666666666
lon_0: -120.5
x_0: 2500000
y_0: 0
no_defs: defined

The source location has these PROJ_INFO parameters defined in the
metadata.xml with EPSG 2992:

name: NAD83 / Oregon Lambert (ft)
datum: nad83
ellps: grs80
proj: lcc
lat_1: 43
lat_2: 45.5
lat_0: 41.75
lon_0: -120.5
x_0: 399999.9999984
y_0: 0
no_defs: defined
nadgrids: WO

When I imported this OFGDB source and selected epsg 2992 a window with 6
flavors appeared. I selected #6: Washington/Oregon HARM adjustment.

yes, it would apply
nadgrids=WO

according to the list in the location manager selection window (I just tried here with EPSG 2992).

Apparently this was not used.

I checked:

  • in GRASS GIS 7.2 is is used, should be ok:

g.proj -p
-PROJ_INFO-------------------------------------------------
name : NAD83 / Oregon Lambert (ft)
datum : nad83
ellps : grs80
proj : lcc
lat_1 : 43
lat_2 : 45.5
lat_0 : 41.75
lon_0 : -120.5
x_0 : 399999.9999984
y_0 : 0
no_defs : defined
nadgrids : WO
-PROJ_EPSG-------------------------------------------------
epsg : 2992
-PROJ_UNITS------------------------------------------------
unit : foot
units : feet
meters : 0.3048

Question: do you use 7.2.svn?

  • in trunk (“7.3”) it is not used due to NAD file removal during the recent code sprint upon long discussions with the GDAL maintainer Even Rouault (https://trac.osgeo.org/grass/changeset/69211). Here it should use the respective file through GDAL/PROJ4 since we don’t want to keep our private copies any longer.

From the target location/mapset I tried v.proj
location=ODOT2014mapset=data_source.gdb input=state_roads_2014 (I renamed
the long original name to this with g.rename.) and was told there
was no projection conversion table available.

Sounds to me that you are using the trunk version of GRASS GIS?

Should I re-import the data and try to ensure that the HARM adjustment is
accepted, or is there a way of reprojecting the source to match the target?

In the first place I would use GRASS GIS 7.2.svn since the NAD management stuff in trunk is currently experimental.
It is a fairly complex beast. The idea is that GRASS no longer bothers about NAD and just receives related info from GDAL/PROJ4. Seems not to be complete yet (I’ll update https://trac.osgeo.org/grass/ticket/2456 accordingly).

For now, here a cmd line way for GRASS GIS 7.2:

create dummy location just in order to fetch the list

of available datums for given EPSG code:

grass72 -c epsg:2992 ~/grassdata/dummy --exec g.proj -t epsg=2992 datumtrans=-1
Cleaning up temporary files…
Creating new GRASS GIS location/mapset…
Executing <g.proj -t datumtrans=-1 epsg=2992> …

1
Used in whole nad83 region
towgs84=0.000,0.000,0.000
Default 3-Parameter Transformation (May not be optimum for older datums; use this only if no more appropriate options are available.)

2
Used in Florida
nadgrids=FL
Transforms ‘Old NAD83’ to ‘HPGN NAD83’

3
Used in Maryland
nadgrids=MD
Transforms ‘Old NAD83’ to ‘HPGN NAD83’

4
Used in Tennessee
nadgrids=TN
Transforms ‘Old NAD83’ to ‘HPGN NAD83’

5
Used in Wisconsin
nadgrids=WI
Transforms ‘Old NAD83’ to ‘HPGN NAD83’

6
Used in Washington - Oregon
nadgrids=WO
Transforms ‘Old NAD83’ to ‘HPGN NAD83’
Execution of <g.proj -t datumtrans=-1 epsg=2992> finished.
Cleaning up temporary files…

now generate location using EPSG code and related datumtransform #6:

grass72 -c epsg:2992 ~/grassdata/oregon2992_nad83_WO --exec g.proj -t epsg=2992 datumtrans=6 -p
Cleaning up temporary files…
Creating new GRASS GIS location/mapset…
Executing <g.proj -t epsg=2992 datumtrans=6 -p> …
-PROJ_INFO-------------------------------------------------
name : NAD83 / Oregon Lambert (ft)
datum : nad83
ellps : grs80
proj : lcc
lat_1 : 43
lat_2 : 45.5
lat_0 : 41.75
lon_0 : -120.5
x_0 : 399999.9999984
y_0 : 0
no_defs : defined
nadgrids : WO
-PROJ_EPSG-------------------------------------------------
epsg : 2992
-PROJ_UNITS------------------------------------------------
unit : foot
units : feet
meters : 0.3048
Execution of <g.proj -t epsg=2992 datumtrans=6 -p> finished.
Cleaning up temporary files…

eventually start using the new location

grass72 ~/grassdata/oregon2992_nad83_WO/PERMANENT/

But! When entering this location and running
g.proj -p
still nadgrids is not listed any more… confusing.
Anyone with more insights here?

Markus

3

Rich,

Martin fixed it just now in trunk (7.3.svn) in r69494.

Now it looks like this on my Fedora box:

# (long line broken here on purpose)
GRASS 7.3.svn (nc_spm_08_grass7):~ > g.proj -jft epsg=2992 datumtrans=6
+proj=lcc +lat_1=43 +lat_2=45.5 +lat_0=41.75 +lon_0=-120.5
+x_0=399999.9999984 +y_0=0 +no_defs +a=6378137 +rf=298.257222101
+nadgrids=/usr/share/proj/WO +to_meter=0.3048

GRASS 7.3.svn (nc_spm_08_grass7):~ > g.proj -pt epsg=2992 datumtrans=6
-PROJ_INFO-------------------------------------------------
name : NAD83 / Oregon Lambert (ft)
datum : nad83
ellps : grs80
proj : lcc
lat_1 : 43
lat_2 : 45.5
lat_0 : 41.75
lon_0 : -120.5
x_0 : 399999.9999984
y_0 : 0
no_defs : defined
nadgrids : WO
-PROJ_EPSG-------------------------------------------------
epsg : 2992
-PROJ_UNITS------------------------------------------------
unit : foot
units : feet
meters : 0.3048

Seems we are back on track? Please update and let us know.

Markus

4

On Thu, 15 Sep 2016, Markus Neteler wrote:

Sounds to me that you are using the trunk version of GRASS GIS?

Markus,

   Yes, I did use 'trunk' and expected to hit a speed bump some time. So, I
should have dropped back to 7.2svn before writing.

For now, here a cmd line way for GRASS GIS 7.2:

   Good information. I'll use 7.2svn now rather than 7.3svn. I'm sure this
will save me a lot of time and allow me to not clutter the list with
avoidable questions.

Thanks very much,

Rich

5

On Thu, 15 Sep 2016, Markus Neteler wrote:

Martin fixed it just now in trunk (7.3.svn) in r69494.

Markus,

   I am always impressed and grateful to the responsiveness of OSS
developers.

Thank you both,

Rich

6

On Thu, Sep 15, 2016 at 3:00 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Thu, 15 Sep 2016, Markus Neteler wrote:

Martin fixed it just now in trunk (7.3.svn) in r69494.

Markus,

  I am always impressed and grateful to the responsiveness of OSS
developers.

We are happy to help! And at the end of the day you triggered several
improvements :slight_smile:

It is good that you don't give up here easily but try get things
solved. Overall, a win-win for all of us.

Best,
Markus

PS: Still, if you can, please test this fix in trunk since we plan to
backport the improved PROJ4 support mechanism at some point.

7

On Thu, 15 Sep 2016, Markus Neteler wrote:

Seems we are back on track? Please update and let us know.

Markus,

   Yes, we're back on the tracks.

   My project's location report:

GRASS 7.3.svn
~/projects/oregon/<proj_name>/data/features > g.proj -pt
-PROJ_INFO-------------------------------------------------
name : NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl
datum : nad83harn
ellps : grs80
proj : lcc
lat_1 : 44.33333333333334
lat_2 : 46
lat_0 : 43.66666666666666
lon_0 : -120.5
x_0 : 2500000
y_0 : 0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Foot
units : Feet
meters : 0.3048

   The OpenFileGDB roads location report:

GRASS 7.3.svn (ODOT2014):~/data/grassdata/ODOT2014 > g.proj -pt
-PROJ_INFO-------------------------------------------------
name : NAD83 / Oregon Lambert (ft)
datum : nad83
ellps : grs80
proj : lcc
lat_1 : 43
lat_2 : 45.5
lat_0 : 41.75
lon_0 : -120.5
x_0 : 399999.9999984
y_0 : 0
no_defs : defined
-PROJ_EPSG-------------------------------------------------
epsg : 2992
-PROJ_UNITS------------------------------------------------
unit : foot
units : feet
meters : 0.3048

   And v.proj run from the project location has no complaints about
transforming projection data from the source location.

   The state is supposed to have a single projection so it's interesting to
learn that map sets from two different state agencies have slightly
different parameters.

   I don't mind testing in the corners of the development (trunk) branch.

Thanks to Even, Martin, and you for taking the time to patch things,

Rich