3

I'm using QGIS 3.4.1, and I'm trying to print 61km x 61km area map of somewhere South Korea. Then I need to send this map with west / east latitude and north / south longitude info to other person, who need to do some work on that map. Here's what I did.

First, I set project CRS to EPSG 32652, WGS84 - UTM zone 52N, because most of South Korea is in the zone 52N.

Second, I load maps from Quick Map Service plugin, ESRI map from ArcGIS Map Server layer, Openlayers plugin. I also downloaded SRTM data using SRTM downloader, and also from CGIAR-CSI for double check.

Third, I found out that all of layers that I loaded or downloaded have CRS of EPSG 3857, WGS84 - Pseudo Mercator. I intuitively thought that they should have the same CRS with project CRS. So I changed CRS of all layers to project CRS, which is EPSG 32652, WGS84 - UTM zone 52N.

Then I found out something gone wrong seriously. Distance is distorted, grids, scale bar, and ruler show unusually shorter distance than it should be. In addition, I found that lat long coordinate shown from Lat Long tools plugin is really really off from real Lat and Long coordinate. For example, typical Lat Long position of Seoul is around 37.55 N, 127.03 E. However, Lat Long position from map after map CRS conversion shows around 8.45 N, -151.53 E. Moreover, all SRTM data layer moved to really strange position.

Just in case, I repeated the same procedure from QGIS 2.18 with on-the-fly CRS transformation option on. But the same symptom occur.

I think major problem here is the CRS, project CRS and layer CRS. I think my "I intuitively thought that they should have the same CRS with project CRS. " this part is wrong, but I can't understand.

Why should I need to use WGS 84 Pseudo-Mercator CRS for layers, while using WGS 84 UTM 52N CRS for project?

And I don't know what to tell my coworker, which CRS I used for this 61km x 61km area map.

  • 1
    Is your project CRS WGS84 UTM 52n? The layer CRS should sort themselves out if you have project-on-the-fly enabled (is enabled by default) provided the underlying GCS is WGS84 or at least compatible with WGS84. SRTM should be WGS84/Geographic, open street map WGS84 pseudo, I don't know which Esri map you've loaded but it should be WGS84 compatible. Don't change the CRS of the layers unless you know that they are wrong and you know what they should be, just set the project CRS to how you want your map and it should be fine. – Michael Stimson Nov 29 '18 at 4:10
  • @MichaelStimson Thank you. Then, what should I need to tell my friend if he wants to print the same map from other GIS tools (he is using Global Mapper)? I told him my map is based on WGS84 UTM 52N CRS, and corresponding west / east latitude and north / south longitude. But his map is slightly off sync from my map... Should I need to tell him to use WGS 84 Pseudo-Mercator? – exsonic01 Nov 29 '18 at 4:14
  • No, global mapper is a different product but the procedure is similar; not that I'm an expert in Global Mapper. It could be in the translation of the lat/lon coords you've provided. You could send him your project file and local data and tell him to use QGIS, that way you eliminate any discrepancies between the packages. – Michael Stimson Nov 29 '18 at 4:25
  • @MichaelStimson Thank you for your advice, I will let him know what I did and will send him files if he want. – exsonic01 Nov 29 '18 at 4:41
  • You're welcome. If your colleague insists on using Global Mapper then I would say that your responsibility is absolved, unless you are an expert in global mapper and you're willing to extend product support, it would be their responsibility to setup their software and if they're having difficulty creating their map then they can post a question on GIS.SE. It would just be easier for all concerned if you both used the same package and exchanged project files. – Michael Stimson Nov 29 '18 at 5:01
3

It sounds like there may be a misunderstanding of the difference between defining a dataset's projection and reprojecting the data itself. This ESRI blog post does a pretty good job of explaining the difference, and this QGIS documentation explains the underlying concepts.

In short, every dataset has a CRS—a way of defining what it's coordinates mean. Some are lat/long, others are easting/northing from a specified origin (like UTM), and there may be other more esoteric CRS's out there.

Defining a dataset's projection tells dataset to say it's using a specific CRS, but doesn't actually change the coordinates of the data. It's entirely possible (and common) to define a CRS that doesn't match the actual coordinates. This usually results in data in weird places, funky scales, etc. Like Michael said, don't redefine the projection unless you are certain it's wrong.

Reprojecting a dataset involves mathematically changing the coordinates of the data (and automatically defining the projection at the same time). I often reproject data from a UTM-based projection to a US State Plane-based projection when I'm pulling in data to my database.

When you set a project CRS, you are telling the software which projection to use to display the data on the 2D surface of the monitor or the paper. Different projections have different tradeoffs and are suited for different uses. The on-the-fly transformation automatically translates the dataset's CRS to the project's CRS for display only (it doesn't change the data itself), allowing you to add data that doesn't match the project CRS without first reprojecting the data.

Based on what you said about changing the CRS of all the layers, I suspect you redefined the layers' projections without actually reprojecting the data. Then, when the on-the-fly transformation chose where to place the data on the map, it put it in the wrong place because it was interpreting the coordinates incorrectly.

  • Yes, very common to incorrectly overwrite a datasets' CRS. I've seen dozens of questions on this site where the user has overwritten or incorrectly applied a CRS, partly when users mean to project the data but end up overwriting the correct CRS with the CRS they want the data to be in. – Michael Stimson Nov 29 '18 at 4:56
  • Thanks for your explanation Jake and Michael, those discussions were really helpful. – exsonic01 Nov 29 '18 at 5:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.