Re: Spherical->Ellipsoidal Earth models in OpenMap

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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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