Why Is My GIS Data Appearing in the Wrong Place?

When a GIS layer appears in the wrong place, the problem is often not the map itself. The coordinates may be interpreted using the wrong coordinate reference system, latitude and longitude may have been reversed, CRS metadata may be missing, or the underlying coordinates may simply be wrong.

The important first step is not to start reprojecting the data until something looks right. Instead, determine what the existing coordinate values are supposed to mean.

A useful diagnostic sequence is:

1. inspect the coordinates;

2. check the layer's declared CRS;

3. compare both with what you know about the data's origin;

4. determine whether the problem is interpretation, transformation, or the coordinates themselves;

5. only then change the data.

Different errors can produce similar-looking misplaced layers, but they require very different fixes.

Start with the symptom

The way a layer is misplaced often provides useful evidence.

• The entire layer appears on another continent: Possible cause — Wrong CRS assignment or reversed latitude/longitude

• A layer expected in one country appears close to `(0, 0)`: Possible cause — Projected coordinates interpreted as geographic coordinates, or incorrect CRS metadata

• The data is in roughly the right region but consistently shifted: Possible cause — Wrong datum or unsuitable coordinate transformation

• Longitude and latitude values look plausible but features appear in another plausible location: Possible cause — Coordinate order may be reversed

• One layer is far away while the others align: Possible cause — That layer may have missing or incorrect CRS metadata

• Layers align in the GIS but have very different raw coordinate values: Possible cause — On-the-fly reprojection may be working correctly

• Only some features are misplaced: Possible cause — The problem may be in the source coordinates, geocoding, joins, or individual records rather than the CRS

• A raster is shifted while vector layers align: Possible cause — Its georeferencing, transform, control points, or CRS metadata may be wrong

None of these is proof by itself. The point is to narrow the investigation before modifying the data.

First check the raw coordinate values

Before changing the CRS, inspect a few coordinates from the dataset.

Suppose a point that should be somewhere in central Africa contains values such as:

longitude: 11.5
latitude:   3.9

Those values are plausible as geographic coordinates in degrees.

Now suppose another dataset contains values such as:

x: 610000
y: 445000

Those look more like projected coordinates, although their values alone cannot identify which projected CRS produced them.

This distinction is useful because one of the most common failures occurs when projected coordinates are interpreted as longitude and latitude—or geographic coordinates are treated as projected coordinates.

A coordinate such as 610000 cannot be a valid longitude in degrees. If software interprets it using a geographic CRS, something about the data's CRS information or the way it was imported is almost certainly wrong.

Coordinate magnitude is therefore a useful clue, but not a substitute for metadata. Many projected coordinate systems have similar-looking numeric ranges, and small values can occur in both geographic and local Cartesian systems.

Check what CRS the layer says it uses

The next question is simple:

What CRS is currently assigned to the layer?

GIS software needs that information to understand what the coordinate values mean. QGIS, for example, relies on the CRS associated with a layer so that it can transform its raw coordinates into the project's display CRS. If the CRS is absent, the data may need to be assigned one manually; if the wrong CRS is assigned, QGIS warns that selecting the wrong one can place the layer in the wrong position on the Earth's surface.

The critical comparison is not merely:

What CRS does the software display?

but:

Does that CRS actually describe the coordinate values contained in the dataset?

If the file contains coordinates that were created in one CRS but is labelled as another, the software is faithfully interpreting incorrect metadata.

Changing the project CRS usually does not repair this. It simply changes the coordinate system into which correctly referenced layers are transformed for display.

Do not confuse assigning a CRS with reprojecting

This is where a common attempt at fixing misplaced data can make the situation worse.

Suppose the dataset's coordinate values genuinely belong to CRS A, but the layer has been incorrectly labelled as CRS B. If you reproject it from B to CRS C, the transformation begins with the false assumption that the original numbers were expressed in B.

The output will therefore also be wrong.

The correct sequence is:

determine the CRS the existing coordinates actually use → correct the CRS assignment → reproject only if another CRS is needed.

GDAL explicitly distinguishes assigning a spatial reference without changing coordinates from transforming those coordinates into a new CRS, and requires a source CRS to be available before reprojection can occur.

If that distinction is the source of the problem, Assigning a CRS vs Reprojecting Data explains the two operations in detail.

Check whether latitude and longitude have been reversed

A second common failure has nothing to do with projection.

Suppose an intended location is:

latitude:   4
longitude: 12

A system expecting longitude followed by latitude needs:

12, 4

If it instead receives:

4, 12

the numbers may remain completely valid. The software therefore has no reason to reject them—it simply maps a different place.

That makes latitude-longitude reversals particularly troublesome in regions where both coordinates fall between −90° and +90°. Numerical validation alone cannot tell which order was intended.

Axis conventions also vary. PROJ notes that authority-defined geographic CRSs commonly use latitude-longitude axis ordering, while traditional GIS and visualisation conventions frequently use longitude-latitude.

The broader rule is covered in Latitude vs Longitude: Which Comes First?. When investigating a specific dataset, check the format, schema or API that produced the coordinates rather than assuming that every geographic coordinate pair follows the same order.

What if the file has no CRS?

A missing CRS creates a different problem: the coordinates may be perfectly good, but the information needed to interpret them has been lost.

For example, a file might contain:

12.4, 5.8

Those values could plausibly be longitude and latitude, but that observation alone does not establish that they use WGS 84. Likewise, coordinates in hundreds of thousands might suggest a projected system without revealing which one.

Useful evidence includes:

• metadata from the original data provider;

• an accompanying .prj or other sidecar file;

• documentation for the source system;

• units and coordinate ranges;

• the geographic extent the data is supposed to cover;

• known locations that can be compared with the coordinates;

• information from the person or organisation that produced the dataset.

If the CRS is genuinely unknown, assigning whichever CRS makes the layer look approximately correct is not a reliable solution.

What Happens When a GIS File Has No CRS? treats that identification problem separately.

Layers in different CRSs can still align perfectly

Sometimes apparent inconsistency is not an error at all.

A layer stored as geographic longitude and latitude may sit correctly on top of a layer stored in a national projected CRS. Their raw coordinate values can look completely different while the layers line up perfectly on screen.

Modern GIS applications commonly perform on-the-fly coordinate transformations. QGIS, for example, transforms layers from their underlying CRSs into the project CRS for rendering, allowing datasets stored in different reference systems to appear together in the correct location.

This means that:

different coordinate values do not necessarily mean different locations, and matching display positions do not necessarily mean identical stored CRSs.

It also explains why changing the project CRS may alter the shape or appearance of the map without fixing a genuinely mislabelled layer.

If the distinction between geographic and projected representations is unfamiliar, EPSG:4326 vs EPSG:3857: WGS 84 and Web Mercator Explained provides a concrete example of two very different coordinate systems representing the same geographic locations.

A smaller shift may point to a transformation problem

Not every CRS-related error sends data across the world.

Sometimes a layer appears close to the expected position but is consistently displaced. In that case, the source and target CRS definitions, datum, reference frame, coordinate epoch, or selected coordinate operation deserve closer inspection.

Modern CRS transformations can involve more than applying a map-projection formula. PROJ constructs transformations between known source and target reference systems and may choose among different coordinate operations depending on their areas of use.

For routine mapping, GIS software often manages this automatically. But when accuracy requirements are high, an inappropriate transformation—or missing transformation resources—can matter.

The scale of the error is therefore useful evidence. A point thousands of kilometres away suggests a very different class of problem from a systematic shift of a few metres or tens of metres.

That more specialised case belongs in Why Do Layers Sometimes Shift After Reprojection? rather than being reduced to “the projection is wrong”.

Sometimes the CRS is not the problem

Projection problems are so familiar in GIS that it is easy to blame every misplaced feature on the CRS.

That can waste time.

If 9,999 points are correctly positioned and one point is in another country, changing the CRS for the whole layer is unlikely to be the answer. The outlier may contain a transcription error, a bad geocoding result, an incorrect sign, reversed coordinates in one record, or simply incorrect source information.

Likewise, if an imported table uses separate coordinate columns, check that the correct fields were selected for x and y. A perfectly valid latitude column used as x and longitude used as y produces the same basic symptom as reversed coordinates even though the file itself may be correct.

Other non-CRS causes include:

• missing minus signs;

• coordinates stored in the wrong fields;

• truncated or rounded values;

• erroneous geocoding;

• joining coordinates to the wrong record;

• stale or incorrect source data;

• local engineering coordinates mistaken for Earth-referenced coordinates.

The key diagnostic question is whether the error affects the whole spatial reference of the layer or only particular records.

Raster data adds georeferencing problems

A raster can also have the correct CRS and still appear in the wrong place.

Unlike a simple vector point, a raster needs information describing where its pixel grid belongs geographically. Depending on the format and workflow, that can involve a geotransform, affine transformation, ground-control points, geolocation arrays or other georeferencing information.

If that information is missing or incorrect, the pixel values may be perfectly valid while the image is positioned incorrectly.

Reprojecting such a raster does not automatically repair bad georeferencing. GDAL's raster reprojection process relies on the spatial information available for the source in order to determine how source pixels map into the destination CRS.

So when a raster alone is offset, inspect its extent and georeferencing as well as its CRS.

A practical troubleshooting order

When a layer appears in the wrong place, this sequence avoids many unnecessary transformations.

1. Know where the data should be. You need at least an approximate expected country, region or extent.

2. Inspect several raw coordinates. Look at their magnitude, signs and units if known.

3. Check the declared CRS. Do not assume that the metadata is correct merely because an EPSG code is present.

4. Compare the CRS with the coordinate values and source documentation. Ask whether the assigned CRS plausibly describes how those numbers were created.

5. Check coordinate order and fields. Especially for geographic data imported from CSV, JSON, APIs or custom software.

6. Determine whether the error affects every feature. A consistent layer-wide displacement and a handful of bad records point towards different causes.

7. Consider transformations only after the source CRS is established. Reprojecting incorrectly interpreted coordinates compounds the error.

8. For rasters, inspect georeferencing as well as CRS metadata.

9. Keep a copy of the original data. Diagnosis becomes considerably harder after several speculative CRS assignments and transformations have overwritten the starting point.

The objective is not to find a CRS that makes the layer look right. It is to establish why the coordinates mean what you claim they mean.

Fix the interpretation before the appearance

A misplaced GIS layer often looks like a visual problem, but its real cause usually lies earlier in the data chain.

The map can only place coordinates according to the information it has. If the coordinates are correct but their CRS is wrong, correct the assignment. If their source CRS is known and another CRS is required, reproject them. If latitude and longitude have been reversed, correct their order. If only individual records are wrong, investigate the records rather than transforming the entire layer.

And if you do not yet know which of those situations applies, preserve the original data and keep diagnosing.

A layer appearing in the right place is ultimately only a visual sanity check. The stronger result is being able to explain why it is in the right place.

References

1. QGIS Documentation — Working with Projections. Describes layer and project CRSs, missing CRS handling, and on-the-fly transformations; it also notes that assigning an incorrect layer CRS can place data incorrectly. QGIS: Working with Projections

2. GDAL Documentation — Reprojecting Data with GDAL. Explains CRS inspection and the distinction between adding missing CRS metadata and reprojecting coordinates. GDAL: Reprojecting Data with GDAL

3. GDAL Documentation — ogr2ogr. Distinguishes assigning an SRS without reprojection from transforming coordinates into a target SRS. GDAL: ogr2ogr

4. PROJ Documentation — FAQ. Explains authority-defined axis ordering and the difference between formal CRS axis order and traditional GIS coordinate conventions. PROJ FAQ