[Proj] "Double Ellipsoid" error, reproduction

Frank Warmerdam warmerdam at pobox.com
Mon Dec 8 17:14:20 EST 2008

Richard Greenwood wrote:
> On Mon, Dec 8, 2008 at 11:35 AM, Gerald I. Evenden
>> 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 believe Gerald's objection is to the incorporation of datum support,
and other non-projections related stuff into PROJ.4.  I have taken the
position that PROJ.4 is a "coordinate system transformation" library,
while  Gerald believes it should be a projection library and other
services like datum shifting, geodesic calculations and so forth should
be distinct libraries or components.

I respect Gerald's opinion, and reasons for his position.  However,
I have taken a different direction with some justification.

I can understand why Gerald might have little interest in discussions
of the datum aspects of PROJ.4.

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

I do have this wish that PROJ.4 could be restructured into a high level
coordinate systems library calling down to Gerald's libproj4 for the
projections aspect.  But such re-engineering is a pretty substantial
job, and frankly I haven't been paid to work on PROJ.4 since about 2001
so I'm unlikely to spend the several weeks such a re-engineering would
require.  I'm also quite sensitive to the need to do it in such a way
that it is minimally disruptive to applications using the existing PROJ.4
libraries which makes it trickier.

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

More information about the Proj mailing list