Bug report #13665

White areas displayed instead of data with CRS Transformation On The Fly (OTF)

Added by Henrik Forsberg over 8 years ago. Updated over 8 years ago.

Affected QGIS version:2.10.1 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:21700


Data are missing and replaced with white regions during browsing, zooming and print composition, when CRS Transformation On The Fly (OTF) is applied. OTF worked with no problems in QGIS 2.8.3 and previous versions, but is now causing problems in QGIS 2.10.1. Screen shoots are seen in the attachment.

To duplicate the problem:
1) Open a TIFF-file of the entire World in EPSG:4326 (WGS84) in a new blank project (an example link is found below).
2) Enable OTF.
3) Apply EPSG:3574 (WGS 84 / North Pole LAEA Atlantic).

The screen shoots attached shows to the left the original raster before transformation.
In the middle is the useful OTF from QGIS 2.8.
To the right is the non-useable OTF from QGIS 2.10 with white regions around the pole and along longitude 180. The keyhole-shaped white regions changes as zoom level changes, and composing a print in 2.10 makes the white regions unpredictable on the map, making display, zoom and print not useable.
No white regions appeared in display, zoom and print composition in QGIS 2.8.

The obvious work-around of warping the original raster file generates an undesired strip of missing data along longitude 180 in both QGIS 2.8.3 and 2.10.1 (result is shown in the bottom of picture).

The used tiff is the neat Cross Blended Hypso with Shaded Relief and Water (HYP_50M_SR_W.tif) from Natural Earth (http://www.naturalearthdata.com/downloads/50m-raster-data/).

QGIS_OTF_WhiteSpace.jpg - Screen shoots of OTF in QGIS 2.8.3 and 2.10.1 (166 KB) Henrik Forsberg, 2015-10-24 04:46 AM

3574-400points.jpeg - extent transformation with 400 points (25 KB) Radim Blazek, 2015-10-29 10:44 AM

3574-1000points.jpeg - extent transformation with 1000 points (24.9 KB) Radim Blazek, 2015-10-29 10:44 AM

Associated revisions

Revision 1c224453
Added by Radim Blazek over 8 years ago

fix raster projector src extent calculation, fixes #13665


#1 Updated by Sebastian Dietrich over 8 years ago

I can confirm this still is in 4f8a27d

#2 Updated by Jürgen Fischer over 8 years ago

reverting the raster projector part of 6a6b3b4 fixes it.

#3 Updated by Radim Blazek over 8 years ago

  • Status changed from Open to Closed

#4 Updated by Radim Blazek over 8 years ago

The problem was calculation of source extent, that is fixed in 1c22445 using again approximation matrix (which cannot be used for reprojection itself in this case).

Similar problem with extent transformation is causing cutting of edges. In 8993a4bc I have increased number of points used for transformation from 64 to 1000 (still quite fast, < 1ms / 3Ghz). See attached pictures for 400 and 1000 points.

Also available in: Atom PDF