CSV to GeoJSON Converter

Here is the bug. You export a list of stores from a database. The columns are latitude and longitude, in that order, because that is how everyone says it and how every address lookup returns it. You write ten lines of Python to wrap each row in a Feature, you paste the result into geojson.io, and every one of your London stores is sitting in the Gulf of Guinea, a few hundred kilometres off the coast of Ghana.

That spot is zero degrees north, zero degrees east. It is where a coordinate lands when the two numbers are small and swapped. GeoJSON positions are [longitude, latitude]. RFC 7946 is explicit about it, and it is the reverse of the order a person uses out loud, the order a spreadsheet column is usually in, and the order Google Maps shows in its own URL bar. Nothing errors. The file is structurally valid. It is just wrong, and it stays wrong until somebody looks at a map.

This converter reads your headings and applies the order for you. A column called latitude, lat or y is the latitude; a column called longitude, long, lon, lng or x is the longitude. Whichever way round they sit in your file, the output puts longitude first. When the detection cannot find them, or finds the wrong ones, the two dropdowns list the columns of the file in front of you and you pick in a second.

Real coordinate files are dirty in four specific ways, and all four produce a row that cannot become a Feature. A blank cell where a geocoder gave up. A value like N/A or north that is text rather than a number. A latitude of 910, which is a data-entry slip. And a whole file of numbers in the hundreds of thousands, which is a projected coordinate system that somebody labelled x and y.

Each of those rows is left out, because there is nothing honest to put in its place. What matters is what you are told. The warning gives the count against the total, then lists the first ten offenders by their line number in the original file along with the value that failed:

3 of 400 rows had no usable coordinate and were left out:
row 14: coordinate cell is blank;
row 88: "north", "-0.12" is not a number;
row 251: latitude 910 is outside -90 to 90.

A line number and the offending value is enough to open the CSV and fix it. A converter that quietly hands back 397 features from a 400-row file, with no note anywhere, is the reason people stop trusting these tools.

The out-of-range check is the one that saves the most time. If every row is reported as out of range, your file is almost certainly in a national grid, in metres, and it needs reprojecting before GeoJSON can hold it. Saying that immediately beats producing an empty map and letting you hunt for the reason.

GeoJSON has exactly one coordinate reference system and no way to declare another. RFC 7946 fixes it at WGS 84 decimal degrees, the system usually written as EPSG:4326, and it removed the crs member that the older 2008 specification allowed. If you find a file with a crs block in it, that file predates the RFC and most current readers ignore the block entirely.

Nothing here reprojects. A converter that guessed at your source projection and silently transformed your coordinates would be far more dangerous than one that refuses, because the output would look plausible and be wrong by a few hundred metres. If your data is in British National Grid, State Plane, UTM or a local municipal grid, run it through a reprojection first. QGIS, GDAL's ogr2ogr and the pyproj library all do this properly, and any of them will hand you back degrees you can bring straight here.

Coordinates are written to seven decimal places, which is roughly a centimetre. That is finer than any consumer GPS and much finer than anything that arrives in a spreadsheet. Beyond seven you are only writing floating point noise into the file, and 12.340000000000001 is not more precise than 12.34, only longer.