[OSRS-PROJ] Re: Orthographic Projections and MapServer

[Gerald I. Evenden]

On Fri, 2003-08-22 at 11:53, Strebe at aol.com wrote:
> Ron Russell <ron at lsl.co.uk> writes:
> 
> > I assume that these limits would have to be stored in terms of
> > Geographical Coordinates which leads to problems of deciding
> > their granularity. (I am assuming that the projection is independent
> > of the data; it certainly is in our systems).

I never understood the meaning of "granularity" here.

> > Clipping to the limits would be done before projection using
> > spherical/ellipsoidal geometry. This seems
> > horrific, particularly for polygons, but then computing power is
> > becoming cheaper!
> > 
> > Finally, in my experience, clipping of polygons cannot be done
> > on the fly. You have to bite the bullet and do it all at once. Our
> > polygons contain holes (like the Great Lakes and the Caspian
> > Sea).
> 
> 
> A properly written projection system supplies the domain of projection
> to client applications. This domain is the mathematical limits of the
> projection; not the "practical" limits. The projection system would
> also supply default outer boundaries in each aspect so that client
> applications don't do stupid things out of the box.


> Hence, in the case of UTM, there would be no domain restrication but
> the projection would supply default boundaries of 3-1/2 degrees on
> either side of the prime meridian. (It is a little-known fact that the
> entire sphere is projected to a finite map in the ellipsoidal
> transverse Mercator; and in fact, it's an excellent world map as
> conformal projections go. [That contrasts with the spherical
> transverse Mercator, which projects to a map of infinite extent.]

What nonsense.  If there was a closed form of the transverse Mercator
for the elliptical case, it would extend to infinity also.  The basis
of the math requires it.

>  Having said that, however, UTM implementations normally employ series
> whose accuracy trends toward uselessness a few degrees away from the
> central meridian. In those cases the projection should declare a
> mathematical limit wherever the series breaks down into topological
> nonsense. Unfortunately few people bother to analyze their
> implementations that carefully, and in the end it doesn't much matter
> for a series approximation to Gauss-Kruger.)

Extending more than 4° to 5° is pointless anyway.  Distortion starts
to take over and the map becomes useless as a cadastral tool.  For
larger extents (smaller scale) switching to spherical form is most
justified.  Mercator is just as useless a few degree from the equator
as the transverse form is from the CM.  The only reason Mercator is
so popular is for navigational maps is because simplified navigation
can be done with rhumb (straight) lines on the map.  For world
scale mapping Mercator in any form is terrible.

> The projection must supply a correct representation of the
> mathematical boundary. In some cases that would be a great circle or
> geodesic; in some cases a rhumb; in some cases something else
> entirely. The client application need know nothing specific about the
> outer path; it only needs a parametric representation. In other words,
> the projection package supplies an abstract path from which the client
> application can extract a lat/long pair given a parameter between 0
> and 1, inclusive. It should be clear that the outer path is the
> responsibility of the projection package, since it is the mathematics
> of the projection that defines the domain and range of projection.

Many projections do not have mathematical limits other than the
polar limit and one can extent the longitude indefinitely.  It
is not the projections duty to supply "boundary" information other
than indicate when the limits of the projection are exceeded because
they have no meaning in non-graphical usage.

In general, these comments are getting off track as I feel the basis
of the thread was to solve the problems of "mapserve" and not advertise
a graphics package.  A package, I might add, that package seems to be
only available for Apple systems.

> The amount of computation required for this is not "horrific"; Geocart
> was doing it at quite useful speeds in 1990 on consumer hardware. And
> clipping polygons "on the fly" is a perfectly reasonable thing to be
> doing, whether your polygons contain holes or not.

I do agree here, as I have indicated on previous comments in this
thread.

> If your work is limited to geodetic applications the some of this is
> irrelevant. It's critical in projections for small-scale maps, though.
> 

BTW, is the math for your Strebe-X projections published?

> Regards,
> 
> daan Strebe
> Geocart author
> http://www.mapthematics.com
-- 
Gerald I. Evenden <gerald.evenden at verizon.net>

----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.