Figure 1

One of the most helpful things to understand about map projections is that they convert angular measurements, usually in degrees, to linear measurements such as meters or feet. Consider the following question for a moment: How do you convert an angle in degrees to meters?

Figure 1 shows one way to do it. But is the length of Side 1 the right answer, or is the length of Side 2 correct. According to the figure, there are any number of answers; it all depends upon how big the triangle is. The larger the triangle, the larger the resulting linear value. Figure 2 shows another way to do it, in this case the linear distance is the length of the resulting arc. Again, there are many possible answers. In this case, the larger the radius of the circle, the larger the linear result.

Figure 2

The point of this: yes we can convert an angle to a linear measurement, if we have another number. If we are using round geometry, as we are in the case of cartography, that number is the radius of the round object. Thus, to convert angular measurements of latitude and longitude to linear measurements of X and Y, we need to know the radius of the object we are mapping. That is, the angle (expressed in radians) times the radius produces a linear measurement, which is the length of the arc.

In the case of the sphere, there is a single radius. All points are equidistant from the center of the object, and that distance is the radius of the sphere. Converting and angle to meters, is therefore, straight forward. Multiply the angle, expressed in units of radians, times the radius and we have our length. Well and good. Well, not quite that simple.

In the case of converting latitude to a linear Y value, in meters for example, we have little difficulty, as the distance will always be measured along a great circle of longitude. The calculation described above will produce an linear result in meters, providing the radius value we use is in meters. In the case of converting a longitude value, we do not have a problem if we are measuring longitude on the equator. Again, in this case, we will be calculating the length of an arc along a great circle of latitude. As discussed in previous articles, great circles are called great circles as their radius is as large as you can get with a given sphere, i.e. the radius of the sphere.

If you stayed awake through the last article, perhaps you remember that a line of latitude other than the equator is actually a small circle. That is, a circle with a radius less than that of the sphere. Therefore, to convert such an angle to a linear measurement, we need to determine the radius of such a small circle. This is a relatively easy calculation, as the radius of a small circle of latitude is simply:

Where f is the latitude of the small circle and R is the radius of the sphere. You can mentally verify this formula as at zero degrees, the cosine is 1. Thus at the equator the radius of a circle of latitude is equal to the radius of the sphere. As the latitude increases, the cosine decreases and the radius of the circles of latitude diminish. Of course, at the pole (90 degrees of latitude) the cosine is zero, and the radius of a small circle of latitude at the pole is zero, regardless of how big our sphere is.

So now, with one minor complication, we can convert the angular measurements of latitudes and longitudes to linear distances, X and Y. But don’t make any plans to invent the latest new projection just yet.

What we have described above are two techniques which are used to convert angular measurements to linear measurements. We know that a radius is required, and that there may also be more than one radius involved. How does our projection software know what radius value(s) to use?

When a coordinate system is defined, we associate a projection with other information. In so doing, a projection is usually associated with, i.e. referenced to, a specific datum. As we described several months ago, a datum definition requires the specification of an ellipsoid. It is the implied ellipsoid definition that specifies the radii which the projection will eventually use. When we specify the North American Datum of 1927, for example, the radii associated with the Clarke 1866 ellipsoid are implied. There is no ambiguity.

An example of this which Casual Cartographers are likely to encounter is the conversion of UTM coordinates, in the same zone, from the North American Datum of 1927 (NAD27) to the North American Datum of 1983 (NAD83). Many of us are aware that the shift implied by a NAD27 to NAD83 conversion is on the order of 20 to 100 meters, depending upon where in North America you are. However, the result of converting a UTM coordinate in, say, Kansas, from NAD27 to NAD83 can result in a change in the Y coordinate of about 200 meters. The reason for this is that the UTM Y coordinate is the linear distance, in meters (usually), from the equator to the point of interest. When we switch from NAD27 to NAD83, the underlying ellipsoid changes and thus the radii used by projection algorithm changes. Since the radii of the GRS1980 ellipsoid are different from that of the Clarke 1866, the resulting conversion of degrees of latitude to meters of Y is significantly different, and perhaps more than what we would expect. This is accentuated in the UTM case since the Y distance measure all the way from the equator.

Note that the actual datum specification is of no value to the projection mathemagics. Projection algorithms use only the radius information that is provided by the ellipsoid implied by the datum. (The datum specification indicates the datum upon which the coordinates processed and produced by the projection code are based, but do not affect the numerical results of the projection algorithms themselves.) Since the datum definition (excepting the ellipsoid specification) is not used, is it necessary to reference all coordinate systems to a datum? Not because of the projection algorithms, but perhaps because of the software in use.

Most all coordinate systems, and thereby the underlying map projections, are referenced to a specific datum. This enables the software processing the data to know when a datum shift is appropriate, and perform that shift automatically. Consider how a GIS product would actually perform the conversion used in the example above. The calculation is performed in three steps:

Convert the source coordinate to geographic form, latitudes and longitudes, using the projection algorithms;

Apply a datum shift to the resulting latitudes and longitudes to convert them from the datum of the source coordinate system to the datum referenced by the target coordinate system;

Convert the resulting geographic coordinates back to cartesian form using the projection algorithms.

If the coordinate systems were not referenced to datums, the above would not be possible. The GIS product would not know which datum transformations to apply.

Thus, the most benefit is derived from referencing coordinate systems to datums where ever possible, even though the projection algorithms only care about the implied ellipsoid. What if we don’t know to which datum a specific coordinate system is referenced? Are we out of luck?

Since the projection algorithms only care about the radius, most GIS software will enable users to still define a coordinate system and reference it to an ellipsoid, even though the datum is unknown. I’m aware of two techniques for doing this. Each technique has its drawbacks, neither represent an ideal solution. However, both techniques accomplish the same thing. These techniques are the inventions of software engineers trying to work around an oddball situation.

In one case, a series of "unknown" datums is defined, each which references a different ellipsoid. In this case, we have an empty datum definition, but a datum definition that is capable of pointing the projection software to the proper ellipsoid definition. This technique has the disadvantage of having lots of "non-datums" listed in the datums table; possible causing confusion (which hopefully we have just eliminated).

In other cases, the software product will provide you with an option to reference your coordinate system directly to an ellipsoid. In this case, the disadvantage is ambiguity introduced into the database structure that carries coordinate system definitions. That is, is the content of the reference field a link to the datum table, or is it a link to the ellipsoid table.

Mentor Software products use the second technique. That is, a user who is defining a coordinate system can choose to reference their coordinate system directly to an ellipsoid. Note that this is an either/or situation. You can reference your coordinate system to a datum, or directly to an ellipsoid; you cannot do both at the same time. Mentor Software uses the term "geodetically referenced" to refer to a coordinate system that is referenced to a datum and the term "cartographically referenced" to refer to a coordinate system that is referenced directly to an ellipsoid. As far as I know, this terminology is a Mentor Software invention and is not used elsewhere.

Hopefully the above cleared up more confusion than it created. Understanding that the actual map projection algorithms

have to have radii information in order to do anything, and

do not necessarily need any information about the specific datum itself;

can be helpful in understanding how to use geodetic/cartographic conversion software no matter who the vendor is.