Bug report #18454
Newer builds (with proj 5?) can't reproject XYZ layers (and other world-wide rasters) to local CRSes because of layer extent exceeding limits
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: | - | ||
| Category: | Projection Support | ||
| Affected QGIS version: | 3.1(master) | Regression?: | Yes |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | invalid |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 26342 |
Description
Although world-wide layers are not designed to be entirely reprojected to local CRSes with limited extent, it's essential to be able to reproject OSM background to any CRS.
With proj 5 (even after the recent fix that solves the well known shift), XYZ OSM layer is no longer reprojectable to Polish local CRSes, and probably many others. The log console says:
Raster tab: Could not reproject layer extent: Could not transform bounding box to target CRS CRS tab: Transform error caught: Could not transform bounding box to target CRS
When playing with it, I got an error blaming the -87.725475 longitude:
Transform error caught: inverse transform of (-87.725475, 63.050312) PROJ: +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs Error: latitude or longitude exceeded limits
I exported OSM to two layers covering Europe's neighbourhood, with different western extent: about -68 and -85 degrees (still in EPSG:3857). Both layers can't be reprojected in whole to EPSG:2180 (no surprise, as they are far bigger than its extent). But as long as the map canvas covers just Europe, the first map is properly reprojectable. The second isn't, no matter how small the reprojected area is, just because of the layer extent.
You can find them in the attached GPKG, as well as contour of Poland in EPSG:2180.
Maybe I should rather raise it in proj's trac, as both QGIS 2.18 and 3.1 are affected when proj=5.0.0-3 (Debian's version with the recent fix for the shift), and both work fine with proj 4.9.3.
History
#1
Updated by Kristian Evers about 6 years ago
This seem to be fixed in 5.0.1. Please open stuff like this on the PROJ issue tracker. We are not likely to see them otherwise.
$ cs2cs.exe
Rel. 5.0.1, April 1st, 2018
usage: cs2cs.exe [ -eEfIlrstvwW [args] ] [ +opts[=arg] ]
[+to [+opts[=arg] [ files ]
$ echo -87.725475 63.050312 | cs2cs +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
1373062.07 6052830.53 -0.00
echo 1373062.07 6052830.53 -0.00 | cs2cs -I +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
-87.73 63.05 0.00
Borys Jurgiel wrote:
Although world-wide layers are not designed to be entirely reprojected to local CRSes with limited extent, it's essential to be able to reproject OSM background to any CRS.
With proj 5 (even after the recent fix that solves the well known shift), XYZ OSM layer is no longer reprojectable to Polish local CRSes, and probably many others. The log console says:
[...]
When playing with it, I got an error blaming the -87.725475 longitude:
[...]
I exported OSM to two layers covering Europe's neighbourhood, with different western extent: about -68 and -85 degrees (still in EPSG:3857). Both layers can't be reprojected in whole to EPSG:2180 (no surprise, as they are far bigger than its extent). But as long as the map canvas covers just Europe, the first map is properly reprojectable. The second isn't, no matter how small the reprojected area is, just because of the layer extent.
You can find them in the attached GPKG, as well as contour of Poland in EPSG:2180.
Maybe I should rather raise it in proj's trac, as both QGIS 2.18 and 3.1 are affected when proj=5.0.0-3 (Debian's version with the recent fix for the shift), and both work fine with proj 4.9.3.
#2
Updated by Borys Jurgiel about 6 years ago
Thanks! I'm not fully sure if it's proj or QGIS problem, so I'll try to isolate it from QGIS first and move to the PROJ tracker if appropriate.
Please note the (-87.725475 63.050312) coordinates from your test are metres in the source CRS (EPSG:2180), so it's close to Poland and it works well in both proj versions. The (-87 63) degrees would be about (-10'000'000 18'000'000) in EPSG:2180 and it's faaaar beyond the CRS extent. Both versions fail to reproject it (cs2cs 5.0.0 says "pj_transform(): latitude or longitude exceeded limits" and cs2cs 4.9.3 says - AFAIRC - "pj_transform(): unknown error"). So indeed, there is a slight difference in the error message, what may be a clue.
Anyway, QGIS with proj 4.9 was able to reproject just the appropriate part of a world-wide layer (XYZ as well as GeoTIF), no matter of errors on its periphery.
But first I'll wait for 5.0.1 to land in Buster (just in case) ;)
#3
Updated by Borys Jurgiel about 6 years ago
- Subject changed from With proj 5, error reprojecting XYZ layers to some CRSes because of layer extent exceeding limits to Newer builds (with proj 5?) can't reproject XYZ layers (and other world-wide rasters) to local CRSes because of layer extent exceeding limits
After some more tests I can precise the issue: Raster layers (tested XYZ, WMS and GeoTiffs) with a world-wide extent can't be reprojected to local CRSes like Polish EPSG:2810 or British EPSG:27700, just because their whole bounding box is not projectable in that CRS (it doesn't matter if the source CRS is 3857 or 4326). As a result, you can't use OpenStreetMap or aerial imagery XYZ in projects in local official CRSes. On the contrary, vector layers (tested on world coastlines shp) work well - of course unless you zoom out too much.
I'm still not sure when the problem began, but comparing affected and not affected versions, it seems it's proj 5 or GDAL 2.2.4:
QGIS system gdal proj result -------------- ------------- ----- ----- ------------ 2.18, 3.0, 3.1 win 2.2.3 4.9.3 works fine 2.18.18 debian jessie 1.10 4.8 works fine 2.18, 3.0, 3.1 debian buster 2.2.4 5.0.0 DOESN'T WORK 2.18, 3.0, 3.1 debian buster 2.2.4 5.0.1 DOESN'T WORK
The affected (Debian's) QGIS 3 logs a number of "Could not transform bounding box to target CRS" to the Raster log tab after any canvas refresh. It's thrown from QgsCoordinateTransform::transformBoundingBox(). The same exception is logged once to the CRS tab on layer load for both raster and vector layers, but it seems to be not blocking, as vectors work. In QGIS 2.18 that exception was not implemented yet, so it fails quietly.
However... Also in the non-affected Windows version of 3.x this exception is logged neither in Raster nor CRS tab, what may be a clue... Unfortunately I'm not able to debug it under windows.
#4
Updated by Borys Jurgiel about 6 years ago
- Resolution set to invalid
- Status changed from Open to Closed
Ok, definitely not a QGIS issue. Gdalwarp 2.2.3 @ proj 4.9.3 is able to transform a worldwide geotiff to epsg:2180 despite errors:
C:\Users\Borys\GISDATA>"C:\Program Files\QGIS 3.1\bin\gdalwarp.exe" -t_srs EPSG:2180 -te 100000 100000 900000 900000 world.tif poland.tif ERROR 1: latitude or longitude exceeded limits ERROR 1: latitude or longitude exceeded limits ERROR 1: latitude or longitude exceeded limits ERROR 1: latitude or longitude exceeded limits (...) ERROR 1: latitude or longitude exceeded limits ERROR 1: Reprojection failed, err = -14, further errors will be suppressed on the transform object. ERROR 1: tolerance condition error 0...10...20...30...40...50...60...70...80...90...100 - done.
While gdalwarp 2.2.4 @ proj 5.0.1 gives up with just one error:
gdalwarp -t_srs EPSG:2180 -te 100000 100000 900000 900000 world.tif poland.tif Using band 4 of source image as alpha. ERROR 1: Too many points (1681 out of 1681) failed to transform, unable to compute output bounds.
Actually removing the -te parameter and reprojecting the whole world doesn't change the errors. 4.3.9 is still able to finish successfully.
I'll move it to the proj4 trac.