Opened 3 years ago

Last modified 9 days ago

#2456 new task

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 3 years ago.

Download all attachments as: .zip

Change History (44)

comment:1 Changed 3 years ago by martinl

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

comment:2 Changed 3 years ago by neteler

Component: DefaultProjections/Datums
Priority: normalcritical

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 Changed 3 years ago by 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

comment:4 in reply to:  description ; Changed 3 years ago by 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

comment:5 in reply to:  4 Changed 3 years ago by 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

comment:6 in reply to:  3 ; Changed 3 years ago by 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

Changed 3 years ago by martinl

Attachment: gdal_data.diff.gz added

comment:7 in reply to:  6 Changed 3 years ago by 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

comment:9 Changed 3 years ago by neteler

Priority: criticalblocker
Version: unspecifiedsvn-releasebranch70

We need to solve this, promoting it to blocker.

comment:10 Changed 22 months ago by 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.

comment:12 in reply to:  6 Changed 18 months ago by 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.

comment:13 Changed 18 months ago by 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

comment:14 Changed 18 months ago by 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?

comment:15 Changed 18 months ago by 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
Last edited 18 months ago by neteler (previous) (diff)

comment:16 Changed 17 months ago by 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.

comment:17 in reply to:  16 ; Changed 17 months ago by neteler

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?

comment:18 in reply to:  17 Changed 17 months ago by 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.

comment:19 Changed 17 months ago by 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.

comment:20 in reply to:  19 ; Changed 17 months ago by neteler

Keywords: g.proj added
Milestone: 7.1.07.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?

comment:21 in reply to:  20 ; Changed 17 months ago by martinl

Replying to neteler:

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

looks fine to me.

comment:22 in reply to:  21 ; Changed 17 months ago by 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

comment:23 in reply to:  22 Changed 17 months ago by 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?

comment:24 Changed 17 months ago by martinl

Is this issue still blocker for 7.0.4 release?

comment:25 Changed 17 months ago by neteler

Priority: blockercritical

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?

comment:26 in reply to:  25 Changed 17 months ago by martinl

Milestone: 7.0.47.0.5
Priority: criticalblocker

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.

comment:27 in reply to:  25 ; Changed 17 months ago by 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!

comment:28 in reply to:  27 Changed 17 months ago by 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.

comment:29 Changed 16 months ago by 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.

Last edited 16 months ago by msieczka (previous) (diff)

comment:30 Changed 16 months ago by martinl

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

comment:31 in reply to:  30 Changed 16 months ago by 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.

comment:32 Changed 16 months ago by neteler

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

comment:33 Changed 13 months ago by 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.

comment:34 Changed 13 months ago by 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.

comment:35 Changed 13 months ago by martinl

Milestone: 7.0.57.3.0

comment:36 Changed 13 months ago by martinl

Milestone: 7.3.07.4.0

Milestone renamed

comment:37 in reply to:  33 ; Changed 13 months ago by 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).

comment:38 in reply to:  37 Changed 13 months ago by 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.

comment:39 Changed 13 months ago by 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

comment:40 Changed 13 months ago by martinl

In 69494:

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

comment:41 in reply to:  39 ; Changed 13 months ago by 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

comment:42 in reply to:  41 Changed 13 months ago by neteler

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 13 months ago by neteler (previous) (diff)

comment:43 Changed 9 days ago by neteler

Is anything missing here?

Note: See TracTickets for help on using tickets.