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, and each point's grid_scale_factor and combined_factor. |
| 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. |
| Shapefile and GeoPackage | Written in the zone and its unit, with the zone's definition (a .prj for the shapefile). Elevations are also given in feet on a feet zone. |
| Ground coordinates | Turns on Tools → Ground coordinates…, a ground-scaled export. See Ground coordinates. |
| 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. Tools → Stake a typed coordinate takes grid or ground N/E off a plat. |
| Asset list | Each point shows its grid northing and easting, and its elevation in the zone's unit. A point's detail also shows its Combined factor. |
| 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. |
| Correction frame | Corrections are in is judged against the zone's datum, and ITRF corrections are shifted onto a NAD83 zone. See below. |
| Units | With Settings → Units on Both, the foot shown alongside metres follows the zone: ftUS on a US-survey-foot zone, ft otherwise. |
Without a zone, Shapefile and GeoPackage exports fall back to WGS 84 longitude and latitude.
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: NAD83 and ITRF
The app projects positions onto the zone as received, with one exception: receiver fixes on corrections you've stated are in ITRF / WGS 84, on a NAD83 zone. Those are shifted into NAD83(2011) first. Exports say which applies in their coordinate-system statement.
In practice:
- 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. Set Corrections are in to NAD83(2011) so the record says so.
- With an ITRF or WGS 84 correction service (RTK2go, Emlid Caster, most single bases), set Corrections are in to ITRF / WGS 84. On a NAD83 zone, each fix is then shifted from ITRF2020 to NAD83(2011) (EPSG:10334) at its own date before it's used or saved. Ground motion since 2010 isn't modelled, so on the West Coast a shifted point can sit a decimetre or more from its published 2010.00 coordinate. Tie the job to control.
- With the frame left Not stated, nothing is shifted, and an ITRF-based fix can land 1–2 m off a NAD83 grid with nothing to show it. The Precision sheet and the QA report both warn.
- With phone GPS, positions are WGS 84 and aren't shifted. The 1–2 m to NAD83 is inside the phone's own error.
For ETRS89 zones, ETRS89 is treated as WGS 84; ETRS89 corrections are judged as matching, and other frames are flagged, not shifted. For WGS 84 UTM zones there's no datum shift, but no epoch is applied either.
See The frame your corrections are in.