Re: Spherical->Ellipsoidal Earth models in OpenMap

This is a more technical response.

When i compute distances between two points in the earth i do a first order
correction that changes the latitude from geographic to geocentric. See
http://topex.ucsd.edu/geodynamics/14gravity1_2.pdf

I use 3D vectors rather than lat,lon. The theory and how to make an
efficient implemnetation is given in:

http://openmap.bbn.com/~kanderso/lisp/performing-lisp/essence.ps

The geocentric correction for latitude is largest around 45 degrees, and
makes the latitude about 0.2 degrees smaller. If a degree is about 60
nautical miles, this is about 12 nautical miles. So, if you're looking at
a map which has Boston at the top and Rio at the bottom, data at the top
and bottom could be 1/2 pixel off.

One thing openmap could do is (optionally?) make this latitude correction
before doing the projection from the sphere.

k

At 01:44 PM 1/22/2002, Allan Doyle wrote:
>On Tuesday 2002-01-22 at 13:00:40(-0500) Eliot Lebsack wrote:
> > Good afternoon.
> >
> > I've been examining the source code of the 4.4.2 release, and I have
> > noticed
> > that the Mercator projection assumes a spherical earth, instead of an
> > ellipsoid. I've
> > dug up the Snyder book "Map Projections - A Working Manual", and have
> > found the
> > corresponding ellipsoid-based formulas for performing the forward
> > projection
> > transformations.
> >
> > Before I get bogged down in the details of the Java class
> organization,
> > has
> > anyone given any thought as to how such a change would be implemented in
> > a
> > systematic manner (working within the current class framework)? Since
> > the sphere is a degenerate form of the general ellipsoid, it should be
> > rather straightforward to modify the arithmetic to support it.
> >
> > Any thoughts on this idea would be welcome.
>
>This is a philosphy response to a technical question. Don't mind me,
>I've just always wondered about this...
>
>I'm curious about why people want ellipsoid-based projections in a
>display-oriented component. I can understand why you would want to use
>them in a computation component - i.e. something that deals with
>distances, areas, buffering, etc.
>
>Is there any understanding in other geospatial software of the
>difference between quick-and-dirty display where you want everything
>to go as fast as possible and the accuracy needs of the compute side
>of things? Does everyone always use the same projection math for both
>parts?
>
>In a Model-View-Controller paradigm, it would seem to me that the view
>could generally be considered to be an imprecise and incomplete window
>into the model anyway. Displays have fat pixels, not infinitesimally
>small dots.
>
>Furthermore (at least this used to be true), the OpenMap projections
>are geared towards display and have additional methods such as
>"plotable()" which used to be a way to see if a given point was
>visible (i.e. was not clipped off the edge of the screen, nor "behind"
>other points in the orthographic projections. These methods are not
>needed for computing distance, etc.
>
>So what does this all mean? Maybe it means that there should be two
>kinds of projection classes - those optimized for drawing, and those
>optimized for computing. There could be others, or at least variations
>on these as well.
>
>End of philosophy...
>
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Allan Doyle http://www.intl-interfaces.com
>adoyle@intl-interfaces.com
>
>
>
>--
>[To unsubscribe to this list send an email to "majdart@bbn.com"
>with the following text in the BODY of the message "unsubscribe
>openmap-users"]

--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]