Bug report #4583

Raster reprojection error (plus QGIS freeze)

Added by dr - almost 8 years ago. Updated over 7 years ago.

Status:Closed
Priority:High
Assignee:-
Category:Projection Support
Affected QGIS version:1.7.3 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:Yes Copied to github as #:14490

Description

Open attached file and do the following steps: Settings -> Project Properties -> Enable 'on the fly' CRS transformation, EPSG:900913 -> OK. QGIS throws an error message and freezes.

err-screen.png - error message (7.46 KB) dr -, 2011-11-30 09:50 PM

output.tif - raster (682 KB) dr -, 2011-11-30 09:50 PM

teste_freeze.tif.tar.gz (92.5 KB) Giovanni Manghi, 2011-12-30 05:45 AM

teste_nofreeze.tif.tar.gz (7.82 KB) Giovanni Manghi, 2011-12-30 05:48 AM

teste_onlywarning.tif.tar.gz (90 KB) Giovanni Manghi, 2011-12-30 05:53 AM


Related issues

Duplicates QGIS Application - Bug report #4748: Raster reprojection in broken in qgis-master and has prob... Closed 2012-01-04

History

#1 Updated by Giovanni Manghi almost 8 years ago

  • Target version changed from Version 2.0.0 to Version 1.7.3

I confirm the issue on qgis-master/ubuntu 11.10.

I noticed also that if is set the CRS in the project properties without enabling OTFR and OTFR is enabled after, then the issue does not surface and the raster is correctly reprojected.

#2 Updated by Giovanni Manghi almost 8 years ago

I noticed also that if is set the CRS in the project properties without enabling OTFR and OTFR is enabled after, then the issue does not surface and the raster is correctly reprojected.

But still it is a real issue, because if you do "zoom to layer extent" after enabling OTFR, is ok. But if after enabling OTFR you do a refresh or a pan (before doing "zoom to layer extent") then the error is thrown and qgis freezes.

#3 Updated by Giovanni Manghi almost 8 years ago

  • Target version changed from Version 1.7.3 to Version 1.7.4

#4 Updated by Giovanni Manghi over 7 years ago

  • Affected QGIS version set to master
  • Crashes QGIS or corrupts data set to Yes
  • Subject changed from Raster reprojection error to Raster reprojection error (plus QGIS freeze)
  • Priority changed from High to 6

In qgis-master any attempt to reproject a raster (it seems it doesn't affect WMS) in a projected CRS into a geographic CRS (but NOT vice versa)it results in this warning

*forward transform of
(29001.8, 83811.8)

failed with error: latitude or longitude exceeded limits*

that pop up always if the mouse passes over the canvas.

After enabling OTFR and setting the project CRS as WGS84 (example), the warning pops up and somehow the user can reach the TOC and select "zoom to layer" to workaround the issue. In same cases (see the description of this ticket) it doesn't work, qgis shows the hourglass and everything is blocked/freeze, and kill the program is the only way out.

#5 Updated by Giovanni Manghi over 7 years ago

attached a raster that causes infinite hourglass/freeze after setting OTFR on/WGS84 and selecting "zoom to layer"

#6 Updated by Giovanni Manghi over 7 years ago

A clip of the above raster causes the same continuous warning but no infinite hourglass/freeze

#7 Updated by Giovanni Manghi over 7 years ago

The issue reported originally in this ticket is very similar (the warning/freeze happens when reprojecting between two projected CRSs), but maybe is different, so it could be needed to open a separate ticket.

#8 Updated by Giovanni Manghi over 7 years ago

This sample raster causes only the warning when enabling OTFR/WGS84, but after making to click on "zoom to layer" it is ok.

#9 Updated by Bill Williamson over 7 years ago

Win7 QGIS 1.7.3 00624b3

OK, with teste_onlywarning.tif I get "Error: Forward Transform....." and then hourglass which is hard to kill.

My own experience is with Landsat raster which has been processed in Grass as EPSG:32755 ID:3205, I try to open in a project set as EPSG:28355 ID:2449 (since I am trying to update projects) with OTF turned on, I get a major crash of QGIS. If I set project to ID:3205 then the raster will open OK.

Seems similar to the experience above.

Hard to troubleshoot for me since Landsat rasters are troublesome with Southern Hemisphere projections.

#10 Updated by Bill Williamson over 7 years ago

Also, I had a look at #3099-22 and loaded in the two projection files, no improvement. In fact if I use UTM AGD66 I also get "QGIS.exe not working".

#11 Updated by Bill Williamson over 7 years ago

A US$25 Bounty on this bug

#12 Updated by Giovanni Manghi over 7 years ago

  • Tracker changed from Bug report to 4

#13 Updated by Radim Blazek over 7 years ago

The problem was introduction of mCachedTr in QgsMapRenderer. The cached transformation was not properly updated after destination CRS change. It means that (if only one layer was add to qgis) layer extent was projected to default CRS (latlong). Then the wrong extent was also used in view context and map units per pixel were wrong (very small number (degrees/pixel)), from that wrong value was calculated very large size of image -> freeze.

The cache is fixed in 9a9b53bb. With that fix I can open output.tif and set to 900913. The strange thing is, that this bug was reported before the cache was introduced (e6167d24 Jan 3 2012)!!!

Please test with your data.

#14 Updated by Alexander Bruy over 7 years ago

  • Status changed from Open to Closed

Seems fixed in 9a9b53bb94.

#15 Updated by Alexander Bruy over 7 years ago

One note: when reprojected vector all works fine, but when reprojecting raster in Message log I can see errors:
Could not reproject view extent: forward transform of

(179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000, 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000)
PROJ.4: +proj=utm +zone=48 +datum=WGS84 +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 [email protected] +wktext +no_defs
Error: non-convergent inverse meridinal dist

#16 Updated by Jürgen Fischer over 7 years ago

  • Tracker changed from 4 to Bug report

Alexander Bruy wrote:

Seems fixed in 9a9b53bb94.

please retest with 84dc1ba5.

#17 Updated by Jürgen Fischer over 7 years ago

  • Status changed from Closed to Reopened

#18 Updated by Radim Blazek over 7 years ago

Alexander Bruy wrote:

One note: when reprojected vector all works fine, but when reprojecting raster in Message log I can see errors:
Could not reproject view extent: forward transform of
Error: non-convergent inverse meridinal dist

But this error happens only until you set view extent to a reasonable area, right?
If so, it should not be a big problem, it means that it is impossible to reproject the raster to current view extent.

I would also prefer some cleaner solution, but the problem is how to find the area in target CRS to which an extent in source CRS can be reprojected. We were discussing this in mailing list, but it seems that there is no simple and clean solution. For now, if extent reprojection fails, the raster is not draw and the error in log is about that.

Of course, it can also happen that a full raster extent reprojection fail, but we could still reproject a small piece of raster.

#19 Updated by Alexander Bruy over 7 years ago

Jürgen Fischer wrote:

please retest with 84dc1ba5.

Tested with 836f235, same result

Radim Blazek wrote:

But this error happens only until you set view extent to a reasonable area, right?

This error repeated several times in Message Log window after pressing OK button in Projections tab.

#20 Updated by Jürgen Fischer over 7 years ago

  • Status changed from Reopened to Closed
  • Resolution set to fixed

#21 Updated by Giovanni Manghi over 7 years ago

  • Status changed from Closed to Open
  • Resolution deleted (fixed)

It is not fixed, see also #4748 The tickets seems to be duplicates, but I'm not sure as the error message with the raster originally attached to this ticket it is slightly different. If the issue is the same just close it again.

#22 Updated by Jürgen Fischer over 7 years ago

  • Affected QGIS version changed from master to 1.7.3

Giovanni Manghi wrote:

It is not fixed, see also #4748 The tickets seems to be duplicates, but I'm not sure as the error message with the raster originally attached to this ticket it is slightly different. If the issue is the same just close it again.

3091149a adds some additional errors message to the logs.

I can't reproduce the problem with output.tif - seems fixed.

teste_freeze.tif and teste_nofreeze.tif now produce an error message that the transformed extents to the layers are empty. Before enabling OTFP would just make the rasters disappear and "zoom to layer" would silently ignore the empty extent.

As PROJ.4 doesn't seem to consider that an error, I added an error message when and non-empty extent is transformed into an empty one. I suspect that the coordinates used in the two rasters are invalid for the coordinate system.

No problems with teste_onlywarning.tif. I think master isn't affected anymore.

#23 Updated by Bill Williamson over 7 years ago

Yes I can display test_onlywarning.tif in
QGIS version
1.9.90-Alpha
QGIS code revision
c25ae56
and using proj ID 3205, but in any other projection there is an error.

#24 Updated by Giovanni Manghi over 7 years ago

Hi Jurgen,

I can't reproduce the problem with output.tif - seems fixed.

as in #4748 it works ok under Windows while under Linux I get

forward transform of
(0.079943, 1.017802)
PROJ.4: +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 [email protected] +wktext +no_defs +to +proj=utm +zone=48 +datum=WGS84 +units=m +no_defs
Error: latitude or longitude exceeded limits

(in this specific case when reprojecting the raster to the Google Mercator CRS)

teste_freeze.tif and teste_nofreeze.tif now produce an error message that the transformed extents to the layers are empty. Before enabling OTFP would just make the rasters disappear and "zoom to layer" would silently ignore the empty extent.

As PROJ.4 doesn't seem to consider that an error, I added an error message when and non-empty extent is transformed into an empty one. I suspect that the coordinates used in the two rasters are invalid for the coordinate system.

No problems with teste_onlywarning.tif. I think master isn't affected anymore.

teste_onlywarning.tif works fine now under both Linux and Windows. This raster example is in the 3003 CRS and so I'm seeing a difference of behaviour between this example and the one now attached to #4748

About the other two examples (teste_freeze.tif and teste_nofreeze.tif): you are right, are geotiffs with a wrong CRS. They were given the wrong CRS by mistake, nevertheless I believe it is useful (but at this point not urgent) to avoid freezes and crashes even in this cases.

The wrong CRS is 3763, the same of the sample attached now in #4748 and the behaviour with "teste_nofreeze.tif" is the same I reported now in the same ticket: under Windows it is handled correctly while under Linux I get

forward transform of
(-2.433006, 2.817707)
PROJ.4: +proj=longlat +datum=WGS84 +no_defs +to +proj=tmerc +lat_0=39.66825833333333 +lon_0=-8.133108333333334 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs
Error: latitude or longitude exceeded limits

With "teste_freeze.tif" I get the message

forward transform of
(-2.970111, 3.123830)
PROJ.4: +proj=longlat +datum=WGS84 +no_defs +to +proj=tmerc +lat_0=39.66825833333333 +lon_0=-8.133108333333334 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs
Error: latitude or longitude exceeded limits

also under Windows (beside linux), then the "infinite hourglass" that make necessary to kill qgis

#25 Updated by Giovanni Manghi over 7 years ago

  • Status changed from Open to Closed

Jürgen Fischer wrote:

Jürgen Fischer wrote:

Giovanni Manghi wrote:

ps, in Windows it work as expected, no annoying warning pop

so you're not running valuetool on windows? ;)

damn me... I didn't had the value tool active so I didn't think it was installed... sorry for the noise.

#26 Updated by Bill Williamson over 7 years ago

Hi Jurgen, we owe you a bounty?

Also available in: Atom PDF