[Proj] "Double Ellipsoid" error, reproduction

[Gerald I. Evenden]

On Thursday 11 December 2008 1:51:27 pm Christopher Barker wrote:
> 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?

If one cares to get involved with the literature I think you will find that 
there is deep divide between those involved in these two subjects.  It has 
already been pointed out that the late John Snyder, a well recognized expert 
on cartographic projections, rarely, if ever, published a word on datums.  
And this division of interest is quite common.  Trying to smash material on 
the surface of an ellipsoid to a flat surface is quite a different subject 
than  moving objects around on the top of roughly the surface.

I think I pointed out that I was involved for years making maps and I never 
had to fuss with datums basically because all our data was of the same datum.
But I did have to know about projections because of dealing with a large 
number of local grid systems---all on the same datum.

If one is fairly parochial in the extent of their data, their interest in 
datum conversion may be quite limited if present at all.

> > 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.

For the most part there is precious little commonality other than the 
commonality of the chosen compiler language and the need for some 
mathematical background.  Personally, I find the datum problem somewhat dull
and a terrible disease inflicted upon us.  It is rather like the flu---we keep 
sneezing, coughing and have aching joints when we would like to speed on to 
the the fun part of drawing a picture.

> 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.

I do not understand how you  can say that.  Their bible, Notes #7, is clearly 
divided between the projections and datum shifting problems.  In many cases 
with small scale maps I could care less about datum differences because the 
error in positioning caused by such ignorance would be infinitesimally small.

> > 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.

They are certainly available.

> 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.

I would rephrase as "projection library and datum library".  I can make maps 
without the datum library.

>  > 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 has *everything* to do with the cs2cs problem.  Optimally done, the program 
would have been infinitely more easy to update and keep current with changes 
in either the projection or datum world, each world worked on by people with 
disparate interests.

> 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

Ah, the born defeatist.

-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist