<HTML><FONT FACE=arial,helvetica><FONT SIZE=2 FAMILY="SANSSERIF" FACE="Arial" LANG="11">Ron Russell <ron@lsl.co.uk> writes:<BR>
<BR>
<BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">I assume that these limits would have to be stored in terms of<BR>
Geographical Coordinates which leads to problems of deciding<BR>
their granularity. (I am assuming that the projection is independent<BR>
of the data; it certainly is in our systems).<BR>
<BR>
Clipping to the limits would be done before projection using<BR>
spherical/ellipsoidal geometry. This seems<BR>
horrific, particularly for polygons, but then computing power is<BR>
becoming cheaper!<BR>
<BR>
Finally, in my experience, clipping of polygons cannot be done<BR>
on the fly. You have to bite the bullet and do it all at once. Our<BR>
polygons contain holes (like the Great Lakes and the Caspian<BR>
Sea).<BR>
</BLOCKQUOTE><BR>
<BR>
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.<BR>
<BR>
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.)<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
If your work is limited to geodetic applications the some of this is irrelevant. It's critical in projections for small-scale maps, though.<BR>
<BR>
Regards,<BR>
<BR>
daan Strebe<BR>
Geocart author<BR>
<A HREF="http://www.mapthematics.com">http://www.mapthematics.com</A><BR>
</FONT></HTML>