--- title: UTM Coordinates order: 1 --- # UTM Coordinates RoboDot works in latitude and longitude, but most site work is easier in metres. This page explains what UTM is, what RoboDot shows in UTM, how the zone is chosen, and how UTM relates to State Plane and the datum of your job. ## 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`. Why bother? A degree of longitude is a different length at every latitude, and "0.00001°" means nothing to a tape measure. In UTM, subtracting two eastings gives metres, distances and areas come straight from Pythagoras, and every CAD and GIS package understands the numbers. Within one zone the scale distortion is at most 0.04 %, well below what a site survey cares about. ## What RoboDot gives you * **Web UI Status page** — the position card shows a live **UTM (meters)** line under the latitude/longitude, recomputed from the current RTK position on every refresh, as ` mE mN`, always in metres, to the millimetre. It is standard UTM on the WGS84 ellipsoid (0.9996 scale factor, 500,000 m false easting), computed with a high-order series that matches reference geodesy libraries to better than a millimetre. * **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** — longitude/latitude with the **ground height above the ellipsoid** as the third coordinate (antenna height minus pole height and phase-centre offset; no geoid correction). When a geoid model is loaded, an orthometric ground height is added as a separate `ortho_gnd` property labelled with the model name. Every GIS reads the file and reprojects to UTM on import. * **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 | System | Best for | Watch out for | | ---------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **Lat/lon** | Sharing positions, GIS, anything global; the native RoboDot format | Not metres; poor for distance and area by hand | | **UTM** | Drone mapping, GIS field work, sites that need metres without a local convention | Zone boundaries; up to 0.04 % scale distortion; not what most US deeds and plans use | | **State Plane** | US legal surveying, matching existing plans and county control | Defined per state or sub-zone, in US survey feet or metres; not shown on the device — convert in your GIS or with NOAA's NCAT | Rule of thumb: match whatever the deliverable already uses — US photogrammetry is usually UTM, boundary and construction work State Plane. RoboDot's lat/lon goes into either without loss, so record in lat/lon and project in the office. ## The datum question A projection turns latitude and longitude into easting and northing. It does **not** change the datum: NAD83(2011) in gives NAD83(2011) UTM out, WGS84 in gives WGS84 UTM out. RoboDot contains no datum transformation of any kind. The base position is handed to the receiver exactly as it was obtained, and every rover fix, the UTM line, the point lists and all exports carry that datum through unchanged. 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. An OPUS solution or published control in the US is NAD83(2011), so every rover fix relative to it is NAD83(2011). * **A network (VRS/NTRIP) service** — that network's datum; in the US normally NAD83(2011). Check the provider's mount-point description. One label to read carefully: the GeoJSON header says `"heights":"ground, ellipsoidal (WGS-84)"`. That text is fixed and names the ellipsoid, not the datum of your job: with an OPUS or NAD83(2011) base the coordinates and heights in that file are NAD83(2011), and you should say so when you hand it on. The ellipsoid shape is the same either way (WGS84 and GRS80 differ by a fraction of a millimetre), so the UTM numbers are right for both; only the datum tag is yours to carry forward. See [Base Mode](../robodot-touch-user-guide/operating-modes/base-mode) for how a base position is set. ## 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`. With an OPUS-set base, quote it as *NAD83(2011) UTM zone 18N*; with an uncorrected auto survey, *WGS84 UTM zone 18N*. ## 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.** `18` is not a zone; `18N` is. The letter is the hemisphere, not the latitude band some software prints. * **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](../robodot-touch-user-guide/heights-and-orthometric-elevation) for the vertical.