[GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing

Markus Neteler neteler at itc.it
Thu May 23 09:55:53 EDT 2002


On Thu, May 23, 2002 at 12:52:12PM +0200, Morten Hulden wrote:
> 
> On Thu, 23 May 2002, Markus Neteler wrote:
> 
> > the "ellips=name" is not put into the structure "in_proj_keys".
> > Looking into the Changelog, I found:
> >   2001-10-23 03:33  frankw
> >         * get_proj.c: dont pass through ellps= if we have defining
> >         parameters
> > 
> > The former version of PROJ4 in GRASS was able to deal with this case,
> > I recall that the change done by Frank was required to work around
> > problems with r.in.gdal.
> 
> The way grass used to co-operate with proj was that grass _never_ passed
> the ellipsoid name to proj, but always uses the a and e2 values instead. a
> and e2 were taken from the PROJ_INFO file, or (in the case of m.proj)  
> looked up from grass' ellipsoid table. The ellipsoid name in PROJ_INFO was
> only there for display, but is never really used, unless someone added or
> changed a module to pass the name to proj.
> 
> If proj itself would have have changed so +ellps= is a required argument,
> no projection routine in grass would work. I guess this is unlikely.
> 
> Morten Hulden

So: one problem is solved (above with the ellps).
[for env.c and the new datum functions see Roger's new mail).

The reason why I had above problem was (of course) an interference
of a new feature. Jaro Hofierka and me currently try to add the
Krovak projection to GRASS (Czech republic). This requires the
"hermannskogel" datum which is not present in PROJ4. No surprise
that it wasn't working. However, the PROJ4 error messages are
not really helpful.

diff pj_datums.c.old pj_datums.c
77a78
> "hermannskogel", "towgs84=653.0,-212.0,449.0",  "bessel", "Hermannskogel",

Summary of this long thread:
- Open problems:
  - bugfix needed in src/libes/gis/env.c
  - bugfix needed for G_database_datum_name() and G_database_ellipse_name()
    in src/libes/gis/proj3.c in case datum is absent in PROJ_INFO

- solved issue (we are verifying now the results):
  - implementation of Krovak and Krovakyx (with reverted coordinate system
    as usually used for Czech/Slovak(?) GIS data done
    If desired, I can upload to CVS/Head. It is a new feature
    (no flame war please).

   Proof (in a Krovakyx LOCATION):
   r.proj in=dgm1km loca=europa mapset=europa dbase=/ssi0/ssi/neteler/grassdata
Input:
Cols:   4800 (4800)
Rows:   6000 (6000)
North: 90.000000 (90.000000)
South: 40.000000 (40.000000)
West:  -20.000000 (-20.000000)
East:  20.000000 (20.000000)
ew-res: 0.008333
ns-res  0.008333
 
Output:
Cols:   2000 (2000)
Rows:   3000 (3000)
North: -400000.000000 (-400000.000000)
South: -700000.000000 (-700000.000000)
West:  -1000000.000000 (-1000000.000000)
East:  -800000.000000 (-800000.000000)
ew-res: 100.000000
ns-res  100.000000
Allocating memory and reading input map... d.erase4%
 100%
Projecting... d.rast dgm1km
 100%

with PROJ_INFO
 name: Krovakxy
 datum: hermannskogel
 dx: 653.000000
 dy: -212.000000
 dz: 449.000000
 proj: krovakyx
 ellps: bessel
 a: 6377397.1550000003
 es: 0.0066743722
 f: 299.1528128000

Now Radim and me start to evaluate the error (due to ignored datum
transformation and missing triangulation points for S-JTSK = Krovakyx).

Markus



More information about the grass-dev mailing list