[Proj] "Double Ellipsoid" error, reproduction
richard.greenwood at gmail.com
Tue Dec 9 22:53:10 EST 2008
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.
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
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
richard.greenwood at gmail.com
More information about the Proj