{{{
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
}}}
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.
#428: g.proj -c defines wrong default values
-----------------------------------------+----------------------------------
Reporter: martinl | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Default | Version: 6.4.0 RCs
Keywords: projection, create location | Platform: All
Cpu: All |
-----------------------------------------+----------------------------------
Comment(by 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)