Opened 14 years ago

Closed 10 years ago

Last modified 10 years ago

#428 closed defect (invalid)

g.proj -c defines wrong default values

Reported by: martinl Owned by: grass-dev@…
Priority: major Milestone: 6.4.0
Component: Projections/Datums Version: 6.4.0 RCs
Keywords: projection, create location Cc:
CPU: All Platform: All


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
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
unit       : meter
units      : meters
meters     : 1


Change History (7)

comment:1 by neteler, 14 years ago

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

Compare also


comment:2 by martinl, 14 years ago


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


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

comment:3 by martinl, 14 years ago

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

comment:4 by pkelly, 14 years ago

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.

comment:5 by hamish, 11 years ago

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)

comment:6 by hamish, 10 years ago

Resolution: invalid
Status: newclosed

close as invalid?

reopen if that isn't the case.

comment:7 by hamish, 10 years ago

Component: DefaultProjections/Datums
Note: See TracTickets for help on using tickets.