Skip to main content
Version: 3.4.3

Coordinate Systems and Georeferencing

Almost everything in VRGS that reaches outside the project — satellite imagery, the globe, GNSS, KML export, photogrammetric GPS — has to convert between the project's coordinates and the rest of the world. That conversion needs a project coordinate reference system, and getting it wrong fails silently: the model still loads, the numbers still look plausible, and everything is in the wrong place.

This guide is about setting it correctly and recognising when it is not.

What VRGS stores​

Every ordinate — X, Y and Z — is in the project CRS's horizontal linear unit.If your CRS is in US survey feet, elevations are in feet too. That is the convention survey data arrives in, and VRGS keeps it.
Nothing is stored in latitude and longitude.Data that arrives as lat/long is converted on the way in and stored in project coordinates like everything else.

The second point matters more than it sounds: a GNSS fix, a photograph's EXIF GPS position, an imported KML — all of them are projected into the project frame at import. If there is no CRS, they cannot be placed at all, and VRGS will tell you so rather than dropping them at the origin.

Setting the project CRS​

  1. Open the project properties (the project-settings button at the top of the Properties panel).
  2. Find EPSG Code under General and click the … button.
  3. Search the coordinate-system list. Search matches the whole phrase, so start broad — UTM, or OSGB — and narrow afterwards.
  4. Pick the system and accept.

The property also shows the CRS's Description and Code read back, which is the quickest way to confirm you got the one you meant.

Set it before you load data, not after

Data is converted into the project frame as it is imported. Setting the CRS afterwards does not retrospectively move anything that came in without one.

For a walkthrough with screenshots, see Setting the coordinate system.

Linear units​

A CRS in feet stores everything in feet. VRGS handles the conversion where it has to, but there are two consequences worth knowing.

Every distance you measure is in project units. A measurement of 12.4 on a US-survey-feet project is 12.4 feet. Dialogs and docs generally say "m" because most projects are metric — read it as "project linear units".

Anything leaving the project is converted to metres, because that is what every external consumer expects. VRGS reads the conversion factor from the CRS itself, so this is automatic — but it is also why a project whose CRS is not set can produce output that is out by a factor of 3.28.

Mixing units in one project

A mesh exported in feet and imported into a metric project arrives 3.28× too large. Fix it at import with Transform → Coordinate Conversion → Feet to Meters on the object, before interpreting on it — see Preparing a Model.

Vertical datums and heights​

Horizontal position and height are separate problems, and height is the one that goes wrong quietly.

There are two kinds of height:

EllipsoidalHeight above the mathematical ellipsoid. What GNSS receivers natively measure, and what most drones write into EXIF.
Orthometric (MSL)Height above the geoid — "height above sea level". What survey data and topographic maps use.

They differ by the geoid separation, which is tens of metres in many parts of the world.

Enabling the geoid transform​

In the same EPSG Code property:

SettingWhat it does
Vertical Datum TransformsTurn the geoid correction on for the project.
Vertical DatumThe geoid model: None, EGM2008 (EPSG:3855) or EGM96 (EPSG:5773).

With it on, VRGS converts ellipsoidal heights coming in from GNSS and photogrammetry into the project's orthometric frame, instead of treating the two as interchangeable.

The SfM altitude datum is a separate decision

The SfM workflow has its own GPS altitude is MSL setting, because only you know what the camera wrote. Off (the default) means the EXIF altitude is an ellipsoidal height — true of most drones despite the EXIF specification saying otherwise — and it is geoid-corrected on the way in. On means it is already MSL and is used as-is.

Guessing this wrong shifts the whole model vertically by the local geoid separation.

What changed, and which projects it affects​

The project↔WGS84 conversion now transforms heights as well as horizontal position. Previously the height passed through untouched, so VRGS and its own KML export could disagree about the same point by the size of the datum's height shift.

The projects that moved are the ones on legacy datums:

DatumHeight shift
OSGB36 / British National Grid+49.53 m
Belge 1972 / Lambert 72+42.87 m
NAD27 / BLM 13N (ftUS)−32.27 m
NAD83 / UTM, WGS 84 / UTM, RGF930.00 m

Modern WGS84-aligned datums are unaffected, whatever their units. If you have an older project on a legacy datum and its position relative to satellite imagery looks different from how you remember it, this is why — and the new answer is the correct one.

Reprojecting data that arrives in the wrong frame​

Objects carry their own coordinates, so a single object in the wrong CRS can be converted without touching the rest of the project. On a mesh, point cloud, polyline or orientation group's Transform submenu:

CommandWhat it does
Between Coordinate Systems (CRS)Reproject the object from one CRS to another.
Meters to Feet / Feet to MetersFix a unit mismatch.
Suggest UTM ZoneWork out the appropriate UTM zone from the object's position — useful when you know the data is UTM but not which zone.
Translate, Rotate, ScaleManual correction where there is no formal CRS to convert from.

For two datasets that should overlay but do not — and where no reprojection will fix it, because one of them was never georeferenced — use ICP Alignment to register one onto the other, or ground control points in the SfM workflow.

What depends on the CRS​

FeatureWhat it needs the CRS for
GNSS field navigationPlacing a live fix. A capture with no project CRS is refused, with the reason given, rather than landing at the origin.
Satellite imagery and the globePositioning the model on the Earth. Cesium and Google 3D Tiles both work through this transform.
SfMConverting camera GPS positions and ground control into the project frame.
GeoJSON export and KMLWriting coordinates a GIS can read.
Field guide mapsPlacing the guide's spots and the model's footprint on a real map.
Imported GIS layersReprojecting them onto the project.

Diagnosing a georeferencing problem​

Work through these in order — the answer is usually in the first two.

1. Is the project CRS set at all? Check EPSG Code in the project properties. Blank means every one of the features above is either disabled or falling back to something arbitrary.

2. Is the model in roughly the right place on the globe? Turn on a satellite basemap and look. Errors have characteristic sizes:

SymptomLikely cause
Model at (0, 0), or at the project originIt never had georeferencing, or arrived before the CRS was set.
Right shape, in the wrong countryWrong CRS — often the right projection, wrong zone. Suggest UTM Zone on the object will tell you which it should be.
Right place, 3.28× too big or too smallFeet / metres mismatch.
Right place horizontally, tens of metres out verticallyVertical datum: either the geoid transform is off when it should be on, or the SfM altitude datum was set the wrong way.
Right place, kilometres too highElevations in feet being read as metres — a unit mismatch compounding into a datum shift.
Two models offset from each other by a constantOne is georeferenced and one is not, or they are on different datums.

3. Does the height agree with something you trust? Compare a known point against a map or a GNSS reading. A constant offset of tens of metres is a geoid problem, not a positioning one.

Tips and troubleshooting​

  • The CRS search finds nothing. It matches the whole phrase. Search UTM before WGS 84 / UTM zone 30N.
  • A GNSS capture says the position cannot be placed. Either there is no project CRS, or the fix is outside the CRS's valid domain — a UTM zone covers 6° of longitude and refuses positions outside it.
  • Satellite imagery is offset from the model. Check the CRS first, then the vertical datum. An old project on a legacy datum may simply be showing you the corrected height for the first time.
  • My measurements are in the wrong units. They are in project linear units. If the CRS is in feet, so are the measurements.
  • I reprojected an object and my interpretation stayed behind. Interpretations are separate objects with their own coordinates. Convert them too, or — better — get the CRS right before interpreting.

See also​