<HTML dir=ltr><HEAD><TITLE>Re: [Proj] "Double Ellipsoid" error, reproduction</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16735" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText14531 dir=ltr>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=2>I totally agree with Gerald's philosophy. John P. Snyder stayed away from various geodetic applications also, and was strictly interested in cartographic projections. John did not diddle with datums. Once upon a time, I wrote software that did both. John used my software for his private consulting work but did not diddle with datums directly.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>A philosophic separation is reasonable and warranted.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>The EPSG is a reflection on the practical needs of Geodetic Surveyors servicing the international oil patch. Gerald's implementation is not that restrictive.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>Merry Christmas!</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>Cliff Mugnier</FONT></DIV>
<DIV dir=ltr><FONT size=2>LOUISIANA STATE UNIVERSITY</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> proj-bounces@lists.maptools.org on behalf of Gerald I. Evenden<BR><B>Sent:</B> Tue 09-Dec-08 20:51<BR><B>To:</B> Richard Greenwood<BR><B>Cc:</B> PROJ.4 and general Projections Discussions<BR><B>Subject:</B> Re: [Proj] "Double Ellipsoid" error, reproduction<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>On Monday 08 December 2008 4:35:50 pm Richard Greenwood wrote:<BR>> On Mon, Dec 8, 2008 at 11:35 AM, Gerald I. Evenden<BR>><BR>> <geraldi.evenden@gmail.com> wrote:<BR>> > On Monday 08 December 2008 12:24:19 pm Frank Warmerdam wrote:<BR>> >> Gerald I. Evenden wrote:<BR>> >> > I think more desirable approach is to create a d2d program with<BR>> >> > optional i/o filtering through projection procedures. One might have<BR>> >> > options like:<BR>> >> ><BR>> >> > d2d --in=EPSG1234 --out=NAD83_1105<BR>> >> ><BR>> >> > where --in and --out may refer to library systems but one can also<BR>> >> > have<BR>> >> ><BR>> >> > d2d --in=proj=latlon --datum_in=xyx --datum_out=mm \<BR>> >> > --out="proj=merc ellps=WGS84 R_A"<BR>> >><BR>> >> Gerald,<BR>> >><BR>> >> Modulo syntax differences, cs2cs can already be used just to do the<BR>> >> datum transformation step if desired. So I don't see your point.<BR>> >><BR>> >> > To me, that kills all mice with flexibility and ease of use. *AND*<BR>> >> > you can easily use libproj4 updates. ;-)<BR>> >><BR>> >> I would note that this still does nothing for the folks who use PROJ.4<BR>> >> within another program like MapServer or GDAL. There typically the<BR>> >> application knows very little about the coordinate systems or what steps<BR>> >> might be used. They just call pj_init() for the source and destination<BR>> >> coordinate system and then call pj_transform().<BR>> ><BR>> > Hey! I am out of this discussion.<BR>> ><BR>> > What has been done, IMHO, is a grievous design flaw. It is like slipping<BR>> > odd and unrelated attributes into the trigonometric library so as to<BR>> > "facilitate" the creation of a particular program.<BR>><BR>> I'm probably way out of line commenting on the evolution of Proj,4. I<BR>> am not a contributor but I've spent a lot of time looking at it. I do<BR>> not think that Frank et al were "slipping odd and unrelated<BR>> attributes" into Proj.4. My perspective is that Proj.4 was extended to<BR>> support datum transformations, as is pretty commonly need in these<BR>> days. (Actually I think there is a growing need for even more datum<BR>> transformations, but that's for another thread). The EPSG code base<BR>> seems to ball projections and datums together and I can see how the<BR>> evolution occurred.<BR><BR>The germination of proj took place in the late 70's/early 80's as part of a<BR>mapmaking program I wrote called MAPGEN. The earliest stages were in RATFOR<BR>(as I had and still do have a passionate hatred of FORTRAN). Not much later,<BR>UNIX was introduced into our shop and proj began to take the form it has<BR>today. As time progressed I kept adding to and refining proj and eventually<BR>freed it from its ties to MAPGEN even though it still was a required in<BR>MAPGEN's use. Eventually an open file report was published and its code<BR>became more readily available.<BR><BR>At no time during my development of proj were datum operation part of proj's<BR>internals. Early on, datum conversion was not a concern in our shop as all<BR>our data was NAD27. Later with satellite navagation datum conversion did<BR>rear its ugly head but was taken care of with our version of NADCON.<BR><BR>Clearly note: that it was and still is quite clear that datum conversions and<BR>projection operations are totally different, mathematically and logically,<BR>there is *no* reason to combine the operations into one procedure. <BR>Programmatically combining the operation made no sense and was a clear<BR>violation of modular programming practices.<BR><BR>Through the years, even after retirement, I took care of my "baby" and<BR>continued its expansion through proj.4 and eventually libproj4. I did the<BR>last name change recognizing that there had been some hacking of proj.4<BR>software that I did not, and still do not, agree with. Thus I changed the<BR>name to libproj4 and tried to tighten up the licensing a bit although it is<BR>still totally free.<BR><BR>> Ideally it seems like cs2cs should be the all encompassing wrapper<BR>> that handles the datum transformations and call proj as necessary. And<BR>> that proj would be just that: projection support. I think that's<BR>> basically what Gerald is suggesting. But there are so many users that<BR>> would be affected by that change that it seems unwise.<BR><BR>On the surface I find nothing wrong with cs2cs and it certainly should be a<BR>valuable program. However, I feel that the internals are put together in a<BR>manner that first: made it harder to develop and now: much more difficult to<BR>maintain. By combining datum and projection operation internally with<BR>modifications of proj.4 it is impossible to easily upgrade cs2cs when<BR>corrections or improvements of libproj4 become available. If the proj4<BR>library had been used in it orginal state one should normally update cs2cs by<BR>merely relinking with a new libproj4 release.<BR><BR>I hope that explains my interest and frustration with this problem. Thank-you<BR>for your time.<BR><BR>BTW, the reason I never got too involved in datum operations was that in the<BR>era when I was exposed the USSR still existed. At that time datum<BR>information was often treated like state secrets and I figured it best to<BR>stay away from that nonsense.<BR><BR>--<BR>The whole religious complexion of the modern world is due<BR>to the absence from Jerusalem of a lunatic asylum.<BR>-- Havelock Ellis (1859-1939) British psychologist<BR>_______________________________________________<BR>Proj mailing list<BR>Proj@lists.maptools.org<BR><A href="http://lists.maptools.org/mailman/listinfo/proj">http://lists.maptools.org/mailman/listinfo/proj</A><BR></FONT></P></DIV></BODY></HTML>