Re: Spherical->Ellipsoidal Earth models in OpenMap

Hi Eliot,

I'm not sure that the OpenMap projections need to be based on a
ellipsoid model for accuracy, in a general case. You'd need that if you
wanted to overlay another data image (say, from a OGC web server), where
the projection of the overlay was based on an ellipsoid. Otherwise,
objects laid out on the map will be in the right place relative to each
other, and the translations between lat/lon space and x/y space will be
consistent and accurate (not taking into account the error introduced by
the size of the pixel itself).

For distance and measurement calculations, though, there will be an
error introduced by using the spheroid model. In OpenMap, these
calculations are done for all projections in the GreatCircle class,
which uses equations based on the sphere. So, figuring out the points
on a GreatCircle line, the location of a point that is a certain
distance and azimuth away from another point, the distance between two
points, etc, all have this error in them - and I think the size of the
error is of the order that Ken explains below.

We used to have ellipsoidal equations in that class, but they were
yanked some time ago because someone on the team felt they were not
stable or documented. I have Ken's GreatCircle class that he wrote that
is based on an ellipsoid, and I'm planning on integrating it into
OpenMap code base, hopefully for the next release.

Which is not to say that an ellipsoidal Mercator projection would not be
warmly welcomed into the OpenMap code base, it definitely would be great
if you took the time to do it. The class framework should support it,
if you just want to name it EMercator or whatever, or even modified the
current class to use either model. The ProjectionFactory is due for a
rework shortly, so that it can dynamically load different projection
classes, instead of having them hard-coded like it is now. This would
make it easy to substitute the projection classes you need into your
application.

Cheers,

Don

On Tuesday, January 22, 2002, at 05:46 PM, Ken Anderson wrote:

> 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"]
>
>

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Donald Dietrick, dietrick@bbn.com
BBN Technologies, Cambridge, MA
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
[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"]