[Proj] "Double Ellipsoid" error, reproduction

[Richard Greenwood]

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.

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.

Rich
-- 
Richard Greenwood
richard.greenwood at gmail.com
www.greenwoodmap.com