Assigning a CRS vs Reprojecting Data
Learn the difference between assigning a coordinate reference system and reprojecting data, why confusing them can move a layer to the wrong place, and which operation to use.
Resolve a common GIS workflow mistake by distinguishing CRS metadata from coordinate transformation, and give readers a practical decision process for missing, incorrect, and correctly identified coordinate systems.
Assigning a coordinate reference system and reprojecting data are not the same operation. Assigning a CRS tells GIS software how to interpret coordinates that already exist. Reprojecting calculates new coordinates that represent the same geographic locations in another CRS.
That distinction matters because assigning the wrong CRS does not convert the data. It merely gives the existing numbers a different meaning, which can cause a layer to appear in the wrong part of the world. Reprojection, by contrast, requires a known source CRS and a target CRS so that the software can transform the coordinates between them.
A useful rule is:
If the coordinates are correct but their CRS label is missing or wrong, assign the correct CRS. If the CRS is already known and you want the data expressed in another CRS, reproject it.
The difference at a glance
Changes coordinate values?: Assign a CRS — No; Reproject data — Yes
Changes how existing coordinates are interpreted?: Assign a CRS — Yes; Reproject data — Produces coordinates in a new CRS
Requires the true source CRS to be known?: Assign a CRS — You must know what CRS the existing numbers already belong to; Reproject data — Yes
Typical use: Assign a CRS — Missing or incorrect CRS metadata; Reproject data — Converting correctly referenced data to another CRS
Geographic locations should change?: Assign a CRS — No—the assignment should describe where the coordinates already belong; Reproject data — No—the new coordinates should represent the same locations
Can fix data with missing CRS information?: Assign a CRS — Yes, if the correct CRS can be established; Reproject data — Not until the source CRS is known
Can convert WGS 84 coordinates into a projected CRS?: Assign a CRS — No; Reproject data — Yes
This is not merely a difference in terminology. QGIS, for example, explicitly distinguishes its Assign projection operation—which leaves feature geometries unchanged—from Reproject layer, which calculates coordinates in another CRS. GDAL makes essentially the same distinction between assigning a spatial reference system without reprojection and transforming features into a target spatial reference system.
What does assigning a CRS actually do?
Coordinates on their own are just numbers.
Consider this pair:
12, 4Without additional information, those numbers do not tell you whether they represent longitude and latitude in degrees, eastings and northings in metres, positions on a local engineering grid, or something else entirely.
A coordinate reference system supplies the reference framework that gives those numbers geographic meaning. Assigning a CRS therefore says, in effect:
Interpret these existing coordinates according to this coordinate reference system.
It does not mathematically convert the coordinates.
If a layer contains longitude and latitude coordinates in WGS 84 but has lost its CRS metadata, assigning the appropriate WGS 84 CRS can restore the information software needs to interpret those numbers correctly. The geometries themselves do not have to change because their coordinates were already expressed in that CRS.
The same principle applies when a dataset has been given an incorrect CRS label. If the numbers actually belong to CRS A but the metadata says CRS B, correcting that metadata to CRS A can repair the interpretation without changing the coordinate values.
This is why QGIS describes assigning a projection as creating a layer with the same features and geometries but a different CRS assignment. Its documentation explicitly notes that the geometries are not reprojected.
What does reprojection do?
Reprojection is different because the existing coordinates are already understood.
Suppose an illustrative point is located at:
longitude = 12°
latitude = 4°in WGS 84 geographic coordinates.
If that point is reprojected into EPSG:3857, its coordinates become approximately:
x = 1,335,834 m
y = 445,640 mThe numbers have changed substantially, as have their units, but they still represent the same geographic location within the accuracy of the coordinate operation being used.
That is the essential purpose of reprojection: change the coordinate representation without intentionally changing the geographic position being represented.
This is why understanding the difference between WGS 84 geographic coordinates and Web Mercator coordinates is useful. Reprojection between them cannot be achieved by replacing one EPSG code with another. The coordinates themselves must be transformed.
In GIS software, that transformation may happen explicitly when you export or process a dataset, or temporarily when the software displays several layers together.
Why changing the CRS can make data jump somewhere else
A common mistake is to see a layer in the wrong place and start changing its assigned CRS until it appears to move.
The problem is that assigning a different CRS tells the software to reinterpret the same coordinates under a different reference system.
Imagine that coordinates stored as longitude and latitude in degrees are:
12, 4If they are correctly identified as geographic coordinates, they describe a location at 12° longitude and 4° latitude.
If you simply assign a projected CRS whose coordinates are expected in metres, the numbers remain 12, 4. The software may now interpret them as something like 12 metres east and 4 metres north of that CRS's origin.
Nothing was converted. The meaning of the numbers was changed.
That is why repeatedly changing CRS metadata until a layer “looks right” is dangerous. A plausible visual result is not evidence that the chosen CRS is correct.
If the actual problem is that a dataset appears in the wrong place and you do not yet know why, Why Is My GIS Data Appearing in the Wrong Place? treats that as a broader diagnostic problem rather than assuming that reprojection is always the answer.
The three situations that matter
In practice, most cases fall into three categories.
1. The CRS is missing, but you know what it should be
Suppose a GIS file contains coordinate values that you know were produced in EPSG:4326, but the file no longer carries usable CRS metadata.
You should assign EPSG:4326.
The goal is to restore missing information about coordinates that are already correct.
Reprojecting is not yet necessary unless you subsequently need those coordinates expressed in another CRS.
2. The CRS is correct, but you need a different one
Suppose your layer is correctly identified as EPSG:4326 and you need a projected CRS for a particular analysis or output.
You should reproject from EPSG:4326 to the selected target CRS.
The source interpretation is already known. The task is now to calculate an equivalent set of coordinates in another reference system.
3. The dataset has been assigned the wrong CRS
This case is easy to mishandle.
Suppose the coordinates actually belong to CRS A, but the layer is incorrectly labelled as CRS B. If you immediately reproject from B to CRS C, the transformation starts from a false assumption. The resulting coordinates can therefore also be wrong.
The correct sequence is generally:
establish what CRS the existing coordinate values actually use;
correct or assign that source CRS;
only then reproject to another CRS if necessary.
Reprojection cannot repair an unknown source CRS by itself. A transformation needs to know what the input coordinates mean before it can correctly calculate their representation in the target system. GDAL makes this dependency explicit: a source spatial reference must be available for reprojection to occur.
What if you do not know the original CRS?
Then neither guessing nor immediate reprojection is a reliable solution.
The first task is CRS identification.
Useful evidence can include accompanying metadata, the documented source of the dataset, coordinate ranges, expected geographic extent, units, known control points, filenames or sidecar files, and information from whoever produced the data.
For example, coordinate values such as:
11.52, 3.87look plausible as geographic degrees, while:
554231, 428765look more like projected coordinates. But this is only evidence, not proof. Many projected systems produce similar numeric ranges, and small local coordinate systems can overlap numerically with geographic coordinates.
You should therefore avoid choosing a CRS solely because it makes the layer appear approximately where you expect it to be.
A dataset whose source CRS is genuinely unknown has an information problem before it has a transformation problem. The more detailed question of diagnosing unreferenced data belongs in What Happens When a GIS File Has No CRS?.
On-the-fly reprojection can hide the difference
Modern GIS software often allows layers in different CRSs to appear together without permanently converting each dataset.
QGIS, for example, can transform layers on the fly into the project's CRS for rendering. A layer stored in one CRS may therefore visually align with another layer stored in a completely different CRS.
That convenience can make it seem as if both datasets already share the same coordinate system.
They may not.
If you inspect their underlying coordinates, export them, send them to another application, or run software that does not make the same automatic transformations, the distinction becomes visible again.
This leads to an important practical principle:
Looking aligned on the map does not necessarily mean being stored in the same CRS.
QGIS itself warns that layers can visually overlap because of on-the-fly reprojection even when their original coordinates differ.
That is one reason CRS metadata should be checked before spatial processing rather than inferred from what the map canvas happens to show.
Reprojecting vectors and rasters is not quite the same operation
For vector data, reprojection transforms the coordinates that define points, lines and polygon vertices.
Raster data adds another issue. Pixels occupy a grid, and projecting that grid into another coordinate system generally means constructing a new output grid. Pixel values must then be assigned to it through resampling.
This means raster reprojection can involve decisions that vector reprojection does not: output resolution, grid alignment and the resampling method can affect the resulting raster.
For continuous imagery or elevation, methods such as bilinear interpolation may be useful. For categorical data such as land-cover classes, interpolating between category codes would usually be inappropriate, so nearest-neighbour resampling is often preferred.
The CRS principle remains the same—the source reference must be known and coordinates are transformed—but the mechanics of representing the result differ. The consequences of those raster choices are better handled in the separate guide to raster resampling.
Reprojection can also involve more than a map projection
The word reproject is often used broadly in GIS interfaces, but transforming coordinates between CRSs can involve more than applying a projection formula.
The source and target CRSs may use different datums or reference frames. In that situation, software may need to select a particular coordinate operation between them, potentially using transformation parameters or grid files. QGIS, for example, can offer different datum transformations when several operations are available and attempts to select an appropriate transformation automatically.
For many routine workflows, the software handles this detail for you. But it becomes important when positional accuracy matters, when working with older national reference systems, or when several transformations of different accuracy are available.
The introductory distinction still holds:
Assignment changes the declared interpretation of existing coordinates. Transformation or reprojection calculates coordinates in another reference system.
The mathematics behind the transformation can simply be more involved than the word projection suggests.
A practical decision rule
Before changing anything, ask what is wrong with the current state of the data.
The coordinates are correct, but the CRS metadata is missing. Assign the CRS that the coordinates already use.
The coordinates are correct, but the dataset is labelled with the wrong CRS. Correct the CRS assignment first.
The data is correctly referenced, but another CRS is needed for analysis, interchange or output. Reproject it.
The source CRS is unknown. Identify it before attempting reprojection.
Several layers look aligned only because the GIS is transforming them on the fly. Check their actual layer CRSs before assuming that their stored coordinates are compatible.
The only evidence for a CRS is that selecting it makes the map look approximately right. Keep investigating.
These cases are simple once the distinction between describing coordinates and transforming coordinates is explicit.
Assign first only when the assignment is true
The most important lesson is that assigning a CRS is not a shortcut for reprojection.
A CRS assignment is a statement about what the existing numbers already mean. It should therefore be based on evidence about how those coordinates were created. Reprojection begins only after that meaning is known and calculates another valid representation of the same geography.
Confusing those operations can turn perfectly good coordinates into a misplaced layer. Keeping them separate gives a much cleaner workflow:
identify the source → assign or correct its CRS if necessary → reproject only when another representation is actually needed.
Once that sequence becomes habitual, many apparently mysterious projection problems stop being mysterious at all.
References
QGIS Documentation — Working with Projections. Describes layer CRS assignment, on-the-fly transformation, project CRSs and datum transformations. QGIS: Working with Projections
QGIS Documentation — Assign Projection. Specifies that assigning a CRS keeps the same features and geometries rather than reprojecting them. QGIS: Assign Projection
GDAL Documentation — ogr2ogr. Distinguishes assigning an output spatial reference without reprojection (
-a_srs) from transforming coordinates into a target CRS (-t_srs). GDAL: ogr2ogr