Local-Grid Coordinates: When 'Northing 5000, Easting 5000' Means Nothing

What “local grid” actually means

A local grid is a 2D coordinate system anchored to nothing in particular. The surveyor picked an arbitrary point in the field – usually a known monument, often the first occupied station of the job – and called it (N: 5000, E: 5000) or (N: 10000, E: 10000). Every other point in the survey is referenced relative to that origin. The bearings and distances between points are real and accurate. The absolute coordinates are not.

This pattern is everywhere in pre-GPS boundary surveys, especially before the late 1990s. The reason is straightforward: for a typical 5-acre boundary survey, the only thing the surveyor needed was the relative geometry of the corner monuments – where the iron pin is relative to the witness post, where the back-line is relative to the front-line. State-plane coordinates would have added zero accuracy and a lot of computation. Local grid was simpler and the numbers were small enough to write neatly on a plat.

Some firms still issue local-grid coordinates today on small-acreage residential boundary work. They’re not wrong to do it – the legal description for a quarter-acre lot doesn’t need WGS84 lat/lon. But the resulting archive is a coordinate-island.

How to spot one in 30 seconds

Three signals, any of which is conclusive:

1. Coordinate magnitudes around 1,000 to 100,000. Real state-plane coordinates in the US are usually in the hundreds of thousands or low millions of feet (e.g., a Tennessee state-plane northing is typically 560,000 to 580,000). If you see a PNEZD with coordinates in the 5,000-9,000 range, it’s almost certainly local grid.

2. Round-number origin. Local-grid origins are usually a round number like 5000, 10000, or 100000 for both N and E. Real datum coordinates would never coincidentally land on such round numbers as a setup point.

3. The first or first-few points have suspiciously round coordinates. Look at the first three rows of the PNEZD: if they’re at (5000, 5000, 0) or similar, the surveyor explicitly set the origin and the rest of the work cascades from there.

If a file passes those checks, treat it as local grid until proven otherwise. The CRS classifier in FieldIntel auto-tags these as LOCAL_GRID and skips them for map plotting – they appear in the verification table but not on the map. That’s the right behavior; you can’t plot what you don’t have a datum for.

What’s still useful in a local-grid archive

A lot, actually. The relative geometry is real:

• Distance between any two points in the file is accurate to the same precision as any other survey of the same era.
• Bearings between points are accurate, modulo the local-grid’s rotation (more on this below).
• The legal description – “thence N 87° 30’ 12” E, 247.65 feet to an iron pin found” – is just as legally valid as a state-plane survey of the same property.
• Comparison with later surveys of the same property is straightforward once you have a transformation pair (covered below).

What you lose without a datum:

• No map plotting. You can’t drop the points on Google Earth or QGIS basemap.
• No cross-job analytics. You can’t run a single GIS query across “all properties this firm worked in 2010-2015” if half are local grid and half are state plane.
• No spatial queries on Theo or any indexer that depends on real lat/lon.

The hybrid-archive problem

Most firms with 20+ years of records have a mix: older boundary jobs in local grid, newer jobs in state plane. A few have it worse – the same job has a state-plane base survey and a local-grid follow-up addendum.

When ingesting this kind of mixed archive, the right approach is to treat each PNEZD file independently rather than assuming the whole archive is one CRS. FieldIntel’s classifier does this – per-file inference, not per-folder. A 2024 state-plane shot file in the same folder as a 1998 local-grid boundary survey gets correctly tagged as two different things.

The practical implication for the customer: plan to do nothing about local-grid jobs in the first 90 days. They show up in the verification report as LOCAL_GRID (correctly tagged, not failing). They’re searchable in Theo’s text-based queries (job number, client name, point description). They just don’t appear on the map. That’s an acceptable v1 trade-off for most firms.

Bringing a local-grid job into a real CRS

When does it earn its keep? When the customer needs to:

• Plot historical local-grid jobs on a current GIS layer.
• Compare a 1995 boundary survey against a 2024 GPS re-survey of the same property.
• Cross-reference a local-grid plat with adjacent state-plane work.

The path is a 2D Helmert transformation pair: x-translation, y-translation, scale factor, rotation. Same four parameters as the custom-scale-factor case from last week, different starting point.

Extraction:

1. Identify two or three monuments shared between the local-grid job and a known-CRS source. This is usually a corner pin that’s been re-shot in a recent GPS survey, or a USGS benchmark that someone tied into during the original local-grid work.

2. Pull the local-grid coordinates and the real coordinates for those shared monuments. State-plane in the same units (US Survey Foot in most US states), or WGS84 lat/lon converted to state plane.

3. Solve for the four Helmert parameters. With two points you can solve for translation + rotation only (a “rigid” transformation, no scale). With three or more you get the full four-parameter fit via least squares.

4. Validate against the remaining monuments. Apply the pair to the local-grid coordinates of points 4, 5, 6 in the cohort and confirm they land where they should in real coordinates.

If the residuals are under a foot, you’ve got a working pair. Apply it to the entire local-grid file, write the transformed coordinates to a new file, and ingest that as the state-plane version.

What we don’t do (and why)

We don’t try to auto-detect a Helmert pair for local-grid jobs. The reason: there’s nothing to detect against. State-plane archives have a continent’s worth of EPSG geometry to test against. Local-grid archives have arbitrary internal coordinates that match no external reference. You need ground truth from outside the archive. There’s no algorithm; there’s a phone call.

The right operational model: surface local-grid jobs in the verification report, document them for the customer, and propose a one-job-at-a-time transformation pair when the customer needs map plotting for a specific property. Most firms find that 5 to 10 percent of their archive needs this treatment, and they only get around to doing it on jobs where a current client is asking questions about a historical boundary.

What to do if your archive has local-grid jobs

1. Don’t try to “fix” them as a project. They’re not broken. They’re correctly tagged.
2. Don’t merge them into the same map view as state-plane jobs without flagging. A point at (5000, 5000) plotted on a state-plane map would land somewhere very strange.
3. Do tag them in your project-management system so when a current client asks about an old boundary, you know to budget time for a Helmert extraction.
4. Do hold onto the original CAD or plat files. The legal description is in those, not just the PNEZD.