You import a Google Maps export into QGIS and the map zooms to an empty patch of ocean. Or the spreadsheet has place names and links but no latitude or longitude anywhere. Sometimes every point is wrong; sometimes one restaurant has quietly moved to [0,0].
Those symptoms look related, but they have different causes. Fixing them starts with identifying which one you actually have.
| Symptom | Likely cause | Best next step |
|---|---|---|
| CSV has no coordinate columns | Normal Google Takeout Saved export | Re-export the live list or use a coordinate-bearing source |
| One or more points are [0,0] | Placeholder or bad source geometry | Verify and replace those places; do not import them blindly |
| Most points are in the wrong part of the world | Longitude and latitude were swapped | Restore GeoJSON order: longitude first, latitude second |
| Feature exists but has null/empty geometry | Source place had no usable coordinate | Re-scan or verify the place manually |
| A few points are near the right city but at the wrong address | Ambiguous or stale place match | Check the original Maps listing and full address |
Do not begin by changing every zero or swapping every column. Preserve the source, diagnose the pattern, and repair only what the evidence supports.
Case 1: The Takeout CSV has no coordinates
Google Takeout has two similarly named exports. Saved creates list-by-list CSV files, while Maps (your places) can produce a GeoJSON-formatted Saved Places.json file. The CSV is useful for list names and Google Maps links, but it generally has no dedicated latitude and longitude columns.
That is an export limitation, not corruption. Adding empty lat and lng headers does not solve it, and feeding the address column through an arbitrary free geocoder can introduce confident-looking mistakes.
Your options are:
- For Starred places, download Maps (your places) → Saved Places.json and use the Takeout Import page.
- For a custom, default, shared, or followed list, open it in Google Maps and export it with the Chrome extension.
- If you only have the CSV and cannot reopen the source, geocode carefully from the full address and keep the original Maps URL as an audit column.
The complete distinction is covered in Saved Places.json vs Saved CSV. Read that before trying to “repair” a file that is behaving exactly as Google designed it.
Case 2: A point has coordinates [0,0]
GeoJSON coordinates are written as [longitude, latitude]. The value [0,0] is therefore a real coordinate in the Gulf of Guinea, off the west coast of Africa. A structural validator cannot automatically call it invalid because a legitimate marine dataset could intentionally contain that point.
For a list of cafés, homes, shops, or trailheads, [0,0] is almost certainly not intentional. Treat it as missing data.
Search the JSON for the exact sequence and inspect the feature's properties. Keep the name, address, note, and Google Maps URL, but do not keep the placeholder geometry. Then recover the location from the live Maps listing or re-export the list. If the listing no longer exists, verify the address manually rather than selecting the first similar search result.
Do not delete the row immediately. A place without geometry can still contain notes or identifiers that help you recover it. Quarantine bad features in a separate sheet or file until the location is confirmed.
Case 3: Longitude and latitude are reversed
People usually say “latitude and longitude.” GeoJSON does the opposite. The GeoJSON specification defines positions with longitude first and latitude second.
Berlin is approximately:
- latitude: 52.52;
- longitude: 13.405;
- GeoJSON position: [13.405, 52.52].
Write [52.52, 13.405] and the point lands thousands of kilometers away. This often happens after somebody opens coordinates in a spreadsheet, labels the columns by habit, and rebuilds the GeoJSON.
A global swap has a recognizable pattern: most or all points move, while their relative grouping may still look plausible. If only two rows are wrong, coordinate order is probably not the root cause.
Also use range checks as clues. Latitude must be between -90 and 90; longitude can range from -180 to 180. A “latitude” of 121 is definitely a longitude. Values such as 13 and 52 are valid in either column, so a range check alone cannot prove the order—compare a known place.
Case 4: Geometry is empty or missing
A GeoJSON feature may still have a name and properties while its geometry is null, empty, or malformed. Mapping software cannot draw it.
Run the file through the GeoJSON validator. It checks JSON syntax, the FeatureCollection structure, geometry types, and coordinate arrays in your browser. It also helps separate a broken file from a valid file that contains one semantically wrong point.
Remember the validator's limit: valid structure does not guarantee a correct place. [0,0] is structurally valid. A coordinate on the wrong street is structurally valid. Validation is the first filter, not the final verdict.
When ExportMyMap creates coordinate-dependent formats such as KML, GPX, or GeoJSON, an entry with no usable coordinates may be skipped because no honest point can be drawn. Compare the exported feature count with the selected-place count. A small shortfall usually points to a handful of damaged or incomplete source records.
Case 5: The point is plausible, but it is the wrong place
This is harder than [0,0] because the map does not look obviously broken. A short address such as “Main Street, Springfield” can match several cities. A business may have moved, closed, or been replaced by another listing. A Google Maps URL copied from search results may describe the viewport rather than a single canonical place.
Use at least two identifiers when checking the row:
- full name and city;
- street address and postal code;
- original Google Maps place link;
- phone number or website, if available.
Open the link and confirm the pin, not just the search text. For business-critical data, manually verify every corrected match instead of approving the nearest result in bulk.
A safe repair workflow
1. Preserve the original
Make an untouched copy and give it an obvious name such as saved-places-original.json. Never make the only copy your working file.
2. Count the damage
Record the total feature count, number of null geometries, number of [0,0] points, and rough geographic bounds. If 497 of 500 points are right, you need a three-row repair—not a new conversion pipeline.
3. Re-export before geocoding
When the Google Maps list still exists, a fresh GeoJSON export is usually safer than reconstructing coordinates from labels. The live listing can provide a stable place match that a plain address no longer can.
4. Repair in a separate copy
Keep an audit column or note recording where each replacement coordinate came from. If you are working in a spreadsheet, preserve coordinate precision and export UTF-8.
5. Validate and view a sample
Run structural validation, inspect the bounding box, and open known points from the north, south, east, and west edges of the dataset. Then test a few ordinary points in the middle. A valid bounding box can still hide one wildly misplaced feature.
For a full GIS check, follow the QGIS workflow and use Zoom to Layer. A lone point near Africa with the rest of the dataset in Europe is easy to spot at that scale.
Do not hide missing data with made-up precision
Coordinates with six decimal places look authoritative. They can still describe the wrong entrance, the city center, or an entirely different business with the same name.
If you cannot verify a place, leave its geometry missing and keep the row for review. A clearly incomplete dataset is safer than a complete-looking one that sends somebody to the wrong location.
Once the source is clean, export the format the destination actually needs: CSV for a spreadsheet, GPX for waypoints, or GeoJSON for GIS. The coordinate problem should be solved at the source, not copied into five new files.