[Proj] "Double Ellipsoid" error, reproduction

Tue Dec 9 19:31:54 PST 2008

I totally agree with Gerald's philosophy.  John P. Snyder stayed away from various geodetic applications also, and was strictly interested in cartographic projections.  John did not diddle with datums.  Once upon a time, I wrote software that did both.  John used my software for his private consulting work but did not diddle with datums directly.

A philosophic separation is reasonable and warranted.

The EPSG is a reflection on the practical needs of Geodetic Surveyors servicing the international oil patch.  Gerald's implementation is not that restrictive.

Merry Christmas!

Cliff Mugnier
LOUISIANA STATE UNIVERSITY

________________________________

From: proj-bounces at lists.maptools.org on behalf of Gerald I. Evenden
Sent: Tue 09-Dec-08 20:51
To: Richard Greenwood
Cc: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] "Double Ellipsoid" error, reproduction

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
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20081209/def36897/attachment.html>