LOCAL PROJECTION SYSTEM

FOR SURVEY APPLICATIONS

AND

THE PRO'S AND CON'S

OF USING

SUCH SYSTEMS

**Jerry L. Wahl
Bureau of Land Management
Cadastral Survey
Eastern States, ES915
7450 Boston Boulevard
Springfield, VA 22153
(703) 440-1674**

This paper discusses the development of simple local coordinate systems for use in Public Land Surveying applications. One of these projections was developed for field use without elaborate computations. Another was developed to simplify specific computations. Both and are of interest historically as illustrations of many of the features of coordinate systems and projections in general. The discussion will include an exploration of the errors and limitations of these systems as a metaphor for the problems involved in any projection used for geodetic and/or land surveying purposes.

Strangely enough, after describing these systems, this paper will briefly
argue *against* the use of specialized coordinate systems. At the
same time that the use of computer technology makes established systems
more practical to use, there has been an increase in advocacy for proprietary
or custom systems.

Coordinate systems are used by virtually every land surveyor. It is common to use local systems created on a project by project basis. Most often these systems are simple plane cartesian coordinate systems with only rough north orientation. Virtually all surveying software is based upon this concept. Orientation is often arbitrary and is even modified based on subsequent information with a project rotation. The general use is the 2 + 1 dimensional method. This "2 + 1" means computation of plane x y or N E coordinates, where elevations are collected and computed separately.

When moving into Public Land Survey System, PLSS, surveys or other large scale surveys such as route surveys, the simple plane systems can become difficult to maintain, and in fact may become an invalid approach. As a result specialized systems are needed which have certain geodetic features and/or are geodetically related. It is common practice to implement the use of State Plane coordinates to meet these requirements, and in fact this is what they were designed for. For PLSS application, however, these may not be directly usable and there are some intermediate options.

Surveying in the PLSS is a geodetic or geodetic-like system. That is, it has an orientation according to the true meridian. This creates a system which is non- orthogonal (non-cartesian), and thus such surveys cannot easily be computed in directly in a plane coordinate system. This dilemma has lead to the use of a number of enhanced coordinate systems for use in PLSS work. Before we get into the specifics of those systems, let us define some characteristics of coordinate systems and projections.

**Projection Method/Surface:** Coordinate Systems *may* be defined
as projections to a defined mathematical reference surface. State Plane
systems are typical of these, where the reference systems are conic or
cylindrical (Lambert or Transverse Mercator). It is not necessary for a
coordinate system to use a projection or a surface. The system can transform
or map coordinates based upon formula or processes.

**Datum:** If the system is based on geodetically related projection,
then the specific geodetic datum is relevant. In the geodetic sense, this
refers to the specific mathematical spheroid parameters in use. In the
state plane systems, the projections are defined differently in each datum.
The two most common familiar datums are NAD27 and NAD83.

**Orientation:** The system has to have a consistent basis of direction.
This can be arbitrary or "assumed", and is often stated.

**Mapping Angle:** The difference between geodetic north and grid
north at a given place. The magnitude of the mapping angle increases as
you move east or west. The mapping angle is referred to as "theta"
in this paper.

**Central Meridian:** The longitude or Easting value where grid north
and geodetic north are the same.

**Second Term:** A small value which represents the difference between
grid directions, i.e. angles, and geodetic angles at the same point.

**Base Point:** Some systems are based upon or defined with respect
to a specific point.

**Scale Factor:** The ratio derived by dividing the distance between
two points on the ellipsoid and the same two points in grid.

**Elevation Factor:** Many coordinate systems that are defined with
a geodetic reference or projection must base this projection upon a specific
elevation. This requires lines measured at ground elevation to be converted
to "sea-level". Thus any distance measured horizontal on the
ground must be reduced first to sea-level then to grid based on the scale
factor average over the line.

**Conformal:** Is a concept which describes how well the coordinate
system maintains angular relationships and shapes. That is, a square on
the ground will be very close to a square in the grid. Since projections
map an ellipsoidal surface onto a two dimensional surface, they can never
truly avoid distortion but can be designed to minimize it.

**Distortion:** In addition to the small distortions caused by the
projection process, large projection zones necessarily have increasing
variations of scale at their extremities. This distortion is much smaller
near the center of the zone.

**Stability:** A term used by Von Meyer, but not defined. We assume
stability refers to a system being well defined and available so that all
users who implement and use it get the same results. Another stable feature
which a projection may have is independence from datum changes.

**WP Coordinates:**

This system initially was applied to large scale PLSS surveys and was designed to be simple to setup and easy to use. It was designed to be used in the field with simple calculators and uses a minimal set of computations. The initial design is termed algorithm 1. The system is not a projection, but merely a system which allows the user to relate a orthogonal local coordinate system to the PLSS true bearing system. All distances are assumed to be ground measurements. The system was designed before the use of programmable calculators, and allowed conversion between true and project bearings with simple mathematical operations. In addition, a crude lat/long could be computed for use in astronomic observations.

**Algorithm 1 - WP Coordinates:** In this system a base point is
defined with assigned coordinates: The system is defined by astronomic
observations at the base point which thus creates a central meridian at
the base point easting. The primary projection "constant" is
simply the change in direction per change in easting. In BLM Cadastral
survey work the typical units are in chains. Thus this value would be computed
one time per project based upon the average project latitude. Typical examples
are in the magnitude of 20 seconds of bearing per 40 chains in departure.
There are a variety of formula's possible to compute this value from a
given longitude, however since this is only computed once, a full geodetic
computation is not an encumbrance to the design. The example used NAD27
ellipsoid value, however this is not required.

Given:

a = 6378206.4 meters Clark 66 Spheroid major axis meters b = 6356583.8 meters Clark 66 Spheroid minor axis meters

Then:

e1 = 1 - b2/a2 Spheroid eccentricity factors e2 = (a2/b2) - 1.0 Ac = a * 39.37 / 792.0 Spheroid major axis in chains rad = Average Spheroid radius at project for example = 20,906,000 feet, rough value, can be computed for project area

A base point is selected with a given northing, easting and latitude and longitude. The base values are:

LatBase = Latitude of base point LonBase = Longitude of base point N0 = False Northing assigned to base point E0 = False Easting assigned to base point on central meridian

The following values are then computed for a project:

k1 = 1 - e1 * SIN2(LatBase) Intermediate value c = TAN(LatBase) * SQR(k1) / 5533.707122 Curvature in Degrees/chain

For example for a latitude of 34 degrees 45 minutes:

k1 = 0.998019 c = 0.000125239 Degrees per chain departure = 0.4509 Secs of bearing per chain departure = 18.03 Secs of bearing per half mile departure

The base point is defined to be on the meridian where true azimuth equals grid azimuth. Therefor with just this value of c, a theta or mapping angle computation can be performed at any point Ni, Ei, using:

theta = (Ei - E0) * c Mapping angle for point at Easting Ei true az = grid azimuth + theta

This is obviously crude, but still within reasonable limits for the conversion of astronomic azimuths into the grid. The system definition can also include average m and p factors in the project area make a crude computation of latitude and longitude possible. These additional factors can be computed from:

m(lat) = m factor for latitude lat in chains per degree = pi / 180 * Ac * (1 - e1) / ((1 - e1 * (SIN2(lat)))1.5)

p(lat) = p factor for latitude lat in chains per degree = -(pi / 180 * Ac * COS(lat) / SQRT(1 - e1 * SIN2(lat)))

Full implementation thus requires determining the constants for the base point:

N0 = false Northing of base point E0 = false Easting of the base point and central meridian LatBase = Latitude of base point LonBase = Longitude of base point MBase = m factor based on LatBase PBase = p factor based on LatBase c = change in direction per change in easting unit

Implementation of the basic system over a several township (+- 10 mile radius) does not require highly accurate computation of the c value. This system is adequate for the conversion between grid and true bearings which is the dominant factor between any plane system and a geodetic system. However it has small inaccuracies due to the use of a constant value of c over the project, when this value varies as a function of latitude. Also the quick option to compute field lat/long is crude. It is suitable for positional data to control astronomic azimuth observations and rough scaling, but not useful for survey quality geodetic to plane conversions. Both of these problems were addresses by a modification called the second algorithm.

**Algorithm 2 - WP Coordinates:** This refinement makes the basic
computation a little more complex but with the base computation still easily
within the realm of the field calculator, adding only a few trig functions.
In fact, if the calculator has polar rectangular conversions the computation
can be performed in one step. It is based upon a model of a conic tangent
to the earth at the project base point, with the apex over the pole. This
is a model more than a projection, so the use of the system is still simple.
The primary factor now being computed instead of the value c is the conic
radius at the base point, Rb. Since meridians mapped onto the conic converge
at nearly the same rate as on the spheroid surface, corrections to the
operation of the system can be computed using simple curve and radius computations.

Rb = Ac * COT(LatBase) / SQRT(k1)

This refinement produces significantly greater accuracy in the lat/long computation, so much so that failure to correct the computations based on project elevation becomes the dominant error. Thus an additional factor may be computed for average project elevation.

slfact = 1 - Elev / (Elev + rad) sealevel dist = ground dist * slfact

This factor is then used in each conversion computation if needed. The following if statements are now used to compute theta for a point Ni, Ei:

dn = (Ni - N0) * slfactgrid northing difference from point to basede = (Ei - E0) * slfactgrid easting difference from point to basetheta = TAN-1(de/(Rb - dn))

Conversion of a system coordinate Ni, Ei to latitude and longitude is performed accurately with the following process:

drad = Rb - dn rpti = SQRT(de2 + drad2) latr = Latbase + ((Rb - rpti)/Mbase)trial point latitude

the trial latitude is used through iterations to compute a mean latitude between the point the base which is then used to compute a new m factor which is more correct for that interval.

mfacm = m factor at mean latitude,

this is approximated by Mbase, then refined by iteration.

pfacm = p factor at mean latitude,

as determined in the iterations used to compute the above.

lati = LatBase + (Rb - rpti)/mfacm) loni = LonBase + (theta * rpti)/pfacm)

Conversion of a lat long to system N, E is accomplished with the following:

mnlat =mean latitude between point and base= (lati + latbase) / 2.0 mfacm =m factor at mean latitudepfaci = p factor at point drad =difference in conic radius to point= mfacm * (lati - latbase) radi = conic radius of point = Rb - drad arci =length of parallel central meridian to point= pfaci * (loni - lonbase) theta = arci/radiin radians

Ni = N0 + (Rb - radi * COS(theta)) / slfact Ei = E0 + (SIN(theta) * radi) / slfact

It should be noted in order to be much more accurate this is now starting to be a more complex computation, requiring computation of several m and p factor. This begins to move this operation beyond easy field manipulation. However the mapping angle computation is still easy, it is the transformation between geodetic and local system coordinates that has become complex.

This system is still not a true projection, and thus has no scale factor. A number of further refinements could be made to this system which each would increase the accurate scope of coverage, but also increase the complexity of computation. At some point there is a point of diminishing returns.

Alaska has implemented a local coordinate system for field use as an output from their GEO surveying software system developed by Thomas (Red) Wohlwend. This system is a very complete and powerful system designed to perform the wide scope of surveys being performed in Alaska. In many small surveys the field crews, equipped with HP41C class calculators, need a system to perform closures, field checks, and area computations, on the ground. As a result Red has developed a specialized output from GEO which produces a local coordinate system based upon a state plane coordinate base point. This system involves computation of mapping angle and scale factor at the base point. Each point in a geodetic system can then be converted into a planar, ground distance, local system for temporary use in the field.

**T & T Coordinate System: **Alaska has also developed another
system which has very specific purposes. It is not a conformal system,
nor is it trivial to compute, but it provides some very useful characteristics.
Since in the PLSS near cardinal lines are all important, and also in the
PLSS world East and West lines are curved parallels of latitude. It is
difficult to compute areas of PLSS parcels or intersections, since the
system is non-orthogonal. The T&T system is not a projection, but a
mathematical mapping of latitudes and longitudes to coordinate values (usually
in chains) which makes all east and west lines straight grid east and west.
north and south lines end up converging slightly if they are off of the
base point which defines the central meridian. The system is predominantly
an aid to computations in the PLSS, and has minimal value for direct field
use.

In the T&T system the north coordinate of a point is defined by the distance between the points latitude and the latitude of the base point. This is computed by evaluating the m factor for the mean between the point and base latitude times the latitude difference. The east coordinate is defined by it's distance at latitude along a parallel from the base point longitude. This is accomplished by evaluating the p factor for the latitude of the point times the difference in longitude. Thus the T&T coordinate for a point Lati, Loni are given by:

mnlat = (Lati + LatBase) / 2 Easti = (Loni - LonBase) * p(Lat) Northi = (Lati - LatBase) * m(MnLat)

As stated this system has many special computational purposes, but is not conformal, in that angles about a point are preserved. The inverse operation from a T&T coordinate pair to latitude and longitude are computed by iterations between determining a trial latitude based upon base m factor, then deriving a mnlat for use in determining a refined m factor and so forth.

Each of the above described systems was created for specialized purposes, however in several recent papers, the topic of creating much more complex local projections has been discussed. The WP system shares some of these rational, however it is the authors contention that these factors are no longer relevant due to the common availability of computing capability to surveys. The rational for these systems varies between providing:

**Less distortion in the project area**. This is true as there is
always less distortion near the origin of a well defined conformal projection.
However, why this distortion creates any real problem at the graphic level
of a GIS, or to properly programmed projection software is unclear.

**Grid distances close to ground distances**. This is also often
described as a desirable characteristic. If the projection is for GIS use,
the idea of deriving survey quality from a GIS base seems to be obscure,
however it is nice to think of survey and design quality layers in a GIS,
CAD or project COGO system. However it is this authors opinion that these
ends can best be achieved by proper software based on well known projections
than by adopting a whole new specialized projection. Stakeout information
can be readily converted to ground through application of simply computed
scale and elevation factors.

One of the more dangerous of these concepts are various methods to modify the state plane coordinate systems to ground elevation. These adulterated systems are very popular, but very dangerous as a project or description appears to have state plane coordinates on it, but it is not at all clear that they are not. Thus they are highly subject to misinterpretation and use by subsequent users.

**Facilitate GIS development** This reason for adopting a locally
defined projection makes the least sense. As local governments, states,
and numerous federal government agencies develop GIS/LIS systems, universal
coordinates systems which allow for combining data over larger regions
seamlessly seems to be an attribute which is not within grasp, but which
would be frustrated greatly with the proliferation of local proprietary
systems.

Most of the reasons given for using locally defined projections over well defined projections for mapping and GIS purposes are invalid when computers are available and used for most, if not all, computations. Furthermore the arguments in favor seem to be self serving in demanding specialized software and less universal systems at a time when the need for more universal systems are clear. On the ground surveying stakeout problems can be addressed through a number of simple software solutions rather than custom or adulterated projections. The author feels that the time has come to get off the dime and start implementing systems which properly use regional, state, or universally understood projections, rather than quick fixes which serve to further fragment data, datums, and undermine the ability to educate the profession.

von Meyer, Nancy (1990), *County Coordinate Systems*, ACSM Bulletin,
Number 126,, pp. 51-52.

Jeyapalan, Dr, Kandiah, *Surface State Plane Coordinate Systems*,
Proceedings of the 1993 ACSM-ASPRS Annual Convention, Vol. 1, pp. 270-279.

Burkholder, Earl F., *A Case Study Comparing Use of Local Map Projection
Coordinates with 3-D Geodetic Model Coordinates*, Proceedings of the
1993 ACSM-ASPRS Annual Convention, Vol. 1, pp. 42-51.

Burkholder, Earl F., *Design of a Local Coordinate System for Surveying,
Engineering, and LIS/GIS*, Journal of Surveying and Land Information
Systems Vol. 53, No. 1, 1993, pp. 29-40.

Wahl, J.L. (1990), *Cadastral Measurement Management User's Manual*,
147 p., Bureau of Land Management, NSPS Board of Governors.

Wahl, J.L., Rodine, C.J., and R.J. Hintz (1991) *Progress Report on
the Development of an Integrated PLSS Cadastral Measurement Management
and Retracement Survey Software System*.

Hintz, Raymond J., *Examination of the Validity of State Plane Projection
Computations in PLSS Applications*, Proceedings of the 1993 ACSM-ASPRS
Annual Convention, Vol. 1, pp. 223-232.

Cadastral Home | Cadastral Papers

jl-wahl@access.digex.net