[GRASS5] Datum and g.setproj Improvements

[Paul Kelly]

Hello
I've made a few improvements, now commited to CVS, outlined below.

g.setproj:

1. When setting up a State Plane location, prompt for 27 or 83 specification

2. Get rid of the strange error message "Projection 99 does not support UTM
or LL" - couldn't see any reason for this

3. Ask for a datum before an ellipsoid and set the ellipsoid from the datum

4. Say what the current datum is and ask does the user wish to change this.

5. For State Plane co-ordinate system, prompt the user for US Survey Foot,
International Foot or Meter for the units

gislib:

6. G_ask_datum_name() changed to return the ellipsoid name as well as datum
name. If datum support is changed to include prime meridians this function
should return that as well.

7. New data file $GISBASE/etc/datumtransform.table to hold all the possible
sets of datum transformation parameters for all the datums (data). As Frank
pointed out there is no way to automatically determine which is the best or
most appropriate set of parameters so they must be presented to the user who
will choose. There is no point in GRASS pretending to the user that it can
pick the proper parameters when it can't. datumtransform.table has two
fields for "where used" and "comment" to provide plenty of information for
the user to select the best set of parameters for their location / project.

7. New function G_ask_datum_params() to interactively select a set of datum
transformation parameters for a particular datum.

8. Remove local function same() in src/libes/gis/get_ellipse.c for comparing
two ellipsoid names and use G_strcasecmp() instead. Change definition of
ellipsoid_table_file() reflect usage in rest of file.

projlib:

9. Print the PROJ.4 error message to stderr when a projection fails on
pj_do_proj()

10. Change and improve pj_get_kv() to find the datum transform parameters
from old and new-style PROJ_INFO files and pass them to PROJ.4 in the
correct format.

Nothing is super now but just some of it was very bad before and perhaps
not quite as bad and hard to work with now. In particular g.setproj needs
to be completely re-written.

The datum transformation capability has already been in GRASS for a few
weeks, but now the implementation is tider and different transformations
can be added without having to recompile, by adding them to
$GISBASE/etc/datumtransform.table and re-running g.setproj. g.projinfo can
be used to make a note of the old parameters before re-running g.setproj.

Programming notes:
I am still learning about string handling in C and I'm sure there are lots
of places where I could have implemented things more tidily. Feel free to
fix it up.
More improvements when I have time.

Once any bugs in this are sorted out the recent datum improvements will
probably be mature enough now to go into the release branch.

Paul