Coordinate Reference System

Tell MultiSet which survey grid your E57 was exported in, so the scan lands in the right place without hand-solving control points.

Overview

A surveyed E57 carries coordinates in some grid: a national or UTM projection, or a private site grid the plant owner maintains. The file rarely says which. Without that information MultiSet falls back to inferring a UTM zone from the location you pinned when creating the map, which is good enough for a walk-around scan and not good enough for survey work.

Declaring the grid removes the guesswork. Send it as source.metadata.crs on the create-map request when fileType is e57, and the scan is georeferenced directly from it.

There are two forms, and you send exactly one:

Form	Use it when	Fields
EPSG code	The scan is in a published grid (national, UTM, state plane)	horizontalEpsg, optionally verticalEpsg
Helmert	The scan is in a private plant or site grid with no EPSG code	helmert (7 parameters)

This applies to E57 uploads only. A Matterport capture always arrives in its own local frame, so crs is rejected for matterpak.

Form 1: an EPSG code

For a scan exported in a published grid. horizontalEpsg names the grid. verticalEpsg is added only when the heights are not ellipsoidal.

A German export in ETRS89 / UTM 32N with GPS (ellipsoidal) heights needs the horizontal code alone:

{
  "source": {
    "fileType": "e57",
    "provider": "navvis",
    "metadata": {
      "crs": { "horizontalEpsg": 25832 }
    }
  }
}

A US export on a state plane grid with orthometric heights needs both:

{
  "source": {
    "fileType": "e57",
    "provider": "leica",
    "metadata": {
      "crs": {
        "horizontalEpsg": 6424,
        "verticalEpsg": 6360
      }
    }
  }
}

Choosing the horizontal code

horizontalEpsg must be a projected grid, because E57 stores Cartesian coordinates. Common choices are 25832 (ETRS89 / UTM 32N), 27700 (British National Grid) and 2056 (Swiss LV95).

A geographic code such as 4326 is rejected, with a message naming the CRS and its type. So are vendor codes outside the EPSG range, such as ESRI 102100.

Choosing the vertical code

Send verticalEpsg only when heights are orthometric, for example 3855 (EGM2008), 5701 (ODN) or 5703 (NAVD88).

Ellipsoidal is assumed when verticalEpsg is absent, and whether heights are ellipsoidal or orthometric is the one thing neither the file nor your map pin can reveal.

Get it wrong and the scan is off vertically by the local geoid undulation, which is roughly 46 m in Bavaria and roughly -90 m at Bengaluru. Everything horizontal will look perfect, so the error is easy to miss.

Units are handled for you

The EPSG code carries its own units, so a grid in US survey feet needs nothing extra. Send the code for the grid the survey was worked in and the units are handled for you.

Form 2: a Helmert transform

For a scan in a private grid that has no EPSG code, which is common on industrial sites where the owner maintains their own plant grid. The seven numbers come from the site owner's surveyed transform and are reused for every scan on that site.

{
  "source": {
    "fileType": "e57",
    "provider": "navvis",
    "metadata": {
      "crs": {
        "helmert": {
          "tx_m": 145200.5,
          "ty_m": -4790100.25,
          "tz_m": 4195800.75,
          "rx_arcsec": 174900.0,
          "ry_arcsec": -2500.0,
          "rz_arcsec": 8760.0,
          "scale_ppm": -0.0159
        }
      }
    }
  }
}

The convention

This is a 7-parameter Helmert (Bursa-Wolf) transform from the file's local grid in metres to WGS 84 ECEF (EPSG:4978).

Detail	Value
Convention	Position-vector
Rotation order	Composed Rz · Ry · Rx
Translations	Metres
Rotations	Arcseconds
Scale	ppm, applied as s = 1 + scale_ppm × 1e-6

All seven parameters are required, and no other keys are accepted.

Check the convention before you send a transform. A coordinate-frame Helmert uses the opposite rotation sign to a position-vector one. Published parameter sets do not always say which they are, and the two differ by enough to put a scan visibly out of place.

Heights from a Helmert are already ellipsoidal, so verticalEpsg is not allowed alongside it and is rejected if sent.

Do not send an accompanying affine fit either. The two are independent solutions and must never be chained.

What happens to the values you send

Your declaration wins

When crs is present it is the source of truth, and anything the file itself declares is not used. If the file declares a grid that disagrees, yours is still applied and the difference is recorded on the map.

That is deliberate: correcting a bad export is the main reason the field exists.

The result is sanity-checked

The resulting position is compared against the location you pinned when creating the map, and a result far from that pin is flagged on the map rather than silently accepted.

Treat that flag as a strong signal that the wrong grid, or the wrong Helmert convention, was sent.

What lands on the map

Either form produces the same two fields the rest of the platform uses:

• location.coordinates, as [longitude, latitude, altitude] with an ellipsoidal altitude,

• heading, in degrees.

The map also records which of the three sources the georeference came from, so you can audit it later.

Doing it from the portal

The Developer Portal collects the horizontal grid on the Location step of the create-map flow, with a list of common grids plus an Other option for entering an EPSG code directly. The vertical datum is offered only when you set the height reference to geoid, matching the rule above.

The Helmert form is API only. A site grid transform is not something you want retyped by hand into a form.

Related

• Georeference Map, for tying an existing map to WGS 84 with ground control points instead.

• Geo-fence, which is generated from the resulting location and heading.

• Leica Scans, NavVis Scans and Faro Scans for exporting an E57 from each vendor.