[OSRS-PROJ] Datum Shifting

[Martin Manningham]

Frank Warmerdam wrote:

> "Gerald I. Evenden" wrote:
> > > I am finally getting around to incorporating datum shifting support into
> > > PROJ.4, and I would be interested in some feedback on approaches.
> >
> > Got plenty.
> >
> > A hypercritical note here.  We are talking about the PROJ.4 library system.
>
> Gerald,
>
> I am not sure I see your point.  Is it just that it is properly titled as
> "The PROJ.4 Library System" or that PROJ.4 is primarily a library, and
> secondarily available as user tools?
>
> > Correct!  PROJ.x system is purely designed for cartographic projection
> > operations.
> > Same as NMD's GCTP.
> ...
> > Other than supplying the ellipsoid parameters, datums have nothing to do
> > with cartographic projections.  I suggest adding the above to PROJ.4 is
> > counter to the purpose of the package.
> ...
> > 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.
>
> 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.
>
>  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.
>
> > >  o Adding +proj=latlong as a legal "projection" meaning that the
> > coordinates
> > >    are in geodetic coordinates rather than a projection system.
> >
> > This one makes no sense to me.  Dummy argument?
>
> This is so that we can describe the geodetic coordinate system directly.
> Already systems like OGDI which use PROJ.4 as their projections library also
> use PROJ.4 syntax for describing coordinate systems.  OGDI has already adopted
> the convention of +proj=latlong meaning the coordinates are in lat/long.
>
> Best regards,
>

I could add one or two comments about the use of PROJ 4 in the OGDI. The
idea is to handle maps
represented and geo-referenced in a given coordinate system into a new
representation defined by a user.
The whole idea is to combine geographic informations and maps, vectorial
or imagery, from various sources
to a certain "view" or map. Of course, the "from/to" of PROJ 4 is not
applied directly, to transform from
one geographic coordinate to another, we must first perform a "from"
with a projection "A" and take the
result to perform a "to" with a projection "B".

I am not a mathematician, only a computer scientist. I agree with Frank
in this debate, the people who
need to transform coordinates usually also need to perform datum
transformation. And the only way to
ensure this is done properly is by integrating in a single library and
API all transformations (projection
and datum). It's obvious for me.

In the other hand (I agree with Mr Evenden here): Datum transformation
isn't as easy to handle than projection transformation. Most of the
time, this is only a shift applied to a certain system of coordinates of
a small map, and people are using tables to perform this operation.
Tables are difficult to handle since they could be big and their format
could change over time. But they are most of the time more flexible and
precise Of course, there is some mathematical transformations of the
requested shifts from one datum to another (nad27 to WGS84 or stuff like
this) and this must be put into consideration on this situation...
----------------------------------------
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