[OSRS-PROJ] Datum Shifting

[Gerald I. Evenden]

Response embedded below.

__________________________________________________
Jerry Evenden and the Low Riders, Katie and  Daisy May
gevenden at capecod.net  http://www.capecod.net/~gevenden
----- Original Message -----
From: Frank Warmerdam <warmerda at home.com>
To: <osrs-proj at remotesensing.org>
Sent: Tuesday, July 04, 2000 10:26 PM
Subject: Re: [OSRS-PROJ] Datum Shifting


> "Gerald I. Evenden" wrote:
    ...
> > You have two basic problems: 1) cartographic projections and 2) datum
> > shifts.
> > All the factors involved are very nicely separated and can be similarly
> > treated
> > with separate pieces of software.  Problem 1 seems to be niecely solved
and
> > problem 2 seems easily solvable in a similar manner.  Why throw
everything
> > into one stew pot?  It just makes the stirring more difficult.
>
> You are absolutely correct that what I propose is extending PROJ.4 from
> being a cartographic projections library system to being a cartographic
> coordinate system translation library system.

Here is the core of our disagreement.  I would have libproj.a *and*
libdatum.a
while you would have libproj.a absorb the contents of libdatum.a or one
unified library.  I argue for the separation of the two on two points:

1) the maintenance and development of code for the two problems may
be performed by geeks who are experts in the respective fields and don't
want to be nor need to be bothered by the details of extraneous, unrelated
material.

2) users may be of similar exclusivity and could care less about or get
confused about details unrelated to their interests.  Keep it simple.

> One viable solution to building a broader coordinate system translation
> package would be to build separate components for datum shifting as
> an unrelated API, and applications using the libraries would be
responsible
> for calling them in appropriate sequence.  At the command line, programs
> like proj could be used via pipes in combination with other programs
> doing datum shifting.
>
> However, I would claim that it is "natural" to consider coordinate
> system translation a relatively unified task, and that there are good
> reasons to offer a unified API to accomplish them.
>
>  o It is useful to have a unified, and reasonably consistent way of
>    describing coordinate systems as a whole for users.  For me PROJ.4
>    projection parameter syntax is more than just a way to invoke the
``proj''
>    command.  They are a format for describing projections (and soon
hopefully
>    coordinate systems).   I will potentially want to describe other
aspects
>    of my coordinate system via the syntax as well, such as vertical
datums.
>
>    In my mind one of PROJ.4's great advantages over GCTP is a consistent
>    user accessable textual syntax for describing projections.

We certainly agree there.  GCTP's method of control input was archaic and
virtually unchanged since its inception in the late 60's.  A good deal of
the
problem was the mindset of FORTRAN programming.

>  o Applications will generally still need a unified API to handle
coordinate
>    system transformations.  Why make every application that uses PROJ.4
>    handle the integration of it with a datum shifting system?  The result
>    so far has been a number of systems developed with missing, or poorly
>    integrated datum shifting capability because it wasn't conveniently
>    handled by PROJ.4 (notably OGDI, GRASS, and my own OGRSpatialReference
>    stuff).
>
> An argument could be made that adding datum shifting to libproj.a (and
> libproj.so) will make it bigger for people who don't even care about
> datum shifting.  Similarly you could make a case that adding coordinate
> system to coordinate system transformation to the proj command will
> complicate the command syntax.  I would argue that datum shifting adds
> relatively little new code to the library, but I am not so sure about
> overloading of the proj command.
>
> My fear in introducing a separate command for coordinate system to
> coordinate system conversion is that I will need to reimplementing
> essentially all of the functionality already in proj.c, and we will
> end up with two commands that operate fairly similarly but with
> one being a superset of the other.  Assuming that the proj command
> retains backward compatibility to the current argument syntax, what
> argument would you provide against extending it?
>
> Given the feedback I have seen so far, I think there is justification
> for adding datum shifting (and other coordinate system to coordinate
> system transformation capabilities) to PROJ.4.  However, I am less
> convinced of the nead for a unified from/to style of proj command.

As an alternative, I will present my initial thoughts on how to organize
the problem.  I see it layered in the following manner:

                 coordinate system to coordinate system (cs2cs)
                           driver main  (keyword control data)
                       ____________|___________
                       |                     |                       |
                 libproj.a         libdatum.a        libcs2cs.a(?)

Libdatum.a code would have initialization and entry point code similar
to libproj.a and an identical argc/argv control input of keywords.  Note
that
I do not see implementation of keyword input system for libdatum as being
very difficult as some code and techniques can be stolen from libproj.

The only task of cs2cs is splitting the proj keywords for the input system
and the output system.  For the input inverse projection nothing has to be
done to the argv list---remember, proj ignores the second of duplicate
keywords.  But the output forward projection needs to have the input
keywords removed prior to calling the ininitialization.  If the proposed
"+to" keyword is used, the massaging of the parameters is brutally simple
and I'll leave that as an exercise. ;-)  If you want to add the +from, OK
but
it will be ignored.

Example:

    cs2cs [input proj keywds] +to [output proj keywds] [datum keywds]

Datum keywords can be placed anywhere and the only item I would be
sure to put into the libdatum initializer is that if datum keys are absent,
then
no datum conversion is performed!

About all cs2cs is doing is manipulating the argv pointer and controlling
the I/O.  If I were writing it, I'd take proj.c and  rehack it by stripping
out some of the proj type dependencies and preserving the format
and file control.

As for libdatum, I'd look at libproj argument handling routine and rehack
those for the new problem.  I think the argument handling for libdatum
would be a little simpler.

The emphasis here is libproj is unscathed and libproj and libdatum are
independent code.  Simplicity is the ultimate keyword.


----------------------------------------
OSRS PRoject PROJ Discussion List
To Subscribe: send a message to majordomo at remotesensing.org with 'subscribe osrs-proj' in the body
To Unsubscribe: send a message to majordomo at remotesensing.org with 'unsubscribe osrs-proj' in the body
To Report Problems: send a message to owner-osrs-proj at remotesensing.org