[Proj] "Double Ellipsoid" error, reproduction

[Christopher Barker]

First, let me say that I am a Scientist/Engineer first, a Software 
developer second, and a cartographer a very, very, very, distant third...

So take my comments as you will.

Gerald I. Evenden wrote:
> Clearly note: that it was and still is quite clear that datum conversions and 
> projection operations are totally different, mathematically and logically, 

Are they really so different mathematically? I see both as a transform 
from one coordinate system to another. I suppose that a projection is 
from a spheroidal(or ellipsoidal) system to a Cartesian one, if that's 
what you mean. Though if you want to go from one projection to another, 
then it's still a Cartesian to Cartesian transform -- do you always go 
through geo-coords to get from one projection to another?

> there is *no* reason to combine the operations into one procedure.  
> Programmatically combining the operation made no sense and was a clear 
> violation of modular programming practices.

Here is where a take issue -- but maybe it's only with what you mean by 
"combining". It seems to me that datum conversion and projecting share a 
great deal from a programming perspective. Certainly I/O, but also data 
needs (ellipsoids, etc) and others.

It also seems that EPSG has, like it or not, merged the two concerns and 
thus software that deals with EPSG codes needs to work with the two 
together.

> On the surface I find nothing wrong with cs2cs and it certainly should be a 
> valuable program.  However, I feel that the internals are put together in a 
> manner that first: made it harder to develop and now: much more difficult to 
> maintain.

I know nothing of the internals, so I can't comment.

But from a software development perspective, I feel strongly that one 
should think in terms of libraries first, and applications second. the 
projections+datums library should provide all the tools required to make 
it easy to write cs2cs, and I think this does mean a certain merging, or 
at least sharing of routines, between projection support and datum support.

 > By combining datum and projection operation internally with
> modifications of proj.4 it is impossible to easily upgrade cs2cs when 
> corrections or improvements of libproj4 become available.

That has nothing to do with cs2cs, it has to do with the fact that proj 
has been forked, and the two forks are not API compatible. I suppose 
PROJ.4 could have been built as a library that used libproj, adding the 
extra datum support, so that a fork would not have been required, but 
I'm not going to second-guess anyones decisions from years back.

It seems that all (most?) agree that PROJ.4 could use some refactoring 
(and maybe re-naming) -- but who has time to do it?

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov