Key takeaways
- A drone survey delivered in the wrong coordinate reference is not slightly wrong. It lands somewhere else entirely, or it lands in the right place and quietly measures distances that do not match the site's existing drawings.
- The rule that resolves almost every case: match whatever your existing site data is already in. A survey that disagrees with the drawings you already hold is the survey everyone will distrust, whether or not it is the correct one.
- Horizontal and vertical are separate decisions. Elevations need their own named reference, and the difference between the current and legacy Canadian vertical datums is large enough to matter on a real job.
- Site grids are common on Alberta industrial ground and are the easiest way to get this wrong, because the transformation between the site grid and a published system lives in somebody's file rather than in the data.
Coordinate systems are the least glamorous line in a survey scope and the one that most often produces a deliverable somebody cannot use. The flight went well, the accuracy report is good, and the file opens in the wrong place — or worse, in the right place, while quietly measuring distances that do not match the drawings the site has used for twenty years.
This is a decision, it belongs in the scope before the flight, and it takes about two minutes to make if you know which questions to ask.
The rule that answers most of it
Match your existing data. If the site already has a survey, a set of drawings, a design model or a GIS layer, the drone survey should be delivered in whatever those are already on. Being independently correct is not the goal; being comparable is. A new survey that disagrees with the existing record is the one everybody will distrust, and resolving that argument costs more than the survey did.
If nothing exists yet, then you get to choose properly, and the rest of this is how.
Latitude and longitude is not a working coordinate system
Raw GNSS positions come out as latitude, longitude and ellipsoid height. That is a position on a curved earth in angular units, and you cannot measure an area or a volume in degrees. Everything practical — distances, areas, cut and fill — happens in a projected system with metres on both axes.
So there are really two questions: which projection, and which datum the projection sits on.
Datum first: NAD83(CSRS), and the epoch
In Canada the working horizontal datum is NAD83(CSRS), the Canadian Spatial Reference System realisation of NAD83. Most Alberta survey and engineering data is on it, and it is the sensible default.
Two things trip people up here. First, WGS84 — what a consumer GPS or an uncorrected drone log reports — is a different datum, and treating the two as interchangeable introduces an offset that is small enough to survive a casual look and large enough to matter on an engineering deliverable. Second, a modern datum realisation carries an epoch, because the ground itself moves. For most work the epoch is inherited from whatever your correction network is on, but if you are comparing today's survey to one from years ago at tight tolerance, it is a question worth asking rather than assuming.
Write the datum and the epoch into the scope. "NAD83" on its own is an under-specified answer that has caused a lot of rework.
Projection: UTM, 3TM or 10TM in Alberta
Three projected systems cover most Alberta work.
UTM
Universal Transverse Mercator divides the world into six-degree zones. Alberta spans zone 11 in the west and zone 12 in the east. UTM is universally understood, every piece of software handles it, and it is the right default for regional work, mapping and anything that will be shared widely.
Its weakness is the width of the zone. A six-degree zone is a lot of curved earth flattened onto a plane, so grid distances and ground distances differ by an amount that varies across the zone. For a stockpile that is irrelevant. For a long linear alignment where the drawings quote ground distances, it is not.
The other UTM trap in Alberta is the zone boundary itself. A project that straddles it has to pick a zone and stay in it, and two contractors independently picking different zones for adjacent work is a real and recurring problem.
Alberta 3TM
Alberta's own Three Degree Transverse Mercator system uses narrower zones, centred on the 111°, 114°, 117° and 120° west meridians. Narrower zones mean less distortion, so grid distances stay closer to ground distances across the zone. 3TM is common in Alberta cadastral, municipal, oil and gas and engineering data, and if the existing site drawings are on it, so should your drone survey be.
Alberta 10TM
The ten-degree Transverse Mercator system, centred on 115° west, covers the whole province in a single zone. That makes it convenient for provincial-scale data — you will meet it in forestry, resource and some government datasets — at the cost of more distortion than 3TM within any given local area. It is a good province-wide container and a poor choice for tight local engineering work.
Site grids: the common Alberta case, and the risky one
A great deal of Alberta industrial ground — plants, mines, large facilities — is built on a local site grid. It was established once, everything since has been designed and built on it, and the site will reasonably expect the drone survey in it too.
That is fine, and it is normal work. The risk is that the relationship between the site grid and any published system usually exists as a transformation held in one file, on one machine, controlled by one person, and often undocumented. If that relationship is wrong or lost, the survey is internally consistent and externally useless.
So, three questions before agreeing to deliver on a site grid:
- Who holds the transformation, and can they provide it in writing rather than as a setting inside a project file?
- Are there physical control monuments on site whose site-grid coordinates are published and can be occupied to verify it?
- Do you also want a copy in a published system? The answer should almost always be yes — deliver both, so the data survives the loss of the transformation.
Vertical is a separate decision, and it is the one that hurts
Horizontal usually gets discussed. Vertical usually gets assumed, which is backwards, because the vertical mistakes are bigger and harder to spot.
An ellipsoid height is a height above a mathematical model of the earth. It is not an elevation anybody on site is using. Real elevations are orthometric — heights above a geoid model — and converting between the two requires a geoid model, applied deliberately.
In Canada the current national vertical datum is CGVD2013, realised through a published geoid model. The legacy datum, CGVD28, is what a great deal of older Alberta data sits on, and the difference between the two is not a rounding error — it is large enough to matter on any job where elevations are compared. Add a site benchmark or an assumed local datum and you now have three plausible sets of elevations for the same ground.
The practical version: name the vertical datum in the scope, name the geoid model if a conversion is being applied, and if the site uses a local benchmark, name the benchmark. Then verify — occupy a known point and check the delivered elevation against its published value before anyone builds on the file.
Units, and the small stuff that still breaks files
- Metres or feet, and if feet, which foot — the international foot and the US survey foot are not the same, and mixing them over a large coordinate value produces a shift big enough to notice.
- Coordinate order. Northing/easting or easting/northing, latitude/longitude or longitude/latitude. Different software disagrees, and a swapped pair puts the site in the ocean, which at least is obvious.
- Large coordinate values. Some design software loses precision a long way from the origin, which is why site grids and local offsets exist. If your CAD team asks for a translated origin, that is a legitimate request — just document the offset.
- The projection file. Deliverables should carry their reference with them: a
.prjalongside a shapefile, embedded reference in a GeoTIFF, a stated system in a point-cloud header. A file that does not declare what it is on will eventually be opened by somebody who guesses.
What to write in the scope
One line covers it:
Deliverables in [projected system and zone], [datum and epoch], with elevations on [vertical datum, and geoid model if converted], in [units], with the coordinate reference embedded in every delivered file. Where a site grid is required, deliver in both the site grid and the published system, and state the transformation applied.
If you cannot fill in the blanks, that is the question to ask your surveyor, your GIS group or whoever owns the existing site data — before the flight, not after. It belongs in the survey RFP alongside the accuracy clause; our post on what to put in a drone survey RFP covers the rest of that document.
Verify it on arrival
Whatever was specified, check it before the deliverable is used. Occupy or identify a point whose coordinates and elevation you already know independently, read it off the delivered product, and compare. It takes minutes and it catches the entire class of problem this article is about, including the ones nobody thought to specify.