[OSRS-PROJ] Datum Shifting

[Frank Warmerdam]

"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 set the clouds in motion - turn up   | Frank Warmerdam, warmerda at home.com
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent
----------------------------------------
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