You loaded a layer, and now your GIS data is in the wrong place. However, the fix is usually simple. So this guide explains why data lands in the wrong place, and how to put it back.
Almost always, the cause is the coordinate system. In short, the numbers are fine, but their meaning is unclear. So the software guesses, and it guesses wrong. As a result, your data in the wrong place is a mismatch, not bad data.
Three problems cause most cases. First, a missing .prj file. Second, projected metres read as degrees. Third, latitude and longitude swapped. So check these before anything else.
A shapefile stores its coordinate system in a .prj file. However, people often forget to send it. Without it, nothing knows the system. So the layer floats to the wrong spot. To fix data in the wrong place here, add the .prj, or set the system by hand.
Open the layer properties. Then look for the coordinate system. If it says unknown, the .prj is missing. So define it before you reproject.
Projected systems use metres, like UTM. For example, 451234 and 5411234 are metres. However, if software reads them as degrees, the point flies far away. So the value looks huge for a longitude.
Tell the software the real system. For instance, EPSG:32631 for UTM zone 31N. Then reproject to WGS84 for web maps. After that, the point lands correctly.
This one is common with spreadsheets. People put longitude in the latitude column. As a result, the point lands in the wrong hemisphere. So use the range test. Any value above 90 must be longitude.
Swap the two columns. Then check the preview. When you use the spreadsheet tool, the live map makes the mistake obvious before you export.
Run through these in order. First, confirm the coordinate system is set. Next, reproject to WGS84 if needed. Then, check for swapped columns. Finally, confirm no coordinates are 0,0, which lands off Africa. You can look up any code at epsg.io. In short, once the system is right, data in the wrong place snaps back into place.
The usual cause is a coordinate system mismatch. The coordinates are fine, but the software does not know which system they use, so it places them incorrectly. A missing .prj file, projected metres read as degrees, or swapped latitude and longitude are the top three reasons.
First set or correct the coordinate system, then reproject to WGS84 if you need lon/lat. If the data came from a spreadsheet, check that latitude and longitude are not swapped, and that no rows have 0,0 coordinates.
The .prj file records a shapefile's coordinate system. Without it, software cannot tell whether the numbers are degrees or metres, so the layer often lands far from where it should. Always include the .prj.
Coordinates of 0,0 place a point at 'Null Island', off West Africa. It means the latitude and longitude fields were empty or unparsed, usually after a spreadsheet import where the coordinate columns were not recognised.
Check the data's source or metadata. Web data is usually WGS84 (EPSG:4326). Survey and engineering data is often a UTM zone or a national grid in metres. You can look up the exact EPSG code at epsg.io.
