QGIS » QGIS Application

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.

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.

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.

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".

A US$25 Bounty on this bug

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.

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 +nadgrids=@null +wktext +no_defs
Error: non-convergent inverse meridinal dist

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.

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.

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.

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 +nadgrids=@null +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

Hi Jurgen, we owe you a bounty?