Why are my photos on a map in the sea off Africa?
You imported a Google Takeout into a photo library and a large pile of your pictures has landed at one point in the Atlantic, a few hundred miles south of Ghana. They are not spread around badly. They are all stacked on the same spot in open water.
Can you get it back?
There is nothing to recover, and that is the good news rather than the bad. Those photographs never had a location. They have not been given the wrong one by mistake, and no repair will find the right one, because none was ever recorded. What you can fix is them being drawn on the map at all.
What actually happened
Latitude 0, longitude 0 is a real point on the Earth. It is where the equator crosses the prime meridian, in the Gulf of Guinea, and there is nothing there but sea. Sailors call it Null Island as a joke, because so much broken software ends up pointing at it.
Google writes a location for every photograph in the JSON file beside it, including the ones it has no location for. When it has none, it does not leave the field out - it fills it in with zeroes. A tool that reads the number and plots it, without asking whether zero means the Gulf of Guinea or means nothing, sends every one of them to the same patch of ocean.
It is common because the zeroes are common. In one real export, around seven of every ten sidecar files carried a location of exactly zero.
It is worth knowing this before you go looking for a fix, because it saves a lot of effort. Counted across the same export: about a quarter of the photographs carried real coordinates, and every one of those had them inside the picture already. The number of photographs where the sidecar supplied a location the file did not have was zero. Not a handful - none. So for the three quarters with nothing, Google is not holding a location back and no tool can extract one. Those are screenshots, saved pictures, and anything that arrived through a messaging app, which strips location on the way. Dates are the opposite case, and it is easy to assume they behave the same way: for about half a library the sidecar is the only copy of the date in existence. Worth keeping the JSON files for that reason, just not for this one.
How to fix it
Two approaches, depending on whether the pictures are already in your library.
- Strip the zeroes before you import
- If the coordinates were written into the files by an earlier repair pass, exiftool will take them back out where they are zero and leave every real location alone: exiftool -r -if "$GPSLatitude eq '0' and $GPSLongitude eq '0'" -gps:all= -overwrite_original . Run it on a copy first. The -if test is what keeps it from wiping the quarter of your library that has genuine coordinates.
- If they are already imported
- Most photo libraries let you select everything at a single map location and clear it. In Immich, PhotoPrism and Apple Photos you can search or filter by place, select the whole Null Island cluster, and remove the location from the selection. That is usually faster than reimporting.
- Check before a large import
- Import a few hundred photographs first and look at the map. A wrong location that arrives on twenty thousand files is a great deal more tedious to undo than one you catch on two hundred.
How Muletto does it
Muletto treats a location of exactly zero as absent, because that is what it means. Those photographs get no coordinates written into them and do not appear on the map, while the ones with real coordinates do. Nothing has to be configured for it and there is nothing to undo afterwards.
Stopping it happening again
This is a property of the export rather than of anything you did, so there is no setting to change on Google's side. The one thing that helps is checking a sample on a map before committing a whole library to a new home.
Measured against one real Takeout of more than two thousand photographs. Around seven in ten sidecars carried a location of exactly zero, about a quarter of the photographs had genuine coordinates, and in no case did a sidecar supply a location that was not already in the file. That is one export rather than a survey, so treat the proportions as an indication.