[Proj] "Double Ellipsoid" error, reproduction

[Gerald I. Evenden]

On Monday 08 December 2008 4:35:50 pm Richard Greenwood wrote:
> On Mon, Dec 8, 2008 at 11:35 AM, Gerald I. Evenden
>
> <geraldi.evenden at gmail.com> wrote:
> > On Monday 08 December 2008 12:24:19 pm Frank Warmerdam wrote:
> >> Gerald I. Evenden wrote:
> >> > I think more desirable approach is to create a d2d program with
> >> > optional i/o filtering through projection procedures.  One might have
> >> > options like:
> >> >
> >> > d2d --in=EPSG1234 --out=NAD83_1105
> >> >
> >> > where --in and --out may refer to library systems but one can also
> >> > have
> >> >
> >> > d2d --in=proj=latlon --datum_in=xyx --datum_out=mm \
> >> >           --out="proj=merc ellps=WGS84 R_A"
> >>
> >> Gerald,
> >>
> >> Modulo syntax differences, cs2cs can already be used just to do the
> >> datum transformation step if desired.  So I don't see your point.
> >>
> >> > To me, that kills all mice with flexibility and ease of use.  *AND*
> >> > you can easily use libproj4 updates.  ;-)
> >>
> >> I would note that this still does nothing for the folks who use PROJ.4
> >> within another program like MapServer or GDAL.  There typically the
> >> application knows very little about the coordinate systems or what steps
> >> might be used.  They just call pj_init() for the source and destination
> >> coordinate system and then call pj_transform().
> >
> > Hey!  I am out of this discussion.
> >
> > What has been done, IMHO, is a grievous design flaw.  It is like slipping
> > odd and unrelated attributes into the trigonometric library so as to
> > "facilitate" the creation of a particular program.
>
> I'm probably way out of line commenting on the evolution of Proj,4. I
> am not a contributor but I've spent a lot of time looking at it. I do
> not think that Frank et al were "slipping odd and unrelated
> attributes" into Proj.4. My perspective is that Proj.4 was extended to
> support datum transformations, as is pretty commonly need in these
> days. (Actually I think there is a growing need for even more datum
> transformations, but that's for another thread). The EPSG code base
> seems to ball projections and datums together and I can see how the
> evolution occurred.

The germination of proj took place in the late 70's/early 80's as part of a 
mapmaking program I wrote called MAPGEN.  The earliest stages were in RATFOR 
(as I had and still do have a passionate hatred of FORTRAN).  Not much later, 
UNIX was introduced into our shop and proj began to take the form it has 
today.  As time progressed I kept adding to and refining proj and eventually 
freed it from its ties to MAPGEN even though it still was a required in 
MAPGEN's use.  Eventually an open file report was published and its code 
became more readily available.

At no time during my development of proj were datum operation part of proj's 
internals.  Early on, datum conversion was not a concern in our shop as all 
our data was NAD27.  Later with satellite navagation datum conversion did 
rear its ugly head but was taken care of with our version of NADCON.

Clearly note: that it was and still is quite clear that datum conversions and 
projection operations are totally different, mathematically and logically, 
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.

Through the years, even after retirement, I took care of my "baby" and 
continued its expansion through proj.4 and eventually libproj4.  I did the 
last name change recognizing that there had been some hacking of proj.4 
software that I did not, and still do not, agree with.  Thus I changed the 
name to libproj4 and tried to tighten up the licensing a bit although it is 
still totally free.

> Ideally it seems like cs2cs should be the all encompassing wrapper
> that handles the datum transformations and call proj as necessary. And
> that proj would be just that: projection support. I think that's
> basically what Gerald is suggesting. But there are so many users that
> would be affected by that change that it seems unwise.

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.  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.  If the proj4 
library had been used in it orginal state one should normally update cs2cs by 
merely relinking with a new libproj4 release.

I hope that explains my interest and frustration with this problem.  Thank-you 
for your time.

BTW, the reason I never got too involved in datum operations was that in the 
era when I was exposed the USSR still existed.  At that time datum 
information was often treated like state secrets and I figured it best to 
stay away from that nonsense.

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