Known limitations
What OpenSurvey3D doesn't do yet — datums and epochs, geoids, ground coordinates, stakeout tolerance, offset shots, GIS export frames and more.
On this page
- Coordinates and datums
- NAD83 is treated as WGS 84
- No geoid model on the device
- No ground-scaled export
- Site localization is reported, not applied
- GeoPackage and Shapefile exports are in WGS 84 degrees
- Alaska zone 1 is missing
- Field work
- Stakeout tolerance starts at 0.5 m
- No offset shots
- No inserting or deleting vertices on a saved line
- Averaging has no minimum-epoch setting
- Receivers
- Bluetooth receivers aren't bench-tested yet
- Phone GPS heights are rough
- Maps, 3D and capture
- Terrain is public elevation data
- Mesh scanning isn't open yet
- Compass headings on scans
- Import
- Related
OpenSurvey3D tries to be clear about what it can and can't do. This page lists the gaps that matter most for survey work, so you can plan around them. Many of the same caveats are written into the exports and the QA report.
Coordinates and datums
NAD83 is treated as WGS 84
The app doesn't handle datum realizations or epochs. It labels coordinates NAD83 but treats NAD83 and WGS 84 as the same, a difference of about 1–2 m at current epochs.
- On a NAD83(2011) network (a state CORS or VRS network such as KYCORS), the receiver already delivers NAD83(2011) coordinates, so the numbers are right. Write the realization and epoch on your plat yourself.
- On an ITRF-based service (for example a global correction service or your own base on an autonomous position), coordinates land about 1.5 m off NAD83, and the app can't tell.
See NAD83 vs ITRF: datums and epochs.
No geoid model on the device
The app doesn't carry a geoid grid. Elevations above sea level (NAVD88, for example) depend on the geoid your receiver applies. The project's vertical datum setting records what you declare; it doesn't verify it. Check in your receiver's own app which geoid it uses. See Vertical datum.
No ground-scaled export
COGO reports the combined factor and ground distance for each line, but exports are always in grid coordinates. There's no ground-scaled export.
Site localization is reported, not applied
The app solves a site localization from your check shots and reports its residuals and parameters, but it doesn't apply it. No coordinate in the app or its exports is transformed by it. See Site localization.
GeoPackage and Shapefile exports are in WGS 84 degrees
Both always export longitude and latitude (EPSG:4326), not state plane. The project's zone is recorded in the files' notes. For state plane deliverables, use PNEZD, CSV, DXF or LandXML. See Export formats.
Alaska zone 1 is missing
Alaska state plane zone 1 (an oblique Mercator projection) isn't in the list of coordinate systems.
Field work
Stakeout tolerance starts at 0.5 m
The tightest stakeout tolerance is 0.5 m. Use stakeout to find monuments and features, not to set them. See Stakeout.
No offset shots
You can't record a point by distance and bearing from where you stand, for a corner you can't occupy. The map crosshair can drop a point by hand instead, and it's recorded as placed manually.
No inserting or deleting vertices on a saved line
Once a line or area is saved, you can edit or re-measure an existing vertex, but you can't add or remove vertices.
Averaging has no minimum-epoch setting
An averaged occupation runs until you stop it. There's no setting to require a minimum number of epochs. Watch the sample count and the spread, and stop once they've settled.
Receivers
Bluetooth receivers aren't bench-tested yet
Bluetooth supports two families of receivers: the Emlid Reach RX, RX2 and RS4, and the Bad Elf Flex and Flex Mini. Neither has had a full hardware bench test yet.
- Sending corrections to a Bad Elf Extreme over Bluetooth hasn't been confirmed. Running NTRIP in the Bad Elf Flex app in the background works regardless.
- The Emlid Reach RS2 and RS2+ can't stream to third-party iOS apps over Bluetooth. Use their Wi-Fi hotspot instead.
See Connect a Bluetooth receiver.
Phone GPS heights are rough
Without a receiver, heights can be 5–15 m off. In the 3D view they snap to the terrain by default. The QA report flags any height with a vertical accuracy worse than 3 m as phone-GPS grade. See Phone GPS vs a receiver.
Maps, 3D and capture
Terrain is public elevation data
The 3D site model uses public elevation models, about 10 m resolution in the US and 30 m elsewhere. Heights are above sea level. In dense cities the data is often a surface model, so buildings appear as blocks. See 3D site model.
Mesh scanning isn't open yet
The mesh Scan mode is listed but not yet available for capture. Point-cloud capture and photo capture (Object Capture) work on supported devices. See 3D capture overview.
Compass headings on scans
A scan oriented by the phone's compass can be 10–20° off in the open, and worse near metal. At working range that's metres of error. Walking a few metres during capture lets the heading come from the GNSS track instead.
Import
- Polygon holes aren't imported; only outer rings come in.
- KMZ files aren't read; use plain KML.
- A headerless point file with numeric point numbers needs a header row. See Import.