[GRASS5] Projection transform

[Frank Warmerdam]

Andreas Lange wrote:
> Hi all,
> 
> i have to underline what Morten said. 
> The problem is that much of the projection setup is now hardcoded into
> g.setproj.
> For example, it is hardcoded into g.setproj that some projections have
> fixed ellipsoids:
> if ((proj_index == ALSK) || (proj_index == GS48) || (proj_index ==
> GS50)) {
>   sprintf(spheroid, "%s", "clark66");
> ...
> }
> 
> This has to be hardcoded for obvious reasons into m.proj, too. 
> 
> This is very bad design. We need to implement a new database, which
> contains projections, names, ellipsoids/spheroids, datum shift
> parameters and all the dependencies. (it comes to my mind that this is
> also a candidate for new library, as the key/value processing for the
> etc tables is cloned several times in the gis libray code). 
> Then we need to implement a set of library functions that manage/setup
> all this and call the proj library for the actual processing. 

Folks,

I agree with the above.  I would only add that I would like to see as much as
possible of this done in an integrated fashion with PROJ.4.  Obviously some
of the interactive functions to ask for projection parameters will be grass
specific, but I would like to see any required tables of datums, ellipsoids
and so forth handled from within PROJ.4.  I am happy to extend PRO.4 to make
more of it's internal lists accessable to applications, and to extend them.

One of the problems I have now writing translators between GRASS and other
systems is some of the ideosyncratic projection issues in GRASS.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent