A point can contain two perfectly valid numbers and still land on the wrong side of a map. In GeoJSON, the order of those numbers is part of the format, not a matter of personal preference.
The GeoJSON specification, section 3.1.1, places longitude first and latitude second. Coordinates use decimal degrees in the geographic reference system described by the specification. A spreadsheet headed “latitude, longitude” therefore cannot be copied into a GeoJSON position without checking the order.
A deliberately simple point
Consider this invented example: {"type":"Point","coordinates":[20,10]}. It describes longitude 20, latitude 10. Reversing the array to [10,20] describes a different location. Both pairs are numerically plausible, so a range check alone would miss the mistake.
For a first import, choose one record whose general location you can independently verify. Compare its column headings, the exported array and the rendered point. If that row is wrong, investigate the conversion before importing thousands more.
- Identify the source coordinate system and column meanings.
- Construct the array explicitly as longitude, then latitude.
- Check a known point on the map and inspect the exported text.
- Test a second point far away to avoid accepting a coincidental result.
Do not repair a coordinate-system problem by swapping columns
Numbers measured in metres in a projected coordinate system need an appropriate transformation, not merely a different order. Likewise, changing a minus sign to make a point look closer is not a valid correction. Preserve the source values while diagnosing the problem and record the transformation used.
A useful export note names the original fields and their destination: “source lon → coordinates[0]; source lat → coordinates[1].” That small mapping is easier to review than a screenshot of a map that merely looks convincing.