Opened 10 years ago

Closed 7 years ago

#2456 closed task (fixed)

read CSV from GDAL data directory

Reported by: martinl Owned by: grass-dev@…
Priority: blocker Milestone: 7.4.0
Component: Projections/Datums Version: svn-releasebranch70
Keywords: gdal, g.proj Cc:
CPU: Unspecified Platform: Unspecified

Description (last modified by 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?

Attachments (1)

gdal_data.diff.gz​ (160.4 KB ) - added by martinl 10 years ago.

Download all attachments as: .zip

Change History (46)

comment:1 by martinl, 10 years ago

Description: modified (diff)
Summary: read cvs from GDAL data directory → read CSV from GDAL data directory

comment:2 by neteler, 10 years ago

Component: Default → Projections/Datums
Priority: normal → critical

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

comment:3 by martinl, 10 years ago

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

in reply to:  description ; comment:4 by hellik, 10 years ago

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

in reply to:  4 comment:5 by martinl, 10 years ago

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​

in reply to:  3 ; comment:6 by martinl, 10 years ago

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

by martinl, 10 years ago

Attachment: gdal_data.diff.gz​ added

in reply to:  6 comment:7 by martinl, 10 years ago

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​

comment:9 by neteler, 10 years ago

Priority: critical → blocker
Version: unspecified → svn-releasebranch70

We need to solve this, promoting it to blocker.

comment:10 by neteler, 9 years ago

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.

in reply to:  6 comment:12 by mmetz, 9 years ago

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.

comment:13 by neteler, 9 years ago

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

comment:14 by neteler, 9 years ago

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?

comment:15 by neteler, 9 years ago

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
Last edited 9 years ago by neteler (previous) (diff)

comment:16 by neteler, 9 years ago

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.

in reply to:  16 ; comment:17 by neteler, 9 years ago

Replying to neteler:

Also EPSG 3358 (NC) is an issue:

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

Open issues:

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

in reply to:  17 comment:18 by neteler, 9 years ago

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.

comment:19 by neteler, 9 years ago

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.

in reply to:  19 ; comment:20 by neteler, 9 years ago

Keywords: g.proj added
Milestone: 7.1.0 → 7.0.4

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?

in reply to:  20 ; comment:21 by martinl, 9 years ago

Replying to neteler:

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

looks fine to me.

in reply to:  21 ; comment:22 by neteler, 9 years ago

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

in reply to:  22 comment:23 by martinl, 9 years ago

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?

comment:24 by martinl, 9 years ago

Is this issue still blocker for 7.0.4 release?

comment:25 by neteler, 9 years ago

Priority: blocker → critical

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?

in reply to:  25 comment:26 by martinl, 9 years ago

Milestone: 7.0.4 → 7.0.5
Priority: critical → blocker

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.

in reply to:  25 ; comment:27 by neteler, 9 years ago

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!

in reply to:  27 comment:28 by neteler, 9 years ago

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.

comment:29 by msieczka, 9 years ago

Regarding grass/trunk/lib/proj in r68435 - another option might be not to search for the grids in any particular directory, 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.

Version 0, edited 9 years ago by msieczka (next)

comment:30 by martinl, 8 years ago

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

in reply to:  30 comment:31 by neteler, 8 years ago

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.

comment:32 by neteler, 8 years ago

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

comment:33 by neteler, 8 years ago

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.

comment:34 by martinl, 8 years ago

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.

comment:35 by martinl, 8 years ago

Milestone: 7.0.5 → 7.3.0

comment:36 by martinl, 8 years ago

Milestone: 7.3.0 → 7.4.0

Milestone renamed

in reply to:  33 ; comment:37 by neteler, 8 years ago

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

in reply to:  37 comment:38 by martinl, 8 years ago

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.

comment:39 by martinl, 8 years ago

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

comment:40 by martinl, 8 years ago

In 69494:

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

in reply to:  39 ; comment:41 by martinl, 8 years ago

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

in reply to:  41 comment:42 by neteler, 8 years ago

Replying to martinl:

Should be fixed in r69494

Very good! 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
Last edited 8 years ago by neteler (previous) (diff)

comment:43 by neteler, 7 years ago

Is anything missing here?

in reply to:  43 comment:44 by mlennert, 7 years ago

Replying to neteler:

Is anything missing here?

ping

comment:45 by neteler, 7 years ago

Resolution: → fixed
Status: new → closed

Solved both in relbranch72 and trunk, closing.

Note: See TracTickets for help on using tickets.