UTM Coordinates

Use the Status page for a live UTM reading. CSV and DXF exports use a local grid instead. Confirm the coordinate system, datum, and height reference required by your project before combining data.

UTM in plain words

Universal Transverse Mercator cuts the world into 60 north–south strips, each 6° of longitude wide, numbered 1 to 60 from the 180° meridian. Inside a strip, positions are two distances in metres:

• Easting — metres east of the zone's central meridian, which is given the value 500,000 m so eastings never go negative.
• Northing — metres north of the equator; in the southern hemisphere 10,000,000 m is added so northings stay positive too.

A full UTM position is therefore zone + hemisphere + easting + northing, for example 18N 583951.930mE 4507262.097mN.

UTM gives horizontal grid distances in metres. Grid distances differ from ground distances because of projection scale and elevation; account for that difference in precise layout work. Displaying more decimal places does not improve measurement accuracy. See USGS’s UTM overview.

What RoboDot gives you

• Web UI Status page — shows UTM (meters) as <zone><N|S> <easting>mE <northing>mN, calculated from the current latitude and longitude. It uses the WGS84 ellipsoid; this calculation does not transform the source datum.
• Point exports — the CSV and DXF exports carry Easting(M) and Northing(M) columns, but these are local grid metres measured from the first point of the export, not UTM. They are ideal for CAD and relative layout; if you need true UTM columns, bring the export's latitude/longitude into your GIS and reproject.
• GeoJSON export — unavailable in current firmware. Export CSV, identify its coordinate frame and epoch from the correction source or base coordinates, then transform it in suitable GIS software.
• Wingman — the observation and point files you share are stored under your organisation's account for download. Wingman does not currently convert .sht files to State Plane, UTM or XYZ; do that in your GIS or with NOAA's NCAT from the lat/lon in the file.

The touch screen, the saved-points lists and the NMEA stream stay in latitude/longitude.

How the zone is chosen

RoboDot picks the zone automatically from your longitude: zone = ⌊(longitude + 180) / 6⌋ + 1. The hemisphere letter comes from the sign of the latitude — N at or above the equator, S below. There is no zone setting: the displayed zone always follows the current longitude and cannot be locked to a neighbouring zone.

Two things follow from that:

• Near a zone boundary the reading switches zones. Zone edges sit on every multiple of 6° longitude (−78°, −72°, −66° … in the Americas). Step across one and the easting jumps by roughly half a million metres because the same spot is now measured from a different central meridian; the position has not changed, only its label. For a site that straddles a boundary, pick one zone in your office software and reproject everything into it.
• The standard zone exceptions are not applied. The official grid widens zone 32 over southern Norway and reshuffles zones 31–37 around Svalbard. RoboDot uses the plain 6° rule everywhere, so there the zone shown may differ from local convention.

UTM vs State Plane vs lat/lon

Match the coordinate system specified for the deliverable. Keep the original latitude/longitude and its datum, then project or transform in the office as required.

The datum question

A projection converts latitude/longitude to grid coordinates. A datum transformation changes the reference frame. RoboDot’s UTM display performs the projection only; it does not transform coordinates from your base or correction service.

A base position comes from one of three places, and each fixes the datum of everything measured against it:

• Auto survey (averaging) with no corrections — the receiver's own satellite solution, effectively WGS84/ITRF; it can differ from NAD83(2011) by 1–2 m in the contiguous US.
• A saved favourite or a typed position — whatever datum those numbers were in. Read the datum and epoch on the control record or OPUS report; do not infer them from the file format.
• A network (VRS/NTRIP) service — that network's datum; in the US normally NAD83(2011). Check the provider's mount-point description.

Current CSV and DXF exports identify the coordinate frame and epoch as unknown. Confirm both from the correction provider or control-point source; an observation timestamp is not a coordinate epoch. Older GeoJSON exports may carry a fixed WGS84 label even when the base used another datum. Check that source before importing older files. See Base Mode.

Worked example

The Status page reads latitude 40.712000000°, longitude −74.006100000° (lower Manhattan).

1. Zone: ⌊(−74.0061 + 180) / 6⌋ + 1 = ⌊17.67⌋ + 1 = 18; latitude positive, so N.
2. Central meridian of zone 18 is −75°; the point is 0.9939° east of it, about 83,952 m, so easting ≈ 500,000 + 83,952 = 583,951.930 mE. Northing along the grid from the equator = 4,507,262.097 mN.

RoboDot displays 18N 583951.930mE 4507262.097mN. If the base coordinates came from the NAD83(2011) result in an OPUS report, label it NAD83(2011) UTM zone 18N and retain the reported coordinate epoch.

Common mistakes

• Reading the CSV's Easting/Northing as UTM. They are local grid metres from the first exported point; reproject lat/lon for UTM.
• Mixing zones. Eastings from zone 17 and zone 18 cannot be subtracted. Reproject the whole job into one zone first.
• Dropping the hemisphere. Zone 18 alone is incomplete. RoboDot’s 18N means zone 18 in the northern hemisphere; its letter is not a latitude band.
• Assuming metres means US survey feet. RoboDot's UTM is metres. State Plane in many states is survey feet: 0.3048006096 m/ft, not 0.3048.
• Forgetting the datum. A UTM value without a datum is ambiguous by a metre or two in North America. Write down what the base was set from.
• Expecting the ellipsoidal height to be sea level. UTM covers the horizontal only; see Heights & Orthometric Elevation for the vertical.