[OSRS-PROJ] Re: Orthographic Projections and MapServer
Strebe at aol.com
Strebe at aol.com
Fri Aug 22 11:53:07 EDT 2003
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Proj