Re: Spherical->Ellipsoidal Earth models in OpenMap

Don,

        Thanks for the reply on this. I've studied the problem, since we REALLY
need
a true WGS 84 datum for the cylindrical projections, and am working on a
slight reorganization of the Planet, Ellipsoid, and Projection classes
so that any datum
could be considered.

        I envision the following framework:

1. Move Ellipsoid into com.bbn.openmap package.
2. Develop a new class called com.bbn.openmap.Datum which contains all
of the
   information based on the desired Ellipsoid (WGS 84 Spherical by
default) that
   used to be supplied by the Planet class.
3. Remove com.bbn.openmap.proj.Planet; com.bbn.openmap.Datum supplies
the information.
4. Whenever a Proj object is instantiated, the subclasses, like
Mercator, etc
   can specify as an additional argument the desired Ellipsoid, which
will be used
   to construct the corresponding Datum object within Proj.

By organizing the Planet data in this fashion, I think that we can step
back from
hard-coded assumptions.

I've already implemented 1 and 2; 3 and 4 should not be a problem.

If this is of interest to the group at large, please let me know.

Regards,
        
Eliot

Donald Dietrick wrote:
>
> 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
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-- 
====================================================
Eliot Lebsack                         (781) 271-5830
Senior Communications Engineer    elebsack@mitre.org
The MITRE Corporation                    Bedford, 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"]