QGIS – Changing Shapefiles from Geographic (WGS84) to Projected (EPSG:2263) Coordinate System

Question

I am trying to calculate service area polygons using the QNEAT3 plug in tool for a project I am doing. However, I got an error before these polygons could be created.

2021-01-04T08:03:38 CRITICAL The TIN-Interpolation algorithm in QGIS is designed to work with projected coordinate systems. Please use a projected coordinate system (eg. UTM zones) instead of geographic coordinate systems (eg. WGS84)!

I thought I had changed the Coordinate Reference System for all my layers to NAD83 / New York Long Island or EPSG:2263 (the project is about New York City), but after doing it again, I got the same error.

I realized that changing the CRS from WGS84 to NAD83/NY Long Island moved some layers from the accurate spot in NYC to some random spot in Pennsylvania, and on a completely different scale. However, other layers that were already in NAD83/NY Long Island were still in the right spot.

The yellow dot is one of the layers that got moved to the wrong spot after being converted from WGS84 to NAD83/NY Long Island.

I added an OSM base map to illustrate the problem.

If you zoom in, the layer is ridiculously small for some reason. A layer that should encompass an entire city is smaller than a single house.

This is what the layer is supposed to look like, and where it should be located.

Something is very wrong, but what is it?

Answer 1

This answer has four sections:

1. What you should do to solve the problem and what you should avoid
2. An example to better illustrate why assigning CRS and reprojecting are not the same
3. An analogy that should help to make this difference better understandable
4. Using batch process to transform several layers at once in QGIS

1. What you should (not) do to solve the problem

Do NOT "change" the CRS: what you did is simply assigning another CRS definition to your layer. However, your layer is saved with coordinates in a certain CRS (projection), so if you assign another CRS, the coordinates from one CRS (like EPSG:4326 / WGS84) are interpreted as being coordinate values belonging to another CRS, in your case NAD83/ New York Long Island EPSG:32118.

What you should do is reprojecting the layer: right click on your layer / Export / Safe features as... or go to menu Processing / Toolbox / reproject layer. There, you can define the CRS that your existing layer should be reprojected to. You will get a copy of your input layer in the new CRS.

When saving, in the dialog window you have a CRS section with a drop down menu where you can select the CRS you want to reproject to. Or click on the right side the small symbol "globe with grid". It will open an advanced CRS selection dialog with more information and the option to filter the CRS description by introducing some letters or numbers:

---

2. Case study to illustrate assigning CRS vs. reprojection

To illustrate that: let's say you have coordinates in EPSG:4326 (WGS84, GPS coordinates) 0° E, 51.4777° N: a point nearby the Greenwich observatory in London (today's IERS reference meridian passes a few dozen meters to the east of the observatory, but that is another story, however it shows how complex the topic is).

If you now change the EPSG, you assign another definition to the coordinate values of 0 and 51.4777. Let's say we tell QGIS that these values are in Web Mercator, EPSG:3857. This defintion has it's point of origin at the intersection of the equator (red line) with the prime meridian (blue line), a point in the Atlantic west ob Gabon, south of Ghana: the red cross on the following map:

This point of origin is the same as when using EPSG:4326. But EPSG:3857 is a projected CRS, thus it measures it's coordinates not on a globe (spheroid) as EPSG:4326 does that uses degrees as unit, but on a planar map projection and uses meters. Both start at the same point of origin in the Atlantic. So in EPSG:3857/WebMercator, the latitude is measured in meters and our point will be 51.4777 meters to the north of this point, thus in the Atlantic very close to the point of origin. The longitude still has the "right" value because 0 remains zero, thus in this special case, nothing changes (to make things a bit easier here).

You see this on this screenshot: a point created in EPSG:3857 with coordinates lon 0, lat 51.4777 creates a point that is a few dozen meters north of the equator (red line):

To get the "right" coordinates value for the point near the Greenwich observatory in EPSG:3857, we must use a transformaton algorithm. QGIS normally handels this automatically when we reproject. But often there are several different algorithms for the transformation available. In such cases, QGIS alerts with a dialog window where we can choose one of the available transformations - see the following screenshot. The background: this has to do with different mathematical methods of transformation. Calculating the earths shape to different projections is not so trivial and is almost always not 100% exact, so you always get minor errors when reprojecting - see the info about the accuracy in the screenshot:

When we reproject, we see that the latitude for our point near Greenwich observatory is 6706107.21 in EPSG:3857 - that means: 6706.1 km to the north of the point of origin in the Atlantic. Be aware: this value is not a distance on earth's surface, but on the projected planar map canvas. Web Mercator heavily distorts lengths, so the values in meters are of use for coordinate values only, not for measuring distances.

We could now use another projected CRS, let's say EPSG:27700, Ordnance Survey, British National Grid. After transformation, we see that the same point near Greenwich observatory has again other coordinates: lat: 177234.2, lon: 538989.7. These values are again in meters, but are completely different from the meters we had before when using Web Mercator. So you see: the values only make sense if they are interpreted in the correct CRS.

---

3. An analogy that should help to make this difference better understandable

An analogy of the difference between set CRS and reproject, as this is a very common mistake a lot of users make: To better understand, you could imagine the different CRS as different "languages" (conventions about the meaning of symbols). If you have a text and try to translate it, you must first know in which language your text is to be able to look for the right dictionaries, hire the right interpreter or do the correct setting in the automatic translation tool.

When you have a text in English and want to have a translation into Chinese, you can't just stick the label "Chinese" on the first page: this does not translate it. To the contrary, the text will make no sense: a native speaker of Chinese will still not be able to understand it (without knowing English) as the English words have no meaning in Chinese. Maybe some words happen to sound similar in both languages, but with completely different meaning: that's what happened to you: your layer was shown in QGIS, but in a wrong, meaningless place.

So that should help understand why you can't simply "change" the language. You must translate - the analogy of reprojecting in QGIS: every word/sentence must be taken from one language to the other one, according to certain rules (grammar). The same with reprojecting: every coordinate has to be recalculated respecting some transformation algorithms.

If you use an online translation tool as Google translate, the language of many texts you paste is automatically recognized. This is what QGIS also tries: when you load data, you normally should not have to set manually the CRS, as in almost all cases the CRS should be already stored in your data. So only if the CRS is not correctly recognized, you should manually assign the correct CRS.

---

4. Using batch process to transform several layers at once in QGIS

If you have several files or layers, you run this as batch process. Just start the reproject dialog using the menu (as described above), than you find a button at the bottom left to start the tool as batch process, see: