[Proj] "Double Ellipsoid" error, reproduction

[Richard Greenwood]

On Tue, Dec 9, 2008 at 7:51 PM, Gerald I. Evenden
<geraldi.evenden at gmail.com> wrote:
> 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.

Gerald,

I have been using Proj.4 and following this list for long enough to
know your interest in, and contributions to, this project. I have
enough gray hair to remember the USSR and to be able to use with UNIX
pipes. I can relate to your frustration, but I can not sympathize with
it.

We have moved beyond paper maps and can no longer segregate
cartography from geodesy - projections from datums. The addition of
datum support was necessary and well intentioned. The implementation
was probably imperfect.

Perfecting the implementation of Proj.4 as a comprehensive _coordinate
system_ library (not just a projection library) without a major
rewrite is not likely. Restricting it to just a projection library
would diminish its value to such an extent that it would lose its
relevance.

Respectively yours,
Rich

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