[Proj] "Double Ellipsoid" error, reproduction

[Jan Hartmann]

Just for relaxation: see this link  for an explanation of datums that 
even I can understand :-)

http://sourceforge.net/mailarchive/forum.php?thread_name=1190060064.27461.57.camel%40blackpad&forum_name=jump-pilot-devel

Jan

Frank Warmerdam wrote:
> 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.
>
> Folks,
>
> 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,