read CSV from GDAL data directory

[martinl]

Currently GRASS contains copy of several CSV files from GDAL source:grass/trunk/lib/proj. It would make sense to modify GRASS libraries to read these files dynamically.

Any comments?

[neteler]

Yes, this would be very important.

The local GDAL data directory is found like this:

ls `gdal-config --datadir`

Effectively it shows the path to "GDAL_DATA", see

• ​http://trac.osgeo.org/gdal/wiki/ConfigOptions#GDAL_DATA
• ​http://trac.osgeo.org/gdal/wiki/FAQInstallationAndBuilding#WhatisGDAL_DATAenvironmentvariable

[martinl]

For record list of affected files:

• coordinate_axis.csv
• ellipsoid.csv
• gcs.csv
• gcs.override.csv
• gdal_datum.csv
• gt_datum.csv
• gt_ellips.csv
• pcs.csv
• pcs.override.csv
• prime_meridian.csv
• projop_wparm.csv
• stateplane.csv
• unit_of_measure.csv

[hellik]

Replying to martinl:

Currently GRASS contains copy of several CSV files from GDAL source:grass/trunk/lib/proj. It would make sense to modify GRASS libraries to read these files dynamically.

Any comments?

AFAIU winGRASS does it already(?)

e.g.

C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\env.bat

set GISBASE=%OSGEO4W_ROOT%\apps\grass\grass-7.1.svn
REM set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe

set GRASS_HTML_BROWSER=explorer

set GRASS_PYTHON=%OSGEO4W_ROOT%\bin\python.exe
set PYTHONHOME=%OSGEO4W_ROOT%\apps\Python27

set GRASS_PROJSHARE=%OSGEO4W_ROOT%\share\proj

set PROJ_LIB=%OSGEO4W_ROOT%\share\proj
set GDAL_DATA=%OSGEO4W_ROOT%\share\gdal
set GEOTIFF_CSV=%OSGEO4W_ROOT%\share\epsg_csv

set PATH=%OSGEO4W_ROOT%\apps\msys\bin;%PATH%

but there is also

C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\proj

datum.table
datumtransform.table
desc.table
ellipse.table
ellipse.table.solar.system
FIPS.code
nad
ogr_csv
parms.table
projections
state27
state83
units.table

and C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\proj\ogr_csv

coordinate_axis.csv
ellipsoid.csv
gcs.csv
gcs.override.csv
gdal_datum.csv
gt_datum.csv
gt_ellips.csv
pcs.csv
pcs.override.csv
prime_meridian.csv
projop_wparm.csv
stateplane.csv
unit_of_measure.csv

and C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\proj\nad

alaska
conus
FL
hawaii
MD
prvi
src
stgeorge
stlrnc
stpaul
TN
WI
WO

and C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\proj\nad\src

alaska.lla
conus.lla
FL.lla
hawaii.lla
MD.lla
prvi.lla
stgeorge.lla
stlrnc.lla
stpaul.lla
TN.lla
WI.lla
WO.lla

[martinl]

Replying to hellik:

> set GDAL_DATA=%OSGEO4W_ROOT%\share\gdal

yes, but it has no effect, GRASS still uses local copies source:grass/trunk/lib/proj/convert.c#L718​

[martinl]

Replying to martinl:

For record list of affected files:

• pcs.csv

The attached patch attachment:gdal_data.diff forces GRASS to use CSV files from GDAL. First found problem:

GRASS defines 5514 as

pcs.csv:5514,"S-JTSK / Krovak East North",9001,4818,19952,9819,1,0,6501,8806,0,9001,8807,0,9001,8811,49.3,9110,8813,30.1717303,9110,8818,78.3,9110,8819,0.9999,9201,8833,42.3,9110

->

g.proj epsg=5514 -p
-PROJ_INFO-------------------------------------------------
name       : Krovak
proj       : krovak
datum      : hermannskogel
ellps      : bessel
lat_0      : 49.5
lon_0      : 42.5
alpha      : 30.28813972222222
k          : 0.9999
x_0        : 0
y_0        : 0
pm         : ferro
no_defs    : defined
-PROJ_UNITS------------------------------------------------
unit       : meter
units      : meters
meters     : 1

GDAL as

pcs.csv:5514,"S-JTSK / Krovak East North",9001,4156,5510,1041,1,0,4499,1036,30.1717303,9110,8806,0,9001,8807,0,9001,8811,49.3,9110,8818,78.3,9110,8819,0.9999,9201,8833,24.5,9110

->

.proj epsg=5514 -p
-PROJ_INFO-------------------------------------------------
name       : Krovak
proj       : krovak
ellps      : bessel
lat_0      : 49.5
lon_0      : 24.83333333333333
alpha      : 30.28813972222222
k          : 0.9999
x_0        : 0
y_0        : 0
towgs84    : 589,76,480,0,0,0,0
no_defs    : defined
-PROJ_UNITS------------------------------------------------
unit       : meter
units      : meters
meters     : 1

The wgs84 causes that

g.proj epsg=5514 datum_trans=-1
ERROR: No output format specified, define one of flags -p, -g, -j, or -w

will not work.

Should be:

g.proj epsg=5514 datum_trans=-1
---
1
Used in whole hermannskogel region
towgs84=653.000,-212.000,449.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 Austria
towgs84=577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
Accuracy approx. 1.5m
---
3
Used in Czech Republic
towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56
 
---
4
Used in Slovakia
towgs84=485.021,169.465,483.839,7.786342,4.397554,4.102655,0
 
---
5
Used in Slovenia
towgs84=426.9,142.6,460.1,4.91,4.49,-12.42,17.1

[martinl]

Replying to martinl:

The attached patch attachment:gdal_data.diff forces GRASS to use CSV files from GDAL. First found problem:

attachment:gdal_data.diff.gz​

[neteler]

Here some "historical" notes to better understand the actual concept in GDAL:

• ​http://fwarmerdam.blogspot.it/2010/03/in-last-few-weeks-i-believe-i-have-made.html
• Paul Kelly's comments: ​http://lists.osgeo.org/pipermail/grass-dev/2010-March/049674.html
  • in context: ​http://thread.gmane.org/gmane.comp.gis.grass.devel/38870

Additionally the base CSV files:

• ​https://trac.osgeo.org/metacrs/browser/geotiff/trunk/libgeotiff/csv/
• EPSG related explanations: ​https://trac.osgeo.org/metacrs/browser/geotiff/trunk/libgeotiff/csv/README

[neteler]

We need to solve this, promoting it to blocker.

[neteler]

Example, why we need to fix this (​http://epsg.io/4674):

grass70 -c epsg:4674 ~/grassdata/SIRGAS2000

GRASS 7.0.2svn (SIRGAS2000):~ > g.proj -w
GEOGCS["grs80",
    DATUM["unknown",
        SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101],
        TOWGS84[0,0,0,0,0,0,0]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433]]

which is not properly detected.

[neteler]

Maybe of interest:

• ​http://gdal.org/osr_tutorial.html
• ​http://gdal.org/warptut.html

[mmetz]

Replying to martinl:

Replying to martinl:

For record list of affected files:

• pcs.csv

The attached patch attachment:gdal_data.diff forces GRASS to use CSV files from GDAL.

The patch was too complicated. Actually, you do not need to force GRASS to use CSV files from GDAL, instead GRASS should not override the default CSV file location with SetCSVFilenameHook(). Simply disabling calls to this function lets GDAL via GRASS use its own CSV files. Done in trunk r68128.

This does not solve all problems because GRASS uses its own mechanisms for SRS names, datum transformations etc which might fail to find any parameters.

[neteler]

FWIW, the source code of GDAL's gdalsrsinfo application might be used for inspiration to find the datums:

# find by EPSG code
gdalsrsinfo "EPSG:4674"

PROJ.4 : '+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs '

OGC WKT :
GEOGCS["SIRGAS 2000",
    DATUM["Sistema_de_Referencia_Geocentrico_para_las_AmericaS_2000",
        SPHEROID["GRS 1980",6378137,298.257222101,
            AUTHORITY["EPSG","7019"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6674"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4674"]]

# find by PRJ file (WKT string)
gdalsrsinfo /geodata/gaussboaga1.prj 

PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs '

OGC WKT :
PROJCS["Monte Mario / Italy zone 1",
    GEOGCS["Monte Mario",
        DATUM["Monte_Mario",
            SPHEROID["International 1924",6378388.0,297.0,
                AUTHORITY["EPSG","7022"]],
            TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68],
            AUTHORITY["EPSG","6265"]],
        PRIMEM["Greenwich",0.0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.017453292519943295],
        AXIS["Lon",EAST],
        AXIS["Lat",NORTH],
        AUTHORITY["EPSG","4265"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["central_meridian",9.0],
    PARAMETER["latitude_of_origin",0.0],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",1500000.0],
    PARAMETER["false_northing",0.0],
    UNIT["m",1.0],
    AXIS["x",EAST],
    AXIS["y",NORTH],
    AUTHORITY["EPSG","3003"]]

# another EPSG code:
gdalsrsinfo "EPSG:5514"

PROJ.4 : '+proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +towgs84=589,76,480,0,0,0,0 +units=m +no_defs '

OGC WKT :
PROJCS["S-JTSK / Krovak East North",
    GEOGCS["S-JTSK",
        DATUM["System_Jednotne_Trigonometricke_Site_Katastralni",
            SPHEROID["Bessel 1841",6377397.155,299.1528128,
                AUTHORITY["EPSG","7004"]],
            TOWGS84[589,76,480,0,0,0,0],
            AUTHORITY["EPSG","6156"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4156"]],
    PROJECTION["Krovak"],
    PARAMETER["latitude_of_center",49.5],
    PARAMETER["longitude_of_center",24.83333333333333],
    PARAMETER["azimuth",30.28813972222222],
    PARAMETER["pseudo_standard_parallel_1",78.5],
    PARAMETER["scale_factor",0.9999],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["X",EAST],
    AXIS["Y",NORTH],
    AUTHORITY["EPSG","5514"]]

Also the TOWGS84 is there as expected.

Source code: ​https://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdalsrsinfo.cpp#L254

[neteler]

The current state of relbranch70 is:

GRASS 7.0.4svn (latlong):> g.proj epsg=5514 -w
PROJCS["S-JTSK / Krovak East North",
    GEOGCS["bessel",
        DATUM["Militar_Geographische_Institut",
            SPHEROID["Bessel_1841",6377397.155,299.1528128]],
        PRIMEM["Ferro",-17.666666666668],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Krovak"],
    PARAMETER["latitude_of_center",49.5],
    PARAMETER["longitude_of_center",42.5],
    PARAMETER["azimuth",0],
    PARAMETER["pseudo_standard_parallel_1",0],
    PARAMETER["scale_factor",0.9999],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

# ==> wrong.

When (locally) backporting the CSV fix r68128 I finally obtain the right relations between projection and datum:

GRASS 7.0.4svn (latlong):> g.proj epsg=5514 datumtrans=-1 -t -w
---
1
Used in whole S_JTSK region
towgs84=589.000,76.000,480.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 Czech Republic
towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56
Accuracy about 1m
---
3
Used in Czech Republic
towgs84=572.213,85.334,461.94,-4.9732,-1.529,-5.2484,3.5378
Accuracy about 1m
---
4
Used in Slovakia
towgs84=485,169.5,483.8,7.786,4.398,4.103,0
Accuracy about 1m

#####
# selecting the 3rd datum:
GRASS 7.0.4svn (latlong):> g.proj epsg=5514 datumtrans=3 -t -w
PROJCS["S-JTSK / Krovak East North",
    GEOGCS["bessel",
        DATUM["System_Jednotne_Trigonometricke_Site_Katastralni",
            SPHEROID["Bessel_1841",6377397.155,299.1528128],
            TOWGS84[589,76,480,0,0,0,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Krovak"],
    PARAMETER["latitude_of_center",49.5],
    PARAMETER["longitude_of_center",24.83333333333333],
    PARAMETER["azimuth",0],
    PARAMETER["pseudo_standard_parallel_1",0],
    PARAMETER["scale_factor",0.9999],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

# ==> better (Greenwich, not Ferro) but azimuth and pseudo_standard_parallel_1 seem to be wrong.

See also: ​http://epsg.io/5514

Any ideas?

[neteler]

CSV fix backported in r68267.

TODO before closing this report: remove the outdated .csv files etc from lib/proj/

Still some GEOGCS lookup fails, also in trunk. Maybe ​https://trac.osgeo.org/grass/browser/grass/trunk/lib/proj/convert.c#L395 (GEOCGS check) is still incomplete? Example:

# compare
grass71 -c epsg:4674 ~/grassdata/SIRGAS2000
g.proj -w

# to
testepsg epsg:4674

[neteler]

Also EPSG 3358 (NC) is an issue:

grass71 -c epsg:3358 ~/grassdata/nc_data
GRASS 7.1.svn (nc_data):~ > g.proj -w
PROJCS["NAD83(HARN) / North Carolina",
    GEOGCS["grs80",
        DATUM["unknown",
            SPHEROID["Geodetic_Reference_System_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",36.16666666666666],
    PARAMETER["standard_parallel_2",34.33333333333334],
    PARAMETER["latitude_of_origin",33.75],
    PARAMETER["central_meridian",-79],
    PARAMETER["false_easting",609601.22],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

Expected: ​http://epsg.io/3358 :

PROJCS["NAD83(HARN) / North Carolina",
    GEOGCS["NAD83(HARN)",
        DATUM["NAD83_High_Accuracy_Reference_Network",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6152"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4152"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",36.16666666666666],
    PARAMETER["standard_parallel_2",34.33333333333334],
    PARAMETER["latitude_of_origin",33.75],
    PARAMETER["central_meridian",-79],
    PARAMETER["false_easting",609601.22],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["X",EAST],
    AXIS["Y",NORTH],
    AUTHORITY["EPSG","3358"]]

The recognition of datum name "NAD83_High_Accuracy_Reference_Network" fails.

[neteler]

Replying to neteler:

Also EPSG 3358 (NC) is an issue:

NAD83(HARN) fixed in r68308 (backport needed). See discussion here:

• ​https://lists.osgeo.org/pipermail/grass-dev/2016-April/079938.html
• ​https://lists.osgeo.org/pipermail/grass-dev/2016-April/079936.html
• ...and related.

Open issues:

• Krovak (see above)
• SIRGAS2000 epsg:4674
• local .csv files to be deleted
• other?

[neteler]

Replying to neteler:

Replying to neteler:

Also EPSG 3358 (NC) is an issue:

NAD83(HARN) fixed in r68308 (backport needed).

Backported to relbr7 in r68314.

[neteler]

PROJCS versus GEOGCS confusion fix (example epsg:4674) in r68313 as per discussion in ​https://lists.osgeo.org/pipermail/grass-dev/2016-April/079942.html (fixes r68131).

To be further tested before backport.

[neteler]

Replying to neteler:

PROJCS versus GEOGCS confusion fix (example epsg:4674) in r68313 as per discussion in ​https://lists.osgeo.org/pipermail/grass-dev/2016-April/079942.html (fixes r68131).

To be further tested before backport.

Did anyone find issues with r68313 in trunk? May I backport?

[martinl]

Replying to neteler:

Did anyone find issues with r68313 in trunk? May I backport?

looks fine to me.

[neteler]

Replying to martinl:

Replying to neteler:

Did anyone find issues with r68313 in trunk? May I backport?

looks fine to me.

Done in r68331.

Remains to remove the "junk" CSV files and to clean up lib/proj/Makefile

[martinl]

Replying to neteler:

Remains to remove the "junk" CSV files and to clean up lib/proj/Makefile

Are you planning to do it before 7.0.4 or after this release?

[martinl]

Is this issue still blocker for 7.0.4 release?

[neteler]

CSV files removed in trunk in r68341. We can delete them in relbranch70 after the 7.0.4 release.

Ideally, after understanding what to do with the *.lla files, nzgd2kgrid0005.gsb, and ntv1_can.dat which appear to be more recent in the "proj-nad" package itself (in a more recent table format). Ideas?

[martinl]

Replying to neteler:

CSV files removed in trunk in r68341. We can delete them in relbranch70 after the 7.0.4 release.

changing milestone to 7.0.5.

[neteler]

Replying to neteler:

CSV files removed in trunk in r68341. We can delete them in relbranch70 after the 7.0.4 release.

Done in r68381.

Ideally, after understanding what to do with the *.lla files, nzgd2kgrid0005.gsb, and ntv1_can.dat which appear to be more recent in the "proj-nad" package itself (in a more recent table format). Ideas?

... still a TODO!

[neteler]

Replying to neteler:

Ideally, after understanding what to do with the *.lla files, nzgd2kgrid0005.gsb, and ntv1_can.dat which appear to be more recent in the "proj-nad" package itself (in a more recent table format). Ideas?

... still a TODO!

Comment by Paul Kelly via email:

There would be some changes needed to lib/proj/get_proj.c - the call to pj_set_finder() should be removed so that PROJ looks in its default locations for the files. Also changes needed to lib/proj/Makefile so it no longer creates the /etc/proj and /etc/proj/nad directories within a GRASS installation nor installs the files there.

[msieczka]

Regarding grass/trunk/lib/proj/README.txt r68435: "changes needed to lib/proj/Makefile so it no longer creates the /etc/proj and /etc/proj/nad directories within a GRASS installation nor installs the files there" - another option might be not to search for the grids in any particular directory at all, but to rely on a user-provided full path to the grid file in the PROJ_INFO.

cs2cs, gdalwarp etc. allow the "nadgrids" to be a full path to a grid file.

[martinl]

What is exactly needed to close this ticket regarding 7.0.5 milestone?

[neteler]

Replying to martinl:

What is exactly needed to close this ticket regarding 7.0.5 milestone?

We need to understand if the included NAD files are the same as in PROJ.4 and if it can remain like this for 7.0.x?

For trunk, Paul's suggestion should be implemented.

[neteler]

added ntf_r93.gsb and null.lla unless this ticket is solved in r68654, see also #1219

[neteler]

After discussion with Even Rouault at the FOSS4G 2016 code sprint and some testing with m.proj

• removal of local copies of NAD and datum shift files which are indeed used from GDAL
• extended documentation in lib/proj/README.txt

Done in r69211.

After extensive testing backport candidate. Test values available in ​https://github.com/OSGeo/proj.4/tree/master/nad . Test cases should be implemented with m.proj.

[martinl]

I suggest to change milestone from 7.0.5 to 7.3.0. I don't feel that there is something what we can do for 7.0.5 release.

[martinl]

Milestone renamed

[neteler]

Replying to neteler:

After discussion with Even Rouault at the FOSS4G 2016 code sprint and some testing with m.proj

• removal of local copies of NAD and datum shift files which are indeed used from GDAL
• extended documentation in lib/proj/README.txt

Done in r69211.

After extensive testing backport candidate. Test values available in ​https://github.com/OSGeo/proj.4/tree/master/nad . Test cases should be implemented with m.proj.

Issues: the location manager needs to be updated accordingly (at time it still seeks for NAD files in the removed etc/proj/nad/ directory):

cd gui/wxpython/location_wizard/
wizard.py:                # prepare +nadgrids or +towgs84 terms for Summary page. first
wizard.py:                            "towgs84=") != -1 or projterm.find("nadgrids=") != -1:
wizard.py:                # prepare +nadgrids or +towgs84 terms for Summary page. first
wizard.py:                            "towgs84=") != -1 or projterm.find("nadgrids=") != -1:

Furthermore the g.proj code needs updates. Or in lib/proj/?

For some tests, see ​https://lists.osgeo.org/pipermail/grass-user/2016-September/075035.html

I wonder if we should revert r69211 for now (except for the README update).

[martinl]

Replying to neteler:

Furthermore the g.proj code needs updates. Or in lib/proj/?

For some tests, see ​https://lists.osgeo.org/pipermail/grass-user/2016-September/075035.html

what is exact problem? I tried in G72 and G73

g.proj -t epsg=2992 datumtrans=-1

Both version gives me the same output:

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

BTW, instead of

grass72 -c epsg:2992 ~/grassdata/oregon2992_nad83_WO --exec g.proj -t
epsg=2992 datumtrans=6 -p

you can do

grass72 -c epsg:2992:6 ~/grassdata/oregon2992_nad83_WO --exec g.proj -p

The same approach works also in G73.

[martinl]

The issue with g.proj is related to -j flag:

g.proj -jft epsg=2992 datumtrans=6

... +nadgrids=/opt/src/grass_trunk/dist.x86_64-pc-linux-gnu/etc/proj/nad/WO +to_meter=0.3048

[martinl]

In 69494:

Fix GPJget_datum_params() to respect r69211 (see #2456)

[martinl]

Replying to martinl:

The issue with g.proj is related to -j flag:

g.proj -jft epsg=2992 datumtrans=6

... +nadgrids=/opt/src/grass_trunk/dist.x86_64-pc-linux-gnu/etc/proj/nad/WO +to_meter=0.3048

Should be fixed in r69494

[neteler]

Replying to martinl:

Should be fixed in r69494

Very good! Now it looks like this on my Fedora box:

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

[neteler]

Is anything missing here?

[mlennert]

Replying to neteler:

Is anything missing here?

ping

[neteler]

Solved both in relbranch72 and trunk, closing.