Choose an export format

Every export is free, and every one carries more than coordinates. Each file says which coordinate frame it's in, and the CSV and GeoJSON carry the full measurement record behind each point. Project data exports are on Tools → Data. Scan and terrain exports live with the capture or the site model.

Before you start

• An active project with at least one asset. The Data exports are greyed out when the project is empty. Tapping one with no project open offers the project chooser.
• A projected coordinate system (Tools → Coordinate system) if you want state plane or UTM northings and eastings. See Coordinates without a zone.

Export and share

1. Go to Tools and tap an export under Data, for example Export DXF (CAD).
2. The iOS share sheet opens. Send the file with AirDrop, Mail or Messages, save it to Files, or open it in another app.

Files are named after the project and the time, for example lot-12-20260911-143005.dxf.

Which format to use

The Data exports

The Units setting under Settings → Display only changes what you see on screen. Exports always use the units in this table.

Export CSV

One row per vertex, so a line's vertices are consecutive rows. Columns:

• Identity: name, code, type, role (collected or design), geometry, vertex.
• Position: latitude, longitude; with a zone, easting_<unit>, northing_<unit> and crs_epsg; elevation_msl_m, ellipsoidal_height_m.
• Quality: h_accuracy_m, v_accuracy_m, source, fix, samples, timestamp_utc.
• Attachments and notes: notes, photos, scans (file names).
• The measurement record: satellites, PDOP/HDOP/VDOP, sigmas, correction age and source, base distance, antenna height, tilt compensation, receiver, averaging spread, the zone in force when measured, operator, app version, device and timestamp source. After those come vertical_reference and horizontal_datum.
• Attributes: one column for every attribute used anywhere in the project.

A blank field means the value wasn't recorded. It's never written as zero.

Point file (PNEZD)

P,N,E,Z,D with no header row: point number, northing, easting, elevation, description. Point numbers run from 1 in export order, one per vertex, so a line's shots are numbered consecutively. The description is the feature code followed by the name, and any commas in it become spaces. This is the file most survey packages import with their default point format.

The row is greyed out until the project has a projected coordinate system. A PNEZD file only makes sense in a grid.

Export GeoJSON

One feature per asset, as a real Point, LineString or Polygon, in WGS 84 longitude and latitude. Geometry Z is the ellipsoidal height. Orthometric elevations travel in elevation_msl_m for points and elevations_msl_m for lines and areas, one per vertex.

Properties include name, code, layer, type, role, fix, worst_h_accuracy_m, length or perimeter, area, notes, photos and scans, and a pedigree object holding the measurement record. Attributes keep their natural types, so a number stays a number. A metadata block states the datums and names the project's zone for reference.

Export DXF (CAD)

A DXF R12 drawing, the version every CAD package can open.

• Layers come from the feature codes, coloured as in the app. A point's name is drawn as a text label on a separate <layer>-TEXT layer, so a drafter can switch labels off.
• Lines and areas are polylines.
• Attributes (code, name, description, whether the feature is design data, and any attribute values) are stored as extended data on each entity.
• The header comments state the coordinate frame and the height reference.
• Heights: features without a measured height sit at 0.

Export LandXML

LandXML 1.2, the survey interchange format. Points go out as CgPoints with name, code and description intact. Lines and areas go out as plan features. The file declares its units, the zone's EPSG code, its horizontal datum and the project's vertical datum. Coordinates are written northing first, as the schema requires.

Export GeoPackage

A single file with one layer per feature code. Each layer has typed columns: name, code, layer, role, notes, elevation_msl_m, h_accuracy_m, fix, source, timestamp_utc, plus that code's own attributes. An opensurvey3d_metadata table records the project, the datum notes and the project's zone.

Export Shapefile (ZIP)

A ZIP with a set of files per geometry type (points, lines, polygons). Each set has its .shp, .shx, .dbf, a .prj and a .cpg naming UTF-8 encoding. Geometry is 2D, and the elevation is in the ELEV_M attribute. dBase caps field names at 10 characters, so long attribute names are shortened. The README.txt in the ZIP lists every shortened name.

Coordinates without a zone

DXF and LandXML hold flat eastings and northings, not latitudes. If the project has no projected coordinate system, the app doesn't refuse. Instead it builds a local transverse Mercator centred on your data, in metres, and the file header says plainly that the coordinates are local and not a published grid. If the project spreads more than 50 km from its centre, the header also warns how much distance distortion to expect. Set a real zone before exporting anything that measurements will be taken from.

Scan and terrain exports

LAS is the only one of these in ground coordinates. It's turned from true north to grid north at the scan's anchor. It refuses rather than guesses: a point cloud with no position fix, no heading or no anchor height can't be placed, so the app explains why and suggests sharing the PLY instead. With no project zone, the LAS is placed on a local transverse Mercator and declares no coordinate system.

PLY, OBJ and USDZ stay in the scan's local frame, in metres from where the scan started. The georeferencing for them lives in the scan's georef.json, which travels in the bundle.

Terrain OBJ is in the site frame (x east, y up, z south, metres) and opens as a georeferenced mesh in Blender with BlenderGIS. See Export terrain.

Related

• Export a project bundle
• The QA report
• Coordinate systems
• Vertical datum
• Feature codes
• Feature codes, DXF and LandXML for field-to-finish