Coordinates in CSV: Lat/Long Precision and CRS Confusion

Coordinates look deceptively simple in CSV files.

A dataset arrives with columns called latitude and longitude, or maybe lat and lon, or maybe just x and y. The values look numeric. A spreadsheet opens the file. A map loads something. So the data feels "good enough."

Then the real problems start:

• points appear in the wrong hemisphere
• assets cluster off the coast of Africa
• coordinates import but land in the wrong city
• a valid-looking file fails in a GIS pipeline
• projected coordinates get treated like WGS 84 latitude/longitude
• rows are rounded enough to break matching or deduplication
• a downstream team says the CRS is wrong, but nobody can tell whether the coordinates were transformed or just mislabeled

This is why coordinates in CSV files are harder than they look. A CSV can carry coordinate columns, but the CSV format itself does not tell you what those numbers really mean.

This guide explains the most common sources of confusion around latitude/longitude precision, CRS metadata, axis order, and projected coordinate handling so you can validate geospatial CSVs more safely.

If you want the practical tools first, start with CSV to JSON, the universal converter, JSON to CSV, CSV Validator, CSV Format Checker, or CSV Row Checker.

Why coordinates in CSV are harder than they look

A CSV file is just a tabular text container.

It can hold values like:

• -33.9249
• 18.4241

But those values are only useful if you also know things like:

• are these latitude and longitude or longitude and latitude?
• which CRS are they in?
• are they geographic coordinates or projected easting/northing values?
• how much precision was preserved?
• were they transformed correctly from another CRS?
• were they rounded, truncated, or reformatted in a spreadsheet?

That means coordinate handling is not just a parsing problem. It is a contract problem.

Latitude/longitude columns are not self-describing

A pair of columns named lat and long might seem clear. Sometimes they are. Often they are not.

Consider a few possibilities:

• the file uses decimal degrees in WGS 84
• the file says lat and long but actually stores lon, lat
• the values come from a projected CRS and were renamed by someone upstream
• the coordinates were transformed to WGS 84 visually, but only the labels changed
• precision was cut from 8 decimal places to 4 during export
• the decimal separator was altered by locale handling

The file may still "look correct" because the numbers are numeric and plausible. That is what makes this category of data bug so persistent.

The axis-order problem never really goes away

This is one of the most common coordinate mistakes in real workflows.

Many developers and analysts think in:

• latitude, longitude

Many web mapping and GeoJSON workflows use:

• longitude, latitude

The confusion gets worse because EPSG:4326 itself is officially defined with latitude and longitude axes. The EPSG WKT for 4326 shows axis 1 as geodetic latitude and axis 2 as geodetic longitude. PROJ’s FAQ explains that modern PROJ respects official authority-defined axis ordering, which is part of why axis-order confusion keeps surfacing. citeturn688238search5turn688238search2

At the same time, RFC 7946, the GeoJSON specification, explicitly says that point coordinates are in x, y order, which for geographic coordinates means longitude, latitude. citeturn688238search0

That means two authoritative systems can lead users toward different expectations:

• EPSG:4326 definition: latitude, longitude
• GeoJSON coordinate arrays: longitude, latitude

If your CSV workflow moves between GIS, databases, map SDKs, and browser mapping tools, this mismatch is one of the first things to validate.

Why lat and lon column names do not solve the problem

Teams often assume that column labels remove ambiguity.

Sometimes they help. But they are not enough.

Problems still happen because:

• columns are mislabeled
• software ignores labels and reads positionally
• x/y columns get interpreted differently across systems
• one team treats the first coordinate as latitude because that is how humans talk
• another team treats the first coordinate as x, meaning longitude
• projected coordinates get renamed into geographic-looking labels

A file that says latitude,longitude can still be wrong if the values are swapped or belong to a projected CRS.

Precision: what decimal places really mean

Precision gets discussed casually, but it matters a lot in coordinate data.

If you round coordinates too aggressively, you may still get a point that "looks close enough" on a small map while losing enough detail to break:

• geofencing
• address matching
• route snapping
• asset deduplication
• parcel-level mapping
• repeated joins between datasets

The key point is that decimal precision in degrees corresponds to different real-world distances, and longitude precision also varies with latitude. That means there is no single universal "safe" number of decimal places for every geospatial task.

A few practical rules help:

• fewer decimal places are often fine for broad regional mapping
• more decimal places matter for street-level or asset-level data
• precision should match the use case, not just the export defaults
• spreadsheet rounding is often more dangerous than people expect

The worst mistake is not necessarily "too little precision." It is unknown precision combined with false confidence.

Precision is not just about decimals

Coordinate precision can be damaged in several ways:

• rounding
• truncation
• conversion to float and back
• spreadsheet reformatting
• locale-induced decimal changes
• string-to-number coercion
• exporting projected meters with fewer decimals and then converting later

So when people say "we kept six decimals," that may not tell the whole story. You also need to know whether the original numeric meaning was preserved faithfully through each transformation step.

CRS confusion is often worse than precision loss

If axis order is the most common coordinate bug, CRS confusion is often the most expensive one.

A CRS tells you what coordinate system the numbers belong to. Without that, two columns of numbers are just numbers.

Geographic CRS

Geographic coordinate systems typically describe locations using angular values such as latitude and longitude in degrees.

Projected CRS

Projected coordinate systems use linear units such as meters or feet and are often represented as easting and northing.

The problem is that people frequently mix these concepts in CSV files.

Examples:

• a projected easting/northing pair gets renamed as latitude/longitude
• WGS 84 labels get attached to coordinates that are still in a local projected CRS
• a file says EPSG:4326 but the values look like meters
• a source system exports Web Mercator-like values and someone assumes decimal degrees

That is how points that should land in a known city end up in the ocean or off the visible map entirely.

Why EPSG:4326 causes so much confusion

EPSG:4326 is probably the most commonly cited CRS in these workflows, but it is also a major source of misunderstanding.

People often use "4326" as shorthand for:

• GPS-style coordinates
• WGS 84
• longitude/latitude
• any generic lat/long pair

But these are not all the same thing operationally.

The EPSG definition for 4326 is an ellipsoidal 2D coordinate system with axes latitude, longitude. Meanwhile, GeoJSON and many web mapping systems commonly use longitude, latitude ordering in coordinates. PROJ’s documentation explicitly notes both the official axis-order behavior and the adjustments it may insert when converting between coordinate systems. citeturn688238search1turn688238search2turn688238search6

That means the phrase "it is in 4326" is not enough on its own. You still need to know:

• how the producer ordered the columns
• how the consumer expects them
• whether the pipeline respects EPSG axis order strictly
• whether the intermediate format uses x/y conventions instead

ST_SetSRID versus ST_Transform: a very expensive misunderstanding

This is one of the most important conceptual distinctions in geospatial pipelines.

PostGIS documents it clearly:

• ST_SetSRID sets the SRID metadata and does not transform coordinates
• ST_Transform actually changes coordinates from one spatial reference system to another citeturn688238search7turn688238search10

This mistake causes endless damage in CSV-related workflows.

A team receives projected coordinates, assumes they should be WGS 84, and "fixes" the problem by assigning EPSG:4326 metadata. The numbers do not change, so the geometry is now mislabeled rather than corrected.

That is worse than having unknown CRS data, because now the file carries a false sense of correctness.

If you remember one geospatial rule from this article, remember this one:

Relabeling a CRS is not the same thing as transforming coordinates.

Range checks: the fastest sanity test

One of the simplest ways to catch coordinate problems in CSV files is to apply basic range checks.

For geographic coordinates in decimal degrees:

• latitude should usually be between -90 and 90
• longitude should usually be between -180 and 180

If values blow past those limits, you probably have one of these situations:

• projected coordinates
• bad parsing
• swapped fields
• wrong decimal formatting
• unit confusion

This check does not prove the data is correct. But it quickly tells you whether a supposedly geographic lat/long file is obviously not what it claims to be.

Projected coordinates are not wrong, just different

A lot of coordinate confusion comes from treating projected values as "bad coordinates."

They are not bad. They just are not latitude and longitude.

Projected systems are often the right choice for:

• engineering work
• local government data
• asset surveys
• cadastral datasets
• routing or distance analysis
• region-specific mapping accuracy

The problem only begins when projected coordinates are transported without clear metadata or are stuffed into generic lat/lon columns because someone wanted them to fit a simpler template.

Column naming patterns that reduce confusion

The safest coordinate CSVs are explicit.

Better patterns include:

• longitude, latitude
• lon, lat
• easting, northing
• x, y only when the CRS is documented elsewhere very clearly
• a separate crs or epsg field when appropriate
• documentation that states axis order and units explicitly

Worse patterns include:

• generic coord1, coord2
• x, y with no CRS metadata
• lat, long on projected meter values
• "GPS" as the only metadata
• mixing multiple CRSs in one file without clear flags

Spreadsheet behavior makes this worse

Coordinates often look fine in spreadsheets even when they are not.

Spreadsheets can introduce or hide problems like:

• rounding
• dropped trailing decimals
• scientific notation on large projected numbers
• locale-driven decimal interpretation
• string formatting that conceals precision loss
• copy-paste reordering

This is another reason geospatial CSV validation should not stop at "it opened fine in Excel."

A practical validation workflow for coordinate CSVs

1. Validate the CSV structure first

Before you even think about mapping, confirm:

• consistent row shape
• correct delimiter
• correct quoting
• encoding
• header presence

If the rows are broken, coordinate interpretation is unreliable from the start.

2. Identify candidate coordinate columns

Look for fields such as:

• latitude / longitude
• lat / lon
• x / y
• easting / northing
• geometry-like strings
• CRS or EPSG metadata columns

Do not assume the labels are truthful yet.

3. Apply simple range checks

If the file claims decimal degrees, check whether values fit plausible geographic ranges.

This immediately catches many projected-vs-geographic mistakes.

4. Check axis order expectations

Ask:

• does the producer mean latitude then longitude?
• does the consumer expect longitude then latitude?
• is this data headed into GeoJSON or another x/y-oriented format?
• is the toolchain strict about EPSG axis order?

If you do not answer this explicitly, sooner or later one system will answer it for you in the wrong way.

5. Confirm the CRS separately from the column names

Do not infer CRS only from:

• column labels
• values that "look like GPS"
• map previews alone

Look for explicit metadata, documentation, or upstream system guarantees.

6. Check precision against the use case

Do not only ask "how many decimals are there?"

Ask:

• was precision lost during export?
• is the remaining precision enough for the business use case?
• were coordinates rounded by a spreadsheet or reporting layer?
• are longitude values too coarsely rounded for dense urban or parcel-level use?

7. Distinguish relabeling from transformation

If the CRS changed somewhere in the pipeline, verify whether the numeric values were actually transformed.

This is where database functions and GIS tooling need careful review.

Common mistakes to avoid

Assuming EPSG:4326 means everyone will agree on axis order

They will not.

Treating lat and lon headers as proof of meaning

They are only labels.

Assigning a CRS when you really needed a transformation

This is the classic ST_SetSRID versus ST_Transform failure.

Ignoring projected systems because the app expects GPS-style values

Projected coordinates are often valid and useful. The real problem is undocumented mismatch.

Letting spreadsheets round or rewrite coordinates before validation

This quietly damages data quality.

FAQ

Why do latitude and longitude columns still break pipelines?

Because coordinates need more context than ordinary numeric columns. You need axis order, CRS, precision expectations, and confidence that the values were actually transformed correctly if a CRS change occurred.

Does EPSG:4326 always mean longitude then latitude?

No. EPSG:4326 is officially defined with latitude then longitude axes, while formats like GeoJSON use longitude, latitude ordering in practice. That mismatch causes constant confusion. citeturn688238search5turn688238search0turn688238search2

How can I tell if a file has projected rather than geographic coordinates?

Simple range checks help. Values outside normal latitude/longitude bounds often indicate projected coordinates or another interpretation problem.

What is the difference between setting a CRS and transforming coordinates?

Setting a CRS labels the coordinates. Transforming coordinates changes the numeric values from one spatial reference system to another. PostGIS distinguishes these operations explicitly. citeturn688238search7turn688238search10

Is more coordinate precision always better?

Not always. It should match the real use case, but unintentional precision loss is a common and dangerous problem.

Related tools and next steps

If you are validating geospatial CSV data before import or mapping, these are the best next steps:

• CSV to JSON
• universal converter
• JSON to CSV
• CSV Validator
• CSV Format Checker
• CSV Row Checker
• CSV tools hub

Final takeaway

Coordinates in CSV files fail for the same reason many data pipelines fail: the file carries less meaning than people assume.

A pair of numeric columns is not enough. You need to know:

• what the axes mean
• what CRS the numbers belong to
• whether the values were transformed or just relabeled
• how much precision survived export
• whether the consumer expects the same ordering as the producer

Once you treat coordinates as a real contract instead of just two decimals in a spreadsheet, most of the worst geospatial CSV bugs become much easier to catch.