Your drone photos have no GPS

An error message about missing GPS is a statement about what one program could read, not about what is in the file. The clearest documented case is Autodesk ReCap, where users with a Mapir Survey3 camera and with a Mavic 3 Enterprise both reported 'some photos do not have GPS data' on images whose coordinates were plainly visible in the file properties. In a related thread Autodesk staff explained the mechanism: a project created with the precise PPK/RTK option fails on images that are not RTK or PPK corrected, because nothing in the GPS fields says which kind they are. The fix was to recreate the project without the precise setting, and the images were never the problem.

The second way this happens is a reader that parses only one of the two places a position can live. A DJI image usually carries coordinates in the Exif GPS block and again in the XMP packet. A tool written against Exif alone reports nothing for a file whose position survived only in XMP, and a tool written for drones may do the reverse.

The third is narrower and catches people out. The Exif GPS directory splits a coordinate across two tags: GPSLatitude, tag 0x0002, holding three rationals for degrees, minutes and seconds, and GPSLatitudeRef, tag 0x0001, holding a single letter, N or S. Longitude works the same way with E or W. The number alone does not say which hemisphere it belongs to, so a reader handed the value without the ref has nothing it can safely plot.

So open one file in something that shows you everything it finds, before accepting any program's diagnosis. The metadata viewer on this site reads both the Exif GPS block and the DJI XMP fields, in your browser, with nothing uploaded.

A great many writers, when they have no fix to record, write zeros rather than leaving the tag out. The file then claims to have GPS, and the position is fiction: latitude 0, longitude 0 is a spot in the Gulf of Guinea off West Africa with nothing on it, which is why the GIS world calls it Null Island. On a map your flight shows as a tidy strip of points plus a line of them in the ocean.

The DJI version of this is specific and reported repeatedly. Users on the Dronelink forum found that photos triggered manually during a mission came back with all-zero coordinates while automated waypoint shots on the same flight recorded correct data, and Dronelink staff attributed the behaviour to DJI firmware rather than to the app. A thread on DJI's own developer forum describes images and SRT video logs reporting 0;0;0 throughout. Treat these as user reports rather than a specification, but recognise the symptom when you see it.

This is not the same failure as a swapped axis order, though the two look alike on a map. Zeros stack every affected point on one spot in the sea; swapped latitude and longitude put a site near Delhi at 77 degrees north, 28 degrees east, in the Arctic. Different diagnosis, different fix, and the note on EPSG:4326 versus EPSG:3857 covers it.

The viewer here treats an exact 0,0 as no fix rather than as a position, which is why a file can appear as missing GPS in it and as having coordinates somewhere else. That is deliberate. A placeholder plotted as a location is worse than an honest gap, because it drags a photogrammetry solution towards it.

A receiver that starts with no almanac or ephemeris in memory has to search blind for satellites, which is a cold start. Published figures vary with the hardware and the sky view, but the shape is consistent: a hot start can be a matter of seconds, a warm start can be as short as about 30 seconds, a cold start commonly runs two to four minutes, and the full almanac is broadcast over a 12.5 minute cycle, which is the bound rather than the typical wait.

The signature of this cause is a contiguous run. Sort the images by DateTimeOriginal and the files without coordinates sit together at the beginning, with everything after a certain frame correct. A handful of test shots fired on the pad while the aircraft was still acquiring satellites produces exactly this and nothing else.

A gap in the middle means something else: the sky was obstructed during part of the flight. Indoors, under a canopy, in a narrow street, close to a cliff face or inside a steel structure, the fix drops and returns, and the affected images sit in a block with good ones on either side. Multipath near large reflective surfaces does not usually remove the fix so much as degrade it, which shows up as positions that are present and wrong rather than absent.

Scattered single files with no neighbours are a third pattern, and they rarely come from the receiver at all. That distribution points at something the files went through after the flight.

Not every camera that goes up has a GPS in it, and it is not a fixed property of a brand. The GoPro Hero 9, 10 and 11 carry GPS, the Hero 12 Black shipped without it, and the Hero 13 Black brought it back. Mounting any camera on an aircraft does not hand that camera the aircraft's position - the payload has to be wired or synchronised for it.

The route for these files is matching by time against the flight log. ExifTool reads a GPX track and writes positions into the images: exiftool -geotag track.gpx dir, with -geosync to take out a camera clock that was running ahead of or behind GPS time. Where the images have no usable time for the match, the common workaround is to point it at the file time instead, with -P so the original timestamps are preserved.

Be honest about what that buys you. A time match is only as good as the clock offset and the log rate. At 10 metres per second, an ordinary mapping speed, a one-second clock error is ten metres of position error - comfortably worse than the GSD of the imagery it is being attached to. It is a way to get images onto a map, and a poor substitute for a camera that recorded its own position.

This site does not write that data. The tools here read metadata; they do not modify your files. ExifTool, or the processing software's own log import, is where that job belongs.

Editors drop metadata on the way out. Lightroom Classic's export dialog carries both a Metadata dropdown and a 'Remove Location Info' checkbox, and an export set to anything narrower than all metadata can arrive without coordinates. Users also report the opposite confusion: GPS disappearing from DJI raw files in the Lightroom catalogue while remaining in the files themselves, with 'Read Metadata from File' bringing the display back. Check the file rather than the application's view of it.

Format conversion loses things quietly. One user converting Phantom 4 Pro raw files found the GPS present in the JPEGs and gone from the TIFFs, which is the kind of loss that shows up two steps later when the processing software refuses the set. Any conversion is a candidate, and so is any tool that rewrites an image without being asked to carry the metadata across.

Messaging and sharing are the most common cause of all, and the easiest to rule out. WhatsApp strips location from photos sent in the normal way; the same photo sent as a document passes through as the original file. Several other platforms do the same thing by policy. A copy that reached you through a chat app is therefore no evidence about the copy on the card.

So before diagnosing anything, go back to the card and test an original. If the original has the tags, the problem is in your pipeline rather than in the flight, and the fix is a setting rather than a reconstruction.

The Exif format stores a coordinate as degrees, minutes and seconds, each one a rational: a numerator and a denominator, both 32-bit integers, with the writer choosing the denominators. The specification's own examples show two shapes - dd/1, mm/1, ss/1 for whole seconds, and dd/1, mmmm/100, 0/1 for minutes to two decimal places with no seconds at all. The resolution follows from the shape rather than from the hardware. One arc-minute of latitude is about 1855 metres and one arc-second about 31 metres, so whole seconds resolve to roughly 31 metres on the ground and hundredths of a minute to roughly 19 metres. Both are coarse next to the ground resolution of survey imagery, and neither is a limit of the receiver - it is a limit of how the numbers were written down.

That is the background to a workaround that has circulated since a 2018 MavicPilots thread about the Mavic Air. The poster found the Exif GPS values imprecise relative to the XMP:Latitude and XMP:Longitude tags in the same files, and copied the XMP values over the Exif ones with ExifTool: exiftool '-EXIF:GPSLatitude<XMP:Latitude' '-EXIF:GPSLongitude<XMP:Longitude'. Other posters in the thread hit quoting problems and a 'Bad MakerNoteDJI directory' warning, and the coordinates changed anyway.

That thread is a user observation repeated by other users, with no DJI documentation behind it. Take its own advice: back up the originals, run it on a copy, and check the result against a position you know before trusting a batch of several hundred.

The consequence for this page is the useful part. An image reported as having no GPS may be an image whose position survives in only one of the two blocks. Read both before concluding anything, which is what the viewer here does.

Check one file first. Open a single image and look at what is in it: Exif GPS, the ref tags, the XMP block, the timestamp. One file settles whether you have a missing-data problem or a reader problem.

Then run the batch. Drop the whole folder into the metadata viewer and let it flag which files have no usable fix. It reads Exif and DJI XMP in your browser, nothing is uploaded, and it exports the positions it did find as CSV, KML or GeoJSON - the CSV being the format Pix4D, Metashape and WebODM take as a geotag import, so the survivors can go straight into processing while you deal with the rest.

Then look at the pattern. A block at the start is acquisition. A block in the middle is obstruction. Scattered singles are something that happened to the files afterwards. Everything stacked on one point is a 0,0 placeholder. Putting the exported positions on a map, in the Map Lab here or in any GIS, turns that from a guess into something you can see, and it is the step a search result cannot do for you.

What this site cannot do is fix the files. Every tool here reads; none writes metadata back. The repairs are ExifTool for copying or injecting tags and the flight log for images that never had a position. And if your images have coordinates but the heights look wrong, that is a separate problem with a separate cause - the guide on ellipsoidal height versus height above sea level covers it, including which of the three DJI altitude fields you are actually looking at.