[GRASS-user] help with testing the location wizard for the upcoming release

GRASS GRASS user
1

Hi, this is a general call for help.

if anyone/everyone is able to help test, we have made some fixes
to the wxGUI new location wizard since 6.4.3rc3, which really
need to be tested well before the final release. We think all is
ok now, but a messed up location projection definition and ruin
everything downstream in the location, so it's an important
thing to be totally sure of.

since there are so many projections and datums and ways to
select them, it's pretty hard to test for "working/not working"
as we usally could do. Please try throwing your local odd-ball
CRS at it and see what happens. (check all the way through to
'g.proj -p' and 'g.proj -j' in the final location session. make
sure it does what you'd expect it to do.

specifically how datum transforms are handled, and CRSs without
a specificed datum or specified datum terms; usuing all methods
of defining the projection system. see trac issues #1849 and
#1967 for further details.

known issues:
users of proj 4.7.0 and 4.8.0 will get different results for
the default datum transform terms. (PROJ.4 now decides differently,
beyond our control)
when reading from a .prj or WKT file, or creating from a geo-
referenced file, with unspecified datum transform opts, you will
not be prompted to enter them. the location will be created not
mentioning them, but in the background PROJ.4 will assign some
default value (of its choosing) silently.

for those who use Subversion and compile, you know what to do;
for those who don't, nightly test builds are available for Windows
and Ubuntu.

thanks a bunch,
Hamish

2

On 26/05/13 13:20, Hamish wrote:

known issues:
when reading from a .prj or WKT file, or creating from a geo-
referenced file, with unspecified datum transform opts, you will
not be prompted to enter them. the location will be created not
mentioning them, but in the background PROJ.4 will assign some
default value (of its choosing) silently.

Trying to define a sector in Belgian Lambert (1972 or 2008) projections, I see the following oddity (linked to the above ?): Using EPSG codes, I do get prompted with a choice for either no transformation or one choice of transform parameters, but even when I chose "Do not apply any datum transformations" I get a sector with the towgs84 parameter defined for transformation.

The same happens when I try to define these projections manually by choosing in a list.

When I enter the proj4 string without the towgs84 parameter it works as expected, i.e. no towgs84 defined.

Moritz

3

since there are so many projections and datums and ways to
select them, it's pretty hard to test for "working/not working"
as we usally could do. Please try throwing your local odd-ball
CRS at it and see what happens. (check all the way through to
'g.proj -p' and 'g.proj -j' in the final location session. make
sure it does what you'd expect it to do.

EPSG 3416 ETRS89 / Austria Lambert

System Info
GRASS version: 6.5.svn
GRASS SVN Revision: 56422
GIS Library Revision: 50936 (2012-02-25)
GDAL/OGR: 1.9.2
PROJ4: Rel. 4.8.0, 6 March 2012
Python: 2.7.4
wxPython: 2.8.12.1
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)

Select datum transformation

0 Do not apply any datum transformation

g.region -p
projection: 99 (Lambert Conformal Conic)
zone: 0
datum: etrs89
ellipsoid: grs80
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
datum : etrs89
ellps : grs80
lat_1 : 49
lat_2 : 46
lat_0 : 47.5
lon_0 : 13.33333333333333
x_0 : 400000
y_0 : 400000
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : metre
units : metres
meters : 1

g.proj -j
+proj=lcc
+lat_1=49
+lat_2=46
+lat_0=47.5
+lon_0=13.33333333333333
+x_0=400000
+y_0=400000
+no_defs
+a=6378137
+rf=298.257222101
+towgs84=0.000,0.000,0.000
+to_meter=1

1 Used in whole etrs89 region: towgs84=0.000,0.000,0.000 (Default
3-Parameter Transformation)

g.region -p
projection: 99 (Lambert Conformal Conic)
zone: 0
datum: etrs89
ellipsoid: grs80
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
datum : etrs89
ellps : grs80
lat_1 : 49
lat_2 : 46
lat_0 : 47.5
lon_0 : 13.33333333333333
x_0 : 400000
y_0 : 400000
no_defs : defined
towgs84 : 0.000,0.000,0.000
-PROJ_UNITS------------------------------------------------
unit : metre
units : metres
meters : 1

g.proj -j
+proj=lcc
+lat_1=49
+lat_2=46
+lat_0=47.5
+lon_0=13.33333333333333
+x_0=400000
+y_0=400000
+no_defs
+a=6378137
+rf=298.257222101
+towgs84=0.000,0.000,0.000
+to_meter=1

GRASS version: 6.4.3svn
GRASS SVN Revision: 56413
GIS Library Revision: 50937 (2012-02-25)
GDAL/OGR: 1.9.2
PROJ4: Rel. 4.8.0, 6 March 2012
Python: 2.7.4
wxPython: 2.8.12.1
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)

Select datum transformation

0 Do not apply any datum transformation

g.region -p
projection: 99 (Lambert Conformal Conic)
zone: 0
datum: etrs89
ellipsoid: grs80
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
datum : etrs89
ellps : grs80
lat_1 : 49
lat_2 : 46
lat_0 : 47.5
lon_0 : 13.33333333333333
x_0 : 400000
y_0 : 400000
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : metre
units : metres
meters : 1

g.proj -j
+proj=lcc
+lat_1=49
+lat_2=46
+lat_0=47.5
+lon_0=13.33333333333333
+x_0=400000
+y_0=400000
+no_defs
+a=6378137
+rf=298.257222101
+towgs84=0.000,0.000,0.000
+to_meter=1

1 Used in whole etrs89 region: towgs84=0.000,0.000,0.000 (Default
3-Parameter Transformation)

g.region -p
projection: 99 (Lambert Conformal Conic)
zone: 0
datum: etrs89
ellipsoid: grs80
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
datum : etrs89
ellps : grs80
lat_1 : 49
lat_2 : 46
lat_0 : 47.5
lon_0 : 13.33333333333333
x_0 : 400000
y_0 : 400000
no_defs : defined
towgs84 : 0.000,0.000,0.000
-PROJ_UNITS------------------------------------------------
unit : metre
units : metres
meters : 1

g.proj -j
+proj=lcc
+lat_1=49
+lat_2=46
+lat_0=47.5
+lon_0=13.33333333333333
+x_0=400000
+y_0=400000
+no_defs
+a=6378137
+rf=298.257222101
+towgs84=0.000,0.000,0.000
+to_meter=1

EPSG 31258 MGI / Austria GK M31

GRASS version: 6.4.3svn
GRASS SVN Revision: 56413
GIS Library Revision: 50937 (2012-02-25)
GDAL/OGR: 1.9.2
PROJ4: Rel. 4.8.0, 6 March 2012
Python: 2.7.4
wxPython: 2.8.12.1
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)

Select datum transformation

0 Do not apply any datum transformation

g.region -p
projection: 99 (Transverse Mercator)
zone: 0
datum: hermannskogel
ellipsoid: bessel
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Transverse Mercator
proj : tmerc
datum : hermannskogel
ellps : bessel
lat_0 : 0
lon_0 : 13.33333333333333
k : 1
x_0 : 450000
y_0 : -5000000
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : metre
units : metres
meters : 1

g.proj -j
+proj=tmerc
+lat_0=0
+lon_0=13.33333333333333
+k=1
+x_0=450000
+y_0=-5000000
+no_defs
+a=6377397.155
+rf=299.1528128
+towgs84=653.000,-212.000,449.000
+to_meter=1

1 Used in whole hermannskogel region: towwgs84=653.000,-212.000,449.000

g.region -p
projection: 99 (Transverse Mercator)
zone: 0
datum: hermannskogel
ellipsoid: bessel
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Transverse Mercator
proj : tmerc
datum : hermannskogel
ellps : bessel
lat_0 : 0
lon_0 : 13.33333333333333
k : 1
x_0 : 450000
y_0 : -5000000
no_defs : defined
towgs84 : 653.000,-212.000,449.000
-PROJ_UNITS------------------------------------------------
unit : metre
units : metres
meters : 1

g.proj -j
+proj=tmerc
+lat_0=0
+lon_0=13.33333333333333
+k=1
+x_0=450000
+y_0=-5000000
+no_defs
+a=6377397.155
+rf=299.1528128
+towgs84=653.000,-212.000,449.000
+to_meter=1

2 Used in Austria:
towgs84=577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232 Accuracy approx.
1.5m

g.region -p
projection: 99 (Transverse Mercator)
zone: 0
datum: hermannskogel
ellipsoid: bessel
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Transverse Mercator
proj : tmerc
datum : hermannskogel
ellps : bessel
lat_0 : 0
lon_0 : 13.33333333333333
k : 1
x_0 : 450000
y_0 : -5000000
no_defs : defined
towgs84 : 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
-PROJ_UNITS------------------------------------------------
unit : metre
units : metres
meters : 1

g.proj -j
+proj=tmerc
+lat_0=0
+lon_0=13.33333333333333
+k=1
+x_0=450000
+y_0=-5000000
+no_defs
+a=6377397.155
+rf=299.1528128
+towgs84=577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
+to_meter=1

it seems "0 Do not apply any datum transformation" isn't applied?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/help-with-testing-the-location-wizard-for-the-upcoming-release-tp5055791p5055894.html
Sent from the Grass - Users mailing list archive at Nabble.com.

4

since there are so many projections and datums and ways to
select them, it's pretty hard to test for "working/not working"
as we usally could do. Please try throwing your local odd-ball
CRS at it and see what happens. (check all the way through to
'g.proj -p' and 'g.proj -j' in the final location session. make
sure it does what you'd expect it to do.

gdalinfo iseldem.tif

Driver: GTiff/GeoTIFF
Files: iseldem.tif
Size is 3117, 2601
Coordinate System is:
PROJCS["Lambert Azimuthal Equal Area",
    GEOGCS["grs80",
        DATUM["European_Terrestrial_Reference_System_1989",
            SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            AUTHORITY["EPSG","6258"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Azimuthal_Equal_Area"],
    PARAMETER["latitude_of_center",52],
    PARAMETER["longitude_of_center",10],
    PARAMETER["false_easting",4321000],
    PARAMETER["false_northing",3210000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (4471032.628007249900000,2686202.526832540100000)
Pixel Size = (22.717005998822735,-22.717005998819641)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 4471032.628, 2686202.527) ( 11d58'53.33"E, 47d16'16.87"N)
Lower Left ( 4471032.628, 2627115.594) ( 11d57'41.52"E, 46d44'22.62"N)
Upper Right ( 4541841.536, 2686202.527) ( 12d54'57.39"E, 47d15' 1.05"N)
Lower Right ( 4541841.536, 2627115.594) ( 12d53'11.78"E, 46d43' 7.68"N)
Center ( 4506437.082, 2656659.061) ( 12d26'11.02"E, 46d59'45.72"N)

location wizard => georeferenced file iseldem.tif

g.region -p
projection: 99 (Lambert Azimuthal Equal Area)
zone: 0
datum: etrs89
ellipsoid: grs80
north: 2686202.52683254
south: 2627115.59422961
west: 4471032.62800725
east: 4541841.53570558
nsres: 22.717006
ewres: 22.717006
rows: 2601
cols: 3117
cells: 8107317

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Azimuthal Equal Area
proj : laea
datum : etrs89
ellps : grs80
lat_0 : 52
lon_0 : 10
x_0 : 4321000
y_0 : 3210000
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : metre
units : metres
meters : 1

g.proj -j
+proj=laea
+lat_0=52
+lon_0=10
+x_0=4321000
+y_0=3210000
+no_defs
+a=6378137
+rf=298.257222101
+towgs84=0.000,0.000,0.000
+to_meter=1

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/help-with-testing-the-location-wizard-for-the-upcoming-release-tp5055791p5055897.html
Sent from the Grass - Users mailing list archive at Nabble.com.

5

since there are so many projections and datums and ways to
select them, it's pretty hard to test for "working/not working"
as we usally could do. Please try throwing your local odd-ball
CRS at it and see what happens. (check all the way through to
'g.proj -p' and 'g.proj -j' in the final location session. make
sure it does what you'd expect it to do.

testgkat28.prj

PROJCS["MGI_Ferro_M28",
GEOGCS["GCS_MGI_Ferro",
DATUM["D_MGI",
SPHEROID["Bessel_1841",6377397.155,299.1528128]],
PRIMEM["Ferro",-17.66666666666667],
UNIT["Degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["False_Easting",150000.0],
PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",28.0],
PARAMETER["Scale_Factor",1.0],
PARAMETER["Latitude_Of_Origin",0.0],
UNIT["Meter",1.0]]

GRASS version: 6.4.3svn
GRASS SVN Revision: 56413
GIS Library Revision: 50937 (2012-02-25)
GDAL/OGR: 1.9.2
PROJ4: Rel. 4.8.0, 6 March 2012
Python: 2.7.4
wxPython: 2.8.12.1
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)

Select WKT or PRJ file

g.region -p
projection: 99 (Transverse Mercator)
zone: 0
datum: hermannskogel
ellipsoid: bessel
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Transverse Mercator
proj : tmerc
datum : hermannskogel
ellps : bessel
lat_0 : 0
lon_0 : 28
k : 1
x_0 : 150000
y_0 : 0
pm : ferro
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1

g.proj -j
+proj=tmerc
+lat_0=0
+lon_0=28
+k=1
+x_0=150000
+y_0=0
+pm=ferro
+no_defs
+a=6377397.155
+rf=299.1528128
+towgs84=653.000,-212.000,449.000
+to_meter=1

no asking which transformation should be used.

"Used in whole hermannskogel region: towwgs84=653.000,-212.000,449.000" is
preselected, but not the best e.g. if location used for Austria.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/help-with-testing-the-location-wizard-for-the-upcoming-release-tp5055791p5055901.html
Sent from the Grass - Users mailing list archive at Nabble.com.

6

Hi,

Using
grass64_release
revision revision 56596

I did not come across any problems in creating Locations (from custom prj parameters, from a georeferenced shape file, or directly from a prj file).

1.
Location created from georeferenced data file
[shape file from ArcGIS]

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
ellps : grs80
lat_1 : 64.25
lat_2 : 65.75
lat_0 : 65
lon_0 : -19
x_0 : 500000
y_0 : 500000
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1
(Wed Jun 5 17:35:28 2013) Command finished (0 sec)

2. g.proj -p [on location created using custom PROJ.4 parameters:
---
# ISN93 / Lambert 1993
<3057> +proj=lcc +lat_1=64.25 +lat_2=65.75 +lat_0=65 +lon_0=-19 +x_0=500000 +y_0=500000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
---
]

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
ellps : grs80
lat_1 : 64.25
lat_2 : 65.75
lat_0 : 65
lon_0 : -19
x_0 : 500000
y_0 : 500000
towgs84 : 0,0,0,0,0,0,0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1
(Wed Jun 5 17:38:50 2013) Command finished (0 sec)

3. Location created reading projection and datum terms from a PRJ file
[from a shape file folder from ArcGIS]

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
ellps : grs80
lat_1 : 64.25
lat_2 : 65.75
lat_0 : 65
lon_0 : -19
x_0 : 500000
y_0 : 500000
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1
(Wed Jun 5 17:42:37 2013) Command finished (0 sec)

Jon

On 26 May 2013, at 13:20, Hamish wrote:

Hi, this is a general call for help.

if anyone/everyone is able to help test, we have made some fixes
to the wxGUI new location wizard since 6.4.3rc3, which really
need to be tested well before the final release. We think all is
ok now, but a messed up location projection definition and ruin
everything downstream in the location, so it's an important
thing to be totally sure of.

since there are so many projections and datums and ways to
select them, it's pretty hard to test for "working/not working"
as we usally could do. Please try throwing your local odd-ball
CRS at it and see what happens. (check all the way through to
'g.proj -p' and 'g.proj -j' in the final location session. make
sure it does what you'd expect it to do.

specifically how datum transforms are handled, and CRSs without
a specificed datum or specified datum terms; usuing all methods
of defining the projection system. see trac issues #1849 and
#1967 for further details.

known issues:
users of proj 4.7.0 and 4.8.0 will get different results for
the default datum transform terms. (PROJ.4 now decides differently,
beyond our control)
when reading from a .prj or WKT file, or creating from a geo-
referenced file, with unspecified datum transform opts, you will
not be prompted to enter them. the location will be created not
mentioning them, but in the background PROJ.4 will assign some
default value (of its choosing) silently.

for those who use Subversion and compile, you know what to do;
for those who don't, nightly test builds are available for Windows
and Ubuntu.

thanks a bunch,
Hamish
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

7

Should have mentioned the platform: Mac OSX 10.7.5

On 5 Jun 2013, at 17:54, Jon Eiriksson wrote:

Hi,

Using
grass64_release
revision revision 56596

I did not come across any problems in creating Locations (from custom prj parameters, from a georeferenced shape file, or directly from a prj file).

1.
Location created from georeferenced data file
[shape file from ArcGIS]

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
ellps : grs80
lat_1 : 64.25
lat_2 : 65.75
lat_0 : 65
lon_0 : -19
x_0 : 500000
y_0 : 500000
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1
(Wed Jun 5 17:35:28 2013) Command finished (0 sec)

2. g.proj -p [on location created using custom PROJ.4 parameters:
---
# ISN93 / Lambert 1993
<3057> +proj=lcc +lat_1=64.25 +lat_2=65.75 +lat_0=65 +lon_0=-19 +x_0=500000 +y_0=500000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
---
]

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
ellps : grs80
lat_1 : 64.25
lat_2 : 65.75
lat_0 : 65
lon_0 : -19
x_0 : 500000
y_0 : 500000
towgs84 : 0,0,0,0,0,0,0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1
(Wed Jun 5 17:38:50 2013) Command finished (0 sec)

3. Location created reading projection and datum terms from a PRJ file
[from a shape file folder from ArcGIS]

g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
ellps : grs80
lat_1 : 64.25
lat_2 : 65.75
lat_0 : 65
lon_0 : -19
x_0 : 500000
y_0 : 500000
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1
(Wed Jun 5 17:42:37 2013) Command finished (0 sec)

Jon

On 26 May 2013, at 13:20, Hamish wrote:

Hi, this is a general call for help.

if anyone/everyone is able to help test, we have made some fixes
to the wxGUI new location wizard since 6.4.3rc3, which really
need to be tested well before the final release. We think all is
ok now, but a messed up location projection definition and ruin
everything downstream in the location, so it's an important
thing to be totally sure of.

since there are so many projections and datums and ways to
select them, it's pretty hard to test for "working/not working"
as we usally could do. Please try throwing your local odd-ball
CRS at it and see what happens. (check all the way through to
'g.proj -p' and 'g.proj -j' in the final location session. make
sure it does what you'd expect it to do.

specifically how datum transforms are handled, and CRSs without
a specificed datum or specified datum terms; usuing all methods
of defining the projection system. see trac issues #1849 and
#1967 for further details.

known issues:
users of proj 4.7.0 and 4.8.0 will get different results for
the default datum transform terms. (PROJ.4 now decides differently,
beyond our control)
when reading from a .prj or WKT file, or creating from a geo-
referenced file, with unspecified datum transform opts, you will
not be prompted to enter them. the location will be created not
mentioning them, but in the background PROJ.4 will assign some
default value (of its choosing) silently.

for those who use Subversion and compile, you know what to do;
for those who don't, nightly test builds are available for Windows
and Ubuntu.

thanks a bunch,
Hamish
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

8

Hamish wrote:

Hi, this is a general call for help.

Hi,

if anyone/everyone is able to help test, we have made some fixes
to the wxGUI new location wizard since 6.4.3rc3, which really
need to be tested well before the final release. We think all is
ok now, but a messed up location projection definition and ruin
everything downstream in the location, so it's an important
thing to be totally sure of.

since there are so many projections and datums and ways to
select them, it's pretty hard to test for "working/not working"
as we usally could do. Please try throwing your local odd-ball
CRS at it and see what happens. (check all the way through to
'g.proj -p' and 'g.proj -j' in the final location session. make
sure it does what you'd expect it to do.

specifically how datum transforms are handled, and CRSs without
a specificed datum or specified datum terms; usuing all methods
of defining the projection system. see trac issues #1849 and
#1967 for further details.

[..]

Below, maybe not exactly something that helps the testing process... but,
anyway here it goes: I guess it is not possible to follow the good old text-
based way in building a custom coordinate system.

For example, like

#####################################################################
grass64 -text

[snip]

LOCATION: hgrs87_test______________ (enter list for a list of locations)
MAPSET: PERMANENT________________ (or mapsets within a location)

DATABASE:
/geo/grassdb/testing_________________________________________________

           AFTER COMPLETING ALL ANSWERS, HIT <ESC><ENTER> TO CONTINUE
                            (OR <Ctrl-C> TO CANCEL)

#####################################################################

Would you like to create location <hgrs87_test> ? (y/n) [y]

#####################################################################

To create a new LOCATION, you will need the following information:

1. The coordinate system for the database
        x,y (for imagery and other unreferenced data)
        Latitude-Longitude
        UTM
        Other Projection
2. The zone for the UTM database
   and all the necessary parameters for projections other than
   Latitude-Longitude, x,y, and UTM
3. The coordinates of the area to become the default region
   and the grid resolution of this region
4. A short, one-line description or title for the location

Do you have all this information? (y/n) [y]

#####################################################################

Please specify the coordinate system for location <hgrs87_test>

A x,y
B Latitude-Longitude
C UTM
D Other Projection
RETURN to cancel

D

#####################################################################

Other Projection coordinate system? (y/n) [y]

#####################################################################

Please enter a one line description for location <hgrs87_test>

Hellenic Geodetic Reference System 1987

=====================================================
Hellenic Geodetic Reference System 1987

ok? (y/n) [y]

Please specify projection name
Enter 'list' for the list of available projections
Hit RETURN to cancel request

tmerc

Do you wish to specify a geodetic datum for this location?(y/n) [y]

Please specify datum name
Enter 'list' for the list of available datums
or 'custom' if you wish to enter custom parameters
Hit RETURN to cancel request

custom

Please specify ellipsoid name
Enter 'list' for the list of available ellipsoids
Hit RETURN to cancel request

grs80

Please specify datum transformation parameters in PROJ.4 syntax. Examples:
        towgs84=dx,dy,dz (3-parameter transformation)
        towgs84=dx,dy,dz,rx,ry,rz,m (7-parameter transformation)
        nadgrids=alaska (Tables-based grid-shifting transformation)
Hit RETURN to cancel request

towgs84=-199.87,74.79,246.62,0,0,0,0

Parameters to be used are:
"towgs84=-199.87,74.79,246.62,0,0,0,0"
Is this correct?(y/n) [y]

#####################################################################

Enter Scale Factor at the Central Meridian [1.0000000000]: 0.9996

    Enter Central Parallel (23N) :0

    Enter Central Meridian (96W) :24

Enter False Easting [0.0000000000]: 500000

Enter False Northing [0.0000000000]:
Enter plural form of units [meters]:

#####################################################################

...which will define a Location

--%<---
g.proj -p

-PROJ_INFO-------------------------------------------------
name : Transverse Mercator
towgs84 : -199.87,74.79,246.62,0,0,0,0
proj : tmerc
ellps : grs80
a : 6378137.0000000000
es : 0.0066943800
f : 298.2572221010
k_0 : 0.9996000000
lat_0 : 0.0000000000
lon_0 : 24.0000000000
x_0 : 500000.0000000000
y_0 : 0.0000000000
-PROJ_UNITS------------------------------------------------
unit : meter
units : meters
meters : 1.0
--->%--

All is ok using the correct epsg code (e.g. 2100). However, what about
replicating the above process with the new Wizard?

Thanks, Nikos

9

Nikos wrote:

Below, maybe not exactly something that helps the testing
process... but, anyway here it goes:

everything helps :slight_smile:

I guess it is not possible to follow the good old text-
based way in building a custom coordinate system.

So I guess you are missing the ability to set the datum
transform terms? (+towgs84=)

-> "Select coord sys parms from a list"
-> tmerc
-> enter coeff's
-> ellipsoid only
-> grs80
-> summary: +towgs84=0.0,0.0,0.0 :frowning:

All is ok using the correct epsg code (e.g. 2100).
However, what about replicating the above process
with the new Wizard?

epsg gives +datum=GGRS87, but that is not known to 'proj -ld'
or GRASS's datum.table and datumtransform.table AFAICS.
?

so the first thing to do is add it to datum*.table, then
make the location wizard aware of datumtransform.table, and
also have the location wizard have an option to prompt for
custom datum transform terms.

thanks,
Hamish