[GRASS5] datum transforms...

[Paul Kelly]

Hello Frank

On Wed, 15 Jan 2003, Frank Warmerdam wrote:

> I have tentatively added the potsdam, carthage, hermannskogel and ire65
> datums to the pj_datums.c in PROJ.4, even though I am hesitant to extend the

There are lots more datums in the GRASS CVS version of pj_datums.c than
you can see in the diff file, if you are interested.

> datums list untill such time as I have a meaningful naming convention for
> the datums.  I am sticking with the upper case names for WGS84, GGRS87,
> NAD83 and NAD27.  Why does GRASS seem to force these to lower case?  I hope
> the comparison logic would be case insensitive.

Some of the names are different (not just in case) from the PROJ.4
originals as well, especially in the ellipse table. But having these
already consistent with the internal GRASS names made the changes I made
much easier to do. I've no idea why it was changed like that but it was
definitely the simplest way to get it working.

A slightly related point: I had a problem with r.in.gdal automatically
creating a location for me (from an Aster DEM) using the ellipse name
'WGS84'. I couldn't reproject it and the problem was the capital letters
but it was a long time after I'd re-created the projection information
manually using g.setproj and got r.proj working that I realised what the
problem was.

> For me, the key things are to try and minimize the differences in the core
> of PROJ.4 between GRASS and the public PROJ.4 release.  In GRASS 5.1 and
> beyond, as GRASS becomes more shared library oriented I would hope that

I don't like relying on shared libraries. It is really tedious to get them
all installed and configured and can take hours or a day at least for each
one. It is not very convenient for users of minority operating systems on
which the software has more often than not not been tested before release. I
have not even been able to get the standard PROJ.4 release to compile on
my IRIX system (libtool problem I think) but it is OK as I don't need it
on its own.

If there is one version compiled as part of GRASS that has all the
features GRASS programs need, then it can stay fixed like that for ever
and there will be no problems with new releases of the library introducing
bugs unrelated to GRASS (I'm not talking about PROJ.4, just generally).

> GRASS would be able to work with pre-installed PROJ.4 libraries instead of
> including a static copy in libgis.  If this is ever to work we have to ensure
> that the GRASS specific logic for PROJ.4 use is embedded in the GRASS
> wrapper functions (such as pj_do_transform()), not in PROJ.4 code itself.

That sounds like a good idea, what we are already doing for ll -> latlong.
We can't change existing PROJ_INFO files in GRASS installations all over
the world as Morten Hulden already said, so the GRASS internal names have
to stay consistent.

Paul