The flight went fine, the processing finished, and the orthomosaic looks great. Then the client's engineer drops it into their drawing set and it lands in the wrong place, sometimes a few feet off, sometimes in another county, sometimes floating in the ocean. Usually nothing was wrong with the imagery. The map and the drawing were simply speaking different coordinate languages. This guide covers the coordinate system decisions in drone mapping that prevent that phone call: datums, projections, UTM, state plane, EPSG codes and the units that trip people up.
Start with a question, not a setting
Before you plan the flight, ask the client one thing: "What coordinate system are your files in?" Get the answer in writing, ideally as an EPSG code or a sample file you can open. Everything below is about understanding that answer and matching it. If the client doesn't know, the engineer or surveyor who set up the project will.
Geographic vs projected coordinates
There are two broad families of coordinates you'll run into.
- Geographic coordinates are latitude and longitude, measured in degrees on a model of the earth. They're what your drone logs and what most GNSS receivers display by default. They're awkward for measuring, because a degree of longitude isn't a fixed distance on the ground.
- Projected coordinates flatten a piece of the earth onto a grid, so positions become eastings and northings in meters or feet. CAD drawings, site plans and most engineering work live here.
EPSG.io's entry for EPSG:4326 (checked Nov 2, 2026) shows the difference plainly. It's listed as "WGS 84 -- WGS84 - World Geodetic System 1984, used in GPS", and its coordinate system is "Ellipsoidal 2D CS. Axes: latitude, longitude." A projected system such as EPSG:32615 (checked Nov 2, 2026), "WGS 84 / UTM zone 15N", uses "Cartesian 2D CS. Axes: easting, northing (E,N)."
Datums: the part people skip
A projection tells you how the grid is laid out. A datum tells you what the grid is tied to. The National Geodetic Survey's Datums and Reference Frames page (checked Nov 2, 2026) defines it this way: "A geodetic datum or reference frame is an abstract coordinate system with a reference surface (such as sea level) that serves to provide known locations to begin surveys and create maps."
For US work, two horizontal names come up constantly:
- NAD 83. NGS lists the North American Datum of 1983 as the current official geometric datum and notes that it "allows measurement of positions relative to an ellipsoid model of the Earth (latitude, longitude and ellipsoid height)." Most US engineering files sit on a version of NAD 83, such as NAD83(2011).
- WGS 84. The same NGS page describes WGS 84 as "Defined by the U.S. Department of Defense. Commonly used within civilian GPS software." That's why your raw drone positions usually arrive in WGS 84.
NAD 83 and WGS 84 are not interchangeable, even though they look similar in a viewer. If the client's drawings are on NAD 83 and your deliverable is labeled WGS 84, expect an offset. Our post on PPP and OPUS for drone mapping covers how you get an absolute coordinate tied to a known frame in the first place.
Vertical datums and the geoid
Heights have their own datum, and this is where a lot of elevation complaints start. Your GNSS receiver measures height above the ellipsoid, a smooth mathematical shape. Clients almost always want elevations relative to something closer to sea level. In most of the US that means NAVD 88, which NGS describes as a datum that "allows measurement of land elevations and water depths".
The bridge between ellipsoid heights and those elevations is a geoid model. Skip the geoid step and every elevation in your DSM can be off by a consistent amount. When you write down the client's coordinate system, write down the vertical datum and geoid model too. In EPSG terms, NAVD 88 height is EPSG:5703 (checked Nov 2, 2026), listed as "Datum: North American Vertical Datum 1988".
UTM zones
Universal Transverse Mercator splits the world into narrow north-south zones, each with its own grid in meters. It's popular for drone work because it's simple and global. Two practical notes:
- Pick the zone the site is actually in. EPSG.io's entry for EPSG:6344 (checked Nov 2, 2026), "NAD83(2011) / UTM zone 15N", gives its area of use as "between 96°W and 90°W".
- Know whose UTM it is. The NGS SPCS2022 Learn More page (checked Nov 2, 2026) notes: "The Universal Transverse Mercator (UTM) coordinate system and the United States National Grid (USNG) are not NGS products." UTM on NAD 83 and UTM on WGS 84 are different EPSG codes, which is why the code matters more than the word "UTM."
State plane
Many US engineers, surveyors and county GIS departments work in a State Plane Coordinate System zone. Each state has one or more zones designed to keep distortion low across that state, and the coordinates are usually in feet. If the client's files are in state plane, deliver in state plane.
NGS is rolling out a modernized system, SPCS2022. NGS's SPCS2022 Policy (checked Nov 2, 2026) states that "The 'U.S. survey foot' will not be supported for SPCS2022 or any other component of the Modernized NSRS." Confirm which version the project uses.
The foot problem
This is the classic gotcha. The US had two definitions of the foot: the international foot and the U.S. survey foot. The NGS notice on the final determination on retiring the U.S. survey foot (checked Nov 2, 2026) says it was deprecated on December 31, 2022 and "will be superseded by the international foot definition (1 foot = 0.3048 meter exactly) in all applications." The same notice adds: "However, NGS will continue to support the U.S. survey foot for the State Plane Coordinate Systems of 1983 and 1927."
In practice, that means plenty of existing state plane projects still use U.S. survey feet. EPSG.io's entry for EPSG:2276 (checked Nov 2, 2026), a NAD 83 Texas North Central zone, lists "Unit: US survey foot". Because state plane coordinates are large numbers, mixing up the two feet produces a visible shift. Match the unit to the client's file, not to whatever your software calls "feet."
EPSG codes: the shorthand that saves the job
An EPSG code bundles the datum, projection and units into one number. "NAD83(2011) / UTM zone 15N" is EPSG:6344. "WGS 84 / UTM zone 15N" is EPSG:32615. Asking a client for "the EPSG code of your drawings" removes most of the guesswork, and putting it in your delivery notes helps their CAD tech load your files correctly. Look codes up on EPSG.io.
Matching the client's drawing set
A simple workflow that holds up on most jobs:
- Get the target. Horizontal coordinate system (ideally an EPSG code), units, vertical datum and geoid model, in writing.
- Tie your data to a known frame. Use corrected positions, control or both. Our guide to ground control points for drone mapping covers when you need them and where they go.
- Process and export in the target system, using your processing software's documented tools, or a conversion tool you trust, before anything leaves your office.
- Overlay before you deliver. Drop the ortho onto the client's base file or a known feature. If a road edge or building corner lines up, you're in the right system. If not, check datum, units and zone before anything else.
- Label everything. Coordinate system, EPSG code, units and vertical datum go in the file names or a readme with the delivery.
Lining up with the client's drawings is one question; how close your map is to true ground position is another. Our post on absolute vs relative accuracy covers that side. And one firm line: anything involving property lines, boundaries or legal descriptions belongs to a licensed surveyor. A well-referenced drone map can support their work, but it doesn't replace it.
Where SkyView fits
If you process in-house, SkyView, Pilot Ledger's desktop processing, builds RGB orthomosaics and DSM/DTM surfaces locally on Windows with no per-map fee, and exports georeferenced rasters for client delivery. See how a delivery package comes together in our post on exporting a GeoTIFF package. The coordinate system decision above still comes first.
Get the coordinate system right on the first delivery and the client stops thinking about it, which is exactly the goal. If you want one place to run the business side of your mapping work, see Pilot Ledger plans and pricing.