Side by side
| Your survey is in the wrong place | The basemap is in the wrong place | |
|---|---|---|
| Shape of the offset | Often varies - per image, per part of the site, or with terrain | One vector over the whole scene, including ground you never flew |
| Nearby features | Your data moves; roads and roofs around it stay consistent with each other | Everything in the tile moves together, your data included |
| A second reference | Ground control and a second basemap both agree with the basemap | Ground control and a second basemap both agree with your survey |
| Over time | Fixed by reflying with RTK or GCPs, or by reprocessing | Changes on its own when the provider refreshes that tile |
| What the files say | A float or single-point RTK flag, or a CRS nobody chose deliberately | Nothing in your files is wrong |
| Published accuracy | RTK is specified at 1 cm + 1 ppm horizontal, 1.5 cm + 1 ppm vertical | Maxar Vivid has been quoted at 4 to 5 m CE90; Google publishes nothing |
| Who can fix it | You, with control or a correct CRS | Nobody here - you can only stop treating it as truth |
The three numbers that name the cause
Measure the offset before explaining it. Pick five to ten features you can identify in both datasets - painted road markings, building corners, manhole covers, fence posts - and record the displacement and its bearing at each one. What you want is a vector per point, not an impression that the map is a bit off.
Three properties then do the diagnosis. Magnitude: centimetres, a few metres, tens of metres, or hundreds of kilometres. Uniformity: one vector everywhere, or one that changes across the site or between images. Axis: horizontal, vertical, or both. A uniform offset is a definition problem - a datum, a projection, an EPSG code, a geoid. A varying one is a measurement problem - GNSS quality, control geometry, or the surface the orthomosaic was draped over.
Direction carries information too. A systematic lean toward one quadrant across an entire scene, affecting features nobody surveyed, is the signature of the reference rather than the survey. A 2022 study of historical Google Earth imagery over Lagos found that pattern, with errors skewed west and north-west. Read your own numbers first, then find the signature below that matches.
A few metres, different for every image: no RTK fix
This is the common case, and the published specifications are easy to misread. DJI quotes hovering accuracy for the Phantom 4 RTK as plus or minus 0.1 m vertically and 0.3 m horizontally on the vision system, and 0.5 m vertically and 1.5 m horizontally on GNSS alone, against 0.1 m in both axes with RTK. Those are station-keeping figures - how tightly the aircraft holds a spot in the air - and they say nothing about where that spot is on the earth.
The absolute number is quoted wrongly as often. The GPS Standard Positioning Service standard commits to an RMS user range error no worse than 6 m in any 24-hour interval, with a global average of 7.8 m at 95 percent across all ages of data - an error in the broadcast signal, not in your position. Measured position error is better: an FAA report for the last quarter of 2019 recorded maximum 95 percent errors of 2.23 m horizontally and 4.79 m vertically at a reference station, from a fixed survey-grade receiver under open sky, which is not a quadcopter in a turn.
The signature is a shift of a few metres that does not resolve as you add images, with per-image scatter on top of it. The block is internally consistent and the whole thing floats. If the offset is this size and shape, nothing about your coordinate system is wrong and no reprojection will help.
So check what the aircraft recorded. DJI writes an RtkFlag field into the XMP of each image, and anything other than a fixed solution across the flight means you never had the 1 cm + 1 ppm the airframe was sold on. Put a batch of your own images through the image metadata viewer on this site - the parsing happens in your browser and nothing is uploaded - and read the count rather than one frame. The guide on reading RTK status sets out what each value means and how to tell a flag that lies.
One to two metres, uniform, in North America: it is the datum
If the offset is the same vector across the whole site, around 1 to 2 m, and the work is in the United States or Canada, suspect WGS 84 being compared against NAD83. The two agreed within measurement error in 1986. NAD83 is fixed to the North American plate and absorbs its motion of roughly 1 to 2 cm a year while WGS 84 stays tied to the global frame, so the same ground point now has coordinates 1 to 2 metres apart across the lower 48.
Your aircraft writes WGS 84, because that is what GNSS produces. The client's control, the State Plane zone and most agency data are NAD83. Nothing in a coordinate file announces which of the two it holds, and a file labelled only 'WGS84' has not told anyone anything, so this one ships. The WGS 84 vs NAD83 guide covers the mechanism and which realisation to ask for.
What this site cannot do is the honest part. The good NAD83 transformations are grid-based, and a grid is a large binary file the converter here cannot load - it runs proj4 in your browser and will give a parametric answer or none. For survey work, use PROJ with the grids installed, or the National Geodetic Survey's own tooling.
Tens of metres, and only vertical: not a position error at all
If the plan view is perfect and the elevations are wrong by a large, consistent amount, nothing is in the wrong place horizontally. You are comparing ellipsoidal height against orthometric height, and the difference is the geoid undulation, which runs from about 105 m below the ellipsoid to about 85 m above it worldwide and is negative across all of India.
In the client's words: the contours sit a uniform amount below the benchmark, or a product sold on 2 cm turns out to be tens of metres under the control. The relative geometry is excellent and every absolute elevation is wrong by the same number, which is why it survives review. A horizontal error gets caught the moment somebody opens the data over a basemap; a vertical one does not.
There is a quieter version of it, where the altitude in the file is height above the take-off point rather than height above anything on the ground. The offset is then the size of the difference between two launch points, and it moves between flights rather than staying put.
This site cannot convert heights. proj4 carries no vertical axis through a transformation, which is why EPSG:4979 is handled here as its two-dimensional equivalent, and a proper geoid correction needs a gridded model. What it can do is show which altitude fields your images carry. The ellipsoidal height vs MSL guide covers the geoid, EGM96 and EGM2008 in full.
Hundreds of kilometres, or two halves that disagree: the CRS itself
If the data lands in the Gulf of Guinea, or in the sea off Somalia, or a site near Delhi appears at 77 degrees north and 28 degrees east, that is axis order and not a datum. The EPSG registry defines EPSG:4326 as latitude first; GeoJSON mandates longitude first in RFC 7946, and KML writes longitude first. Somewhere in the chain the pair was read in the other order.
A wrong zone moves things by a predictable distance. Label UTM zone 43N data as 44N and it shifts by the ground length of six degrees of longitude at that latitude: 111.32 km per degree at the equator, times six, times the cosine of the latitude, so roughly 590 km at 28 degrees and about 470 km at 45. The numbers look plausible at both ends, because every UTM zone places 500,000 m on its own central meridian.
Web Mercator metres mistaken for a projected survey grid give another signature. EPSG:3857 runs to plus or minus 20037508.34 m on both axes, so a northing of 3326595 for a site in Delhi is Pseudo-Mercator and not a UTM northing. Where it is mistaken for true ellipsoidal Mercator, the northing departs by about 21 km at 30 degrees of latitude, 30 km at 45 and 37 km at 60, as the EPSG:4326 vs EPSG:3857 guide sets out.
The two-halves case is a zone boundary. Eastings restart in every zone, so a corridor that crosses one folds over itself: half the site lines up and the other half is hundreds of kilometres away, or distances across the join are wrong while everything local is fine. London sits about 9 km from the zone 30 and 31 boundary, Hyderabad 52 km from its own and Delhi 77 km, so this is not an edge case. The UTM zone by city guide carries the distance to the edge for 75 cities.
The survey is fine and the basemap is wrong
A satellite basemap is a product with its own positional error, and that error is often metres. Esri's World Imagery is built largely on Maxar's Vivid mosaics; Esri wrote in June 2019 that the third generation of Vivid had moved to 4 m CE90 from 10 m, with the continental United States improving from 10 m to under 5 m CE90. It is served at 1 m resolution globally and 50 cm over the continental United States and western Europe, and resolution is not accuracy - a sharp pixel can sit in the wrong place.
Google publishes no positional accuracy figure for Maps or Earth imagery, so what exists is independent assessment. A 2008 study of 436 control points against Landsat GeoCover measured 39.7 m RMSE globally, 24.1 m in developed countries and 44.4 m in developing ones, with individual errors from 0.4 m to 171.6 m. A 2022 Lagos assessment measured 29.4 m for 2000 imagery, 28.4 m for 2008 and about 10.6 m for 2012 and 2018. A 2017 Montreal study found 0.1 m in the south of its area and 2.7 m in the north, and 67 cm RMSE after a fitted transformation.
Read together: current high-resolution imagery over a well-mapped city is often good to a metre or two, older archive imagery can be tens of metres out, and either way the error is the same order as the offset you are chasing. Esri at least publishes the metadata - add World Imagery from the search menu rather than the default basemap entry and you get a citation layer with provider, date, resolution and accuracy for the footprint under the cursor. Google exposes nothing equivalent.
So bring in a third reference before blaming anyone. If a surveyed point, a benchmark or a second provider's imagery agree with your survey and disagree with the basemap, the basemap is the outlier. Do not drag a surveyed deliverable onto a basemap to make the screenshot look right: that throws away the only version of the data whose accuracy you can state.
What to check in your own files, and what this site cannot do
Start with the metadata, because it costs nothing. Load the flight into the image metadata viewer here, read the RTK status, GPS positions and altitude fields, then export the camera positions as CSV, KML or GeoJSON and put them on a map. If those positions already sit where the orthomosaic sits, the shift arrived with the flight. If they sit in the right place and the product does not, the problem is downstream, in the output CRS or the control.
Then test one known point. Take a coordinate you trust - a GCP, a benchmark, a surveyed corner - and run it through the coordinate converter between the system you believe you are in and the one the client reports in. If the point moves by about the size and bearing of your offset, you have named the cause without touching the dataset. Nothing is uploaded.
The limits are worth stating plainly. This site cannot apply grid-based datum shifts, cannot carry a vertical axis through a transformation, cannot reproject a raster and cannot re-run your photogrammetry. It tells you what your files claim, and what one coordinate does between two systems. For the rest you need PROJ with the relevant grids installed, or your national geodetic agency's tooling.
And there is a limit to the exercise. Aligning to a basemap buys agreement, not accuracy. A survey checked against a 5 m CE90 mosaic has been checked to 5 m, however neat the overlay looks. If the deliverable is sold on centimetres, check it against control of that order: a benchmark, a point from a reference station, or a GCP held out of processing.
Questions people ask
Why is my orthomosaic offset from Google satellite imagery?
Most often because the survey was flown on standalone GNSS without RTK or ground control, which places it a few metres out. But the basemap has its own error: Google publishes no accuracy figure, and independent assessments of its archive range from about 0.1 m in well-controlled urban areas to tens of metres in older or less developed coverage. Measure the offset at several points first - if it is one uniform vector affecting ground you never flew, suspect the basemap rather than the flight.
How far out is a drone map flown without RTK or ground control?
Metres, varying image to image, with the whole block floating as a unit. Manufacturer hovering-accuracy figures - 0.3 m horizontally on the vision system, 1.5 m horizontally on GNSS alone - describe how steadily the aircraft holds position, not where that position is on the earth. Expect a few metres absolutely, and expect it not to improve by adding more images, because the error is in the positions the aircraft wrote rather than in the geometry of the reconstruction.
Is satellite basemap imagery accurate enough to check a survey against?
Only for errors larger than the basemap's own. Esri has quoted Maxar Vivid at 4 to 5 m CE90, with the continental United States under 5 m, so a check against World Imagery is a check at roughly that level. It will catch a swapped axis order or a wrong UTM zone immediately, and it will tell you nothing useful about a 1 to 2 m datum offset. For that you need surveyed control.
My data is uniformly 1 to 2 metres out in the United States. What is it?
Almost certainly WGS 84 against NAD83. The two datums were coincident in 1986, but NAD83 moves with the North American plate at roughly 1 to 2 cm a year while WGS 84 does not, so they are now 1 to 2 m apart across the lower 48. Your aircraft writes WGS 84; State Plane zones and agency control are NAD83. A file labelled only 'WGS84' does not record which of them it holds, which is why this one reaches the client.
Why did my drone map end up in the ocean off Africa?
Latitude and longitude have been read in the wrong order somewhere. EPSG defines EPSG:4326 with latitude first, while GeoJSON and KML both write longitude first, so a tool reading one convention as the other sends points toward the equator and the prime meridian - the Gulf of Guinea. A site near Delhi appearing at 77 degrees north, 28 degrees east is the same fault. It is not a datum problem, and no datum transformation will repair it.
One half of my site lines up and the other half does not. Why?
You have probably crossed a UTM zone boundary. Eastings restart in each zone, with 500,000 m placed on every central meridian, so the two halves of a corridor can carry similar-looking coordinates while being hundreds of kilometres apart. Mislabelling one zone as its neighbour shifts data by six degrees of longitude on the ground - roughly 590 km at 28 degrees of latitude and 470 km at 45. Pick one zone and extend it, or split the deliverable at the boundary and say so.
Should I shift my orthomosaic to match the basemap?
Not unless you have established that the basemap is the better reference, which usually means surveyed control agrees with it and not with you. Moving a georeferenced deliverable to match an image product of unstated accuracy replaces a known position with an unknown one, and the shift is rarely recorded anywhere afterwards. Fix the cause - the datum, the code, the control - rather than the appearance.