Choose a coordinate system
Set a project's state plane or UTM zone so exports, imports, typed coordinates and readouts use northing and easting in that zone.
On this page
Every project can have one projected coordinate system: a state plane or UTM zone. Once it's set, the app works in northing and easting in that zone wherever a grid coordinate makes sense. Exports gain grid columns, projected files import correctly, you can type in a monument's published coordinates, and the asset list shows N/E.
The app has 455 zones built in:
| Family | Zones | Units |
|---|---|---|
| NAD83 (state plane and UTM) | 325 | metres, US survey feet or international feet, depending on the zone |
| WGS 84 / UTM, worldwide | 120 | metres |
| ETRS89 / UTM | 10 | metres |
Set the coordinate system
You can choose one when you create a project, under Output coordinate reference system on the New project screen. To set or change it later:
- Open the project you want to change.
- Go to Tools → Coordinate system. The row shows the current zone, or None if the project uses plain latitude and longitude.
- Type in the search field, for example Kentucky, New York or UTM 33N. You can also search by EPSG number, such as 3089.
- Tap the zone. A checkmark marks the one in use, and the sheet closes.
Each zone shows its EPSG code, its projection (Transverse Mercator or Lambert Conformal Conic) and its unit: m, ft or ftUS.
To go back to latitude and longitude only, tap WGS 84 (EPSG:4326 · latitude/longitude everywhere) at the top of the list.
What the coordinate system changes
The setting belongs to the project, so each job can use a different zone. It affects:
| Where | With a zone set |
|---|---|
| Export CSV | Adds easting_<unit>, northing_<unit> and crs_epsg columns next to latitude and longitude. |
| Point file (PNEZD) | Turns on. PNEZD needs a zone because its northings and eastings are grid values in the zone's own unit. Without one, the row is greyed out. |
| DXF and LandXML | Written in the zone's grid and unit, with the zone and horizontal datum stated in the file. |
| Import | CSV files with northing/easting columns are read in this zone. Without a zone, the app refuses them and asks you to pick one first. Points that fall outside the zone's area get a warning in the import preview. |
| Typed coordinates | Edit → Position… → Type offers N/E (EPSG:…) as well as Lat/Lon, so you can key a monument's published values. |
| Asset list | Each point shows its grid northing and easting, and its elevation in the zone's unit. |
| Stakeout and check shots | ΔN and ΔE are computed on the grid instead of a flat approximation, and residuals are marked as grid residuals. |
| COGO | Inverse, traverse and closure work on the grid, with grid and ground distances and the combined factor. |
| Site localization | Solved on the published grid instead of a local projection. |
| Units | With Settings → Units on Both, the foot shown alongside metres follows the zone: ftUS on a US-survey-foot zone, ft otherwise. |
Shapefile and GeoPackage exports stay in WGS 84 latitude and longitude. For state plane deliverables, use PNEZD, CSV, DXF or LandXML.
How positions are stored
The app always stores every position as WGS 84 latitude, longitude and height. The zone is a way of reading and writing those positions, not a second copy of them. So:
- Changing the zone later moves nothing. Every point keeps its latitude and longitude. Exports, readouts and typed coordinates simply use the new zone from then on.
- Records already saved keep their own numbers. A check shot stores the residual it computed at the time, and whether that residual was on the grid and in which zone. A saved site localization records the zone it was solved in.
- Typed coordinates keep what you keyed. When you enter N/E, they're converted to latitude and longitude for the record, and the values you typed are kept in the position history together with the zone.
Datum limitation: NAD83 is treated as WGS 84
The app projects WGS 84 positions straight onto the zone without a datum transformation. For NAD83 zones, that means NAD83 is treated as WGS 84, which is a difference of roughly 1–2 m at current epochs. No datum realization or epoch is applied. Exports say so in their coordinate-system statement.
In practice:
- With phone GPS, the 1–2 m is inside the phone's own error.
- With an RTK receiver on a NAD83 network (for example a state CORS network that delivers NAD83(2011)), the receiver's coordinates are already NAD83, so the grid values are right. The files still say only "NAD83", so write the realization and epoch on the plat yourself.
- With an ITRF or WGS 84 correction service (such as a global service or an autonomous base), the coordinates can be about 1.5 m off NAD83 and the app can't tell.
For ETRS89 zones, ETRS89 is likewise treated as WGS 84. For WGS 84 UTM zones there's no datum shift, but no epoch is applied either.