[OSRS-PROJ] Re: Orthographic Projections and MapServer

[Strebe at aol.com]

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).
> 
> 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.] 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.)

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.

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.

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

Regards,

daan Strebe
Geocart author
<A HREF="http://www.mapthematics.com">http://www.mapthematics.com</A>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20030822/8091a73e/attachment.html>