g.proj -c defines wrong default values

[martinl]

Creating location with g.proj, e.g.,

g.proj -c proj="+proj=krovak +a=6377397.155 +rf=299.1528128 +no_defs +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56" location=s-jtsk

some unwanted default values are defined, why?

 g.proj -p
-PROJ_INFO-------------------------------------------------
name       : Krovak
proj       : krovak
ellps      : bessel
lat_0      : 0                             <- here
lon_0      : 0                             <- here
alpha      : 0                             <- here
k          : 1                             <- here
x_0        : 0                             <- here
y_0        : 0                             <- here
towgs84    : 570.8,85.7,462.8,4.998,1.587,5.261,3.56
no_defs    : defined
-PROJ_UNITS------------------------------------------------
unit       : meter
units      : meters
meters     : 1

Martin

[neteler]

I assume that some *should* be defined... at least EPSG 2065 suggests so.

Compare also ​http://trac.osgeo.org/gdal/ticket/2559

Markus

[martinl]

Compare:

echo "15 50" | proj +proj=krovak +ellps=bessel +no_defs +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to_meter=1.0
-703105.69      -1058219.60

echo "15 50" | proj +proj=krovak +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +units=m +no_defs
-703105.69      -1058219.60

and

echo "15 50" | proj +proj=krovak +lat_0=0 +lon_0=0 +k=1 +x_0=0 +y_0=0 +no_defs +a=6377397.155 +rf=299.1528128 +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to_meter=1
1067856.48      -996126.10

[martinl]

Generally speaking, g.proj -c should not define any default values, if user decide not to define them. Or am I wrong?

[pkelly]

Without looking in depth, it seems to me it is a bug / "feature" of PROJ that the first syntax, i.e. with no parameters specified, actually works. For clarity it is best to specify the parameters.

How g.proj works is it uses OGR functions to parse and validate the PROJ.4 string before converting it into GRASS format. OGR interprets the string differently from PROJ.4 - internally it converts it to WKT format so I'm guessing that it requires the parameters to be specified, and because none are there it sets them to zero. Then when OGR exports the validated projection back to g.proj the parameters will be set to zero.

Perhaps the best fix is for PROJ.4 to be modified so it does not accept the syntax with no parameters specified. But that is not good as it will break existing installations where people use the syntax with no parameters.

[hamish]

close as invalid? (the math needs some sort of default coefficient if it is to run; if that is to be considered an error it needs to be a request in the proj4 tracker, g.proj isn't involved in the projection logic at that level)

[hamish]

close as invalid?

reopen if that isn't the case.