[OSRS-PROJ] Donald Elliptic Projection for AT&T V&H Coordinates?
gerald.evenden at verizon.net
Fri Nov 29 20:19:00 EST 2002
It sounds like I unknowingly upset someone. I appogize.
Secondly, I did not suggest "improvements" only a method of skinning a cat.
Thirdly, I *always* verify code provided these is a method or data to campare
with. Most programmers do (I hope). At the moment I am unaware of the
whole math picture of the Donald projection and/or any data to compare
results with. So nothing is happening on my watch.
Speaking of errors, when I was first working on projection software I too had
problems resolving the differences between my software and existing data. It
turned out to be US engineering foot versus the International foot.
In your example, the French were obviously in error and should have
been gracious enough to correct their maps. :-)
Clifford J Mugnier wrote:
> I am opposed to making "improvements" to the AT&T V&H math model for their
> projection implementation. Almost a century ago, the American Coast &
> Geodetic Survey made some "improvements" on French Battle Maps (WWI) that
> supposedly were cast on an "inferior" implementation of the Lambert
> Conformal Conic. Rather than match what was already a fact, higher-order
> terms were used to "improve" the original French version.
> Nothing would fit the existing maps. The new "improved" maps had to be
> discarded because consistency and continuity were more important than
> theoretically "correct." For decades, American Geodesists were derided by
> their European peers even though our Army won the war for them.
> I say that if such a projection is implemented, the original should be done
> first so that old data can match new data. A second "improved" alternative
> would be acceptable as long as the user was able to judge (for themself)
> which is preferable for the task at hand.
> Cliff Mugnier
> LOUISIANA STATE UNIVERSITY
> Out of curiosity I down loaded the stuff from Openmap but I still have not
> figured out where the projection math is for anything. I have *no*
> with Java so this is not helping.
> To call this a projection for the ellipsoid (not to be confused with the
> name of Elliptic Projection) seems a bit specious. It says that the
> on the
> sphere is obtained from the ellipsoid latitude---but which one: the
> latitude or authalic latitude? I'd guess the former. Then the remainder
> calculations are done in the spherical system. The problem is, that great
> distances (required in the Two Point Equidistant) cannot be accurately
> computed by merely computing the conformal latitude and using the
> simple spherical formula.
> If I were going to make this a part of PROJ I would use (proj=tpeqd) as
> the basis and make an overlaying entry for Donald which assigns the
> for the two base points (in Kentucky and Utah) and fiddles with the inane
> rectagular transformations as well as the ellipsoid/sphere latitude
> Much like utm calls tmerc except a little more hairy.
> If anyone can tell me where the math is, please let me know. Thanks.
> Now back to fixing the turkey. :-)
> Y'all have a good Thanksgiving.
> Duncan Agnew wrote:
> > There is a description of this projection at
> > http://openmap.bbn.com/doc/api/com/bbn/openmap/util/VHTransform.html
> > (at the bottom of the page). The code used is open-source (it appears)
> > and can be downloaded; go to http://openmap.bbn.com/ for information.
> > The actual conversion code contained inside the Java is from other
> > and it is clear that this is something that even AT&T had difficulty
> > sorting out later.
> > I leave it up to the more expert to add this to PROJ, and to reverse-
> > engineer the ellipsoid used.
> > Don't thank me, thank Google.
> > Duncan Agnew
> PROJ.4 Discussion List
> See http://www.remotesensing.org/proj for subscription, unsubscription
> and other information.
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.
More information about the Proj