Re: Spherical->Ellipsoidal Earth models in OpenMap

Don,

Yeah... reworking the framework will take some doing. I'm currently
trying to resolve the many dependencies that you are talking about.
It's a slow process. Now that I think about it, moving the Ellipsoid
and Datum classes back into the com.bbn.openmap.package class might
be a good organizational idea. Let me know what you come up with on
the ProjectionFactory mechanism.

By default, any instantiation of Datum assumes what I call "WGS 84
Sphere" to maintain compatibility with the existing code base.

Eliot

Don Dietrick wrote:
>
> Hi Eliot,
>
> On Wednesday, January 30, 2002, at 09:58 AM, Eliot Lebsack wrote:
>
> > 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.
>
> I can understand having the Ellipsoid and Datum classes, but I don't
> understand why they should be moved to the com.bbn.openmap package.
> Seems like they should stay/be put in the proj sub-package.
>
> > 3. Remove com.bbn.openmap.proj.Planet; com.bbn.openmap.Datum supplies
> > the information.
>
> I'd be careful of doing this for a while. Other things (some layers)
> rely on Planet. The modified projection classes could certainly stop
> using it, though.
>
> > 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.
>
> As an optional constructor. Seems like the main constructor can assume
> WGS 84 without an extra argument. Heck, the default datum might be
> something that can be set in the ProjectionFactory, too.
>
> > By organizing the Planet data in this fashion, I think that we can step
> > back from hard-coded assumptions.
>
> Sounds great. I appreciate the work you are doing with this.
>
> > 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.
>
> I think it is, since projections are so important. Perhaps this is the
> time to also rework the ProjectionFactory mechanism, too. As long as
> one paradigm is shifting, might as well make a couple of them do it.
> I'll work through a plan sometime in the next week, but it shouldn't
> affect what you are doing.
>
> Cheers,
>
> Don
>
> > 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
> >
> >
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Don 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"]