[GRASS5] Fixing up projection related code...

[Paul Kelly]

A little bit more of this is done now...

On Mon, 26 Aug 2002, Eric G. Miller wrote:

> I've been looking at some of the projection related code, and I'm
> trying to come up with a course of action to clean it up in places.
> Eventually, this should result in:
>
> 1.  Having better defined projection files.
> 2.  Creation of a set of predefined well known coordinate systems
>     files.
> 3.  A rewrite of g.setproj with these ideas in mind:

Not re-written yet, just fixed up a bit. Re-write with a GUI can go in
GRASS 5.1

>     -  Types of coordinate system are XY, geographic, or projected
>     -  Ask users if they want to use a predefined coordinate
>        system (state plane, UTM, others...) or if they want to
>        define their own.  Having a collection of predefined
>        coordinate systems where the user can just pick it by
>        "name", will simplify user's lives as well as insuring the
>        info is correctly specified.
>     -  Both projected and geographic require datum/ellipsoid info.
>        Ask for datum first, ellipsoid parameters can be looked up
>        from it.  Otherwise, just get ellipsoid parameters.

This is now mostly sorted out in the correct order

>     -  Remove state plane from projection list, it'll be covered
>        by the predefined systems above (though still need units...)
>     -  Allow user defined datums??

This is possible; the PROJ.4 datum string (e.g. "towgs84=...") needs to be
known

>     -  Other...?
> 4.  Have transparent handling for a variety of datum transformations
>     incorporated into the library wrappers for proj4.  Most of the
>     necessary work for the transformations has been done by Andreas
>     Lange, it's a matter of working in the strategies.  Perhaps the
>     programs can pass on a preferred stategy when specified by the
>     user (for instance, NADCON vs. Bursa Wolf).

Anything possible with a parameter in the string passed to PROJ.4 can now
be used by including it in the 'datumparams: ...' line in the PROJ_INFO
file (or specify a custom datum in g.setproj). g.setproj can be re-run to
change the transformation parameters, though it would be wise to make a
copy of the current projection parameters by running g.projinfo first;
probably easier just to edit the PROJ_INFO file directly if you know the
parameters you want.

>     Get rid of GRASS
>     copy of proj4 and make a dependency on proj4 >= whatever version.

Today I have done this (well not get rid of the GRASS copy; I just made it
optional to use an external PROJ.4 library). This can be invoked by using
the --with-proj=yes option to the configure script and the usual
--with-proj-includes=... --with-proj-libs=...  also apply if needed. It
needs to be PROJ.4.4.6 or later as the earlier versions had some bugs in the
datum transformations.

The changes required to the modules that use proj were:
1. Include gprojects.h instead of projects.h
2. Include $(PROJINC) in the EXTRA_CFLAGS in the Gmakefile

I had to split the projects.h up into PROJ.4 internal stuff and bits
specific to the GRASS proj wrapper functions, and rename it so it wouldn't
conflict with an externally-installed copy of PROJ.4.

As far as I can see, under some circumstances a 'make clean' might be
needed, or maybe just delete the old libproj.a in src/libes/LIB.arch. The
library containing the GRASS proj wrapper functions is now called libgproj
instead of libproj, again so as not to conflict with the external version.

>     It should be a fatal error if a datum transformation is impossible.
> 5.  Miscellaneous:
>     -  Specify vertical datums? MSL, ellipsoid height, others... Mostly
>        for documentation, since very few can be translated.
>     -  Add missing usfoot/usfeet <-> metric conversions. usinch? usmile?
>     -  Add prime meridian as datum parameter.

Frank said he didn't see this as an attribute of the datum, but of the
co-ordinate system, so I have left it for now.

> Coordinate_Systems/
>    Projected/
>       North_American/
>          State_Plane_1927/
> 	    State_Plane_Alabama_East
> 	    State_Plane_Alabama_West
> 	    ...
> 	    State_Plane_Wyoming_West_Central
> 	 State_Plane_1983/
> 	    ...
>
> This kind of thing is easy enough to add to, and g.setproj could
> just use directory traversals until the user selects a file, then
> just copy the file to the new location...

Frank thought it would be a good idea to put this into PROJ.4, also I
don't know how to do directory traversals, so I will forget about this
for now.

One point that will need to be emphasised (for American users I suppose)
when this work is incorporated into a release of GRASS: The last few releases
(5.0.0pre4 to 5.0.1 approx.) have, for the specific case of transforming NAD27
to NAD83 and vice versa, ignored the dx dy dz-style transformation parameters
given in the PROJ_INFO file and used the nadcon conversion tables. Under
the new 'improvements' the 3-parameter shift will be used if it is
specified in the PROJ_INFO file, and g.setproj will need to be re-run on
the location (or the PROJ_INFO file edited manually) to remove the dx dy
dz and add a 'datumparams: nadgrids=conus' line.

Hoping for some testing and feedback,

Paul