[OSRS-PROJ] Donald Elliptic Projection for AT&T V&H Coordinates?

[Clifford J Mugnier]

Mr. Evenden,

I was not upset, just pointing out historical facts on projection math.
The French could not "correct their maps.  :-)" because the maps were
already printed and the "Bosch" were occupying their country.  The work
that the C&GS tried to interceed with was with the estranged French
Topographic Corps residing in London.

The French only "corrected" their math in 1948 after WWII.  It took the
U.S. Army Map Service to (mathematically and figuratively) "bop" them in
between the eyes with a ball peen hammer before they changed to a fully
conformal Lambert conic.  By that time, the rest of Europe was on the
European Datum, UTM Grid.  Some prior French colonies (in North Africa)
still cling to that old artifact of the French Army Truncated Cubic Lambert
Conic.

Screwy or not, it's what's implemented is what counts for the locals.

Cliff Mugnier
LOUISIANA STATE UNIVERSITY
------------------------------------
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*
> experience
> with Java so this is not helping.
>
> To call this a projection for the ellipsoid (not to be confused with the
> alternate
> name of Elliptic Projection) seems a bit specious.  It says that the
> latitude
> on the
> sphere is obtained from the ellipsoid latitude---but which one: the
> conformal
> latitude or authalic latitude?  I'd guess the former.  Then the remainder
> of
> the
> calculations are done in the spherical system.  The problem is, that
great
> circle
> distances (required in the Two Point Equidistant) cannot be accurately
> computed by merely computing the conformal latitude and using the
> relatively
> 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
> constants
> for the two base points (in Kentucky and Utah) and fiddles with the inane
> rectagular transformations as well as the ellipsoid/sphere latitude
> conversions.
> 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
> sources,
> > 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.


----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.