[GRASS5] Fixing up projection related code...

[Paul Kelly]

Hello Frank

On Wed, 12 Mar 2003, Frank Warmerdam wrote:

> Paul Kelly wrote:
> >
> > So after selection, the datum transformation parameters will be stored in
> > the PROJ_INFO file under the new key 'datumparams'.
>
> Do correctly understand then that each named datum in the datumtransform
> table will have a *default* transformation to use with the datum, but that
> by explicitly including the transformation in the PROJ_INFO file it is
> intended to be easy for users to alter what transformation values are used?

Yes I intended that if, for example, additional datum transform keywords
(other than towgs84 or nadgrids) are added to PROJ.4 in the future only
the PROJ_INFO file will need to be modified to take advantage of this.

I suppose it is implicit that there is a default transformation (as
defined by dx= dy= dz= in datum.table); this is really just for legacy
compatibility with the way datums are currently implemented in GRASS.
Both the current g.setproj and my changed version explicitly write the
transformation parameters into the PROJ_INFO file and these are what are
used. So only in the unlikely situation of the datum keyword being there
on its own with no parameters will the default transformation be used.

> >>I do think that import programs that report projection information, or
> >>offer to setup new locations (like r.in.gdal) should offer the transformation
> >>used if possible.
> >
> > I don't really think that programs that import data should try to
> > reproject it. This is getting too complicated and then there would be too
> > many modules to try to keep up to date. The conventional GRASS way seems
> > to be to import the data into a location with the correct projection, then
> > reproject it to your target location using [rsv].proj.
>
> I meant that an import program like r.in.gdal should be able to associate
> particular datum shift transformation information with the dataset.  That is

Yes, sorry didn't read your comment there properly at all. r.in.gdal does
conform to that convention exactly. I was actually thinking more of
v.in.gshhs which I was looking at earlier today. It offers to reproject
from lat/long into the location it is being imported into, but it is
complicated by the fact that GSHHS data doesn't have an associated ellipsoid
or datum. The program must decide which ellipsoid to associate the
lat/long data with. (Obvious choice: same one as the location the data is
being imported into, but still it should be the user making that decision
and not hidden inside the program.)

> if it knows that a non-default datum shift should be used it could populate
> the PROJ_INFO file with it.  This would seem to be very easy with your
> approach.

Yes definitely that would be easily possible.

> I don't see the prime meridian as an attribute of the datum, though it is
> an attribute of a geographic coordinate system based on the datum.  That is,
> I think the prime meridian handling is orthagonal to the datum shift info.

Well it looks like that can wait until co-ordinate systems are implemented
then. Good.

Thank you for the feedback

Paul