Bug report #5456

Output does not have the same CRS of input if input is tiff+worldfile

Added by Giovanni Manghi over 7 years ago. Updated 9 months ago.

Status:Closed
Priority:Normal
Assignee:Victor Olaya
Category:Processing/Core
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:15091

Description

Add a raster that is (ex) tiff+worldfile (not geotiff) and give it the right CRS in QGIS, then use it as input for one tool available in Sextante (tested otb and saga): the output is added to the project with the same CRS as the input (as expected), but if the same output file is added manually, it is added with the WGS84 CRS and in fact a check (ex: gdalinfo) confirms that the layer is indeed in WGS84 (wrong). This happens regardless if output is vector or raster. When using a geotiff as input all is ok.

History

#1 Updated by Victor Olaya over 7 years ago

What is the CRS in that world file? I guess SAGA and OTB produce the result in the same CRS as the input (or maybe they do not even add a CRS...which might happen). SEXTANTE "forces" the layer to be opened in the same CRS as the input (quite logical...), but as far as I know, there is no support for forcing a CRS for the output in SAGA (I think it might not even have capability to write that CRS or the world file...). As for OTB, i do not know, maybe Julien can tell us...

#2 Updated by Giovanni Manghi over 7 years ago

Hi again,

Victor Olaya wrote:

What is the CRS in that world file?

for example a projected one. When you add such layer in QGIS the program "react" in different ways (defined in "options->CRS"), as the default behaviour is the CRS selector dialog window open to allow the user give the layer the proper CRS (because in the worldfile there is the coordinate of the corner but not the CRS).

I guess SAGA and OTB produce the result in the same CRS as the input (or maybe they do not even add a CRS...which might happen). SEXTANTE "forces" the layer to be opened in the same CRS as the input (quite logical...),

yes, that is what happen. The output is added in the project with the same CRS defined in QGIS for the input, but the output itself is given the wrong CRS (wgs84). This seems to me to happen regardless the toolbox used (just tested again also with GDAL). If the input is a geotiff the output has the correct CRS.

Note:
With GRASS it seems that v.out.ogr and r.out.gdal under Sextante always export without .prj and as tiff+worldfile (regardless if the input is for example a geotiff or a tiff+worldfile) while would be better to have the .prj written and the raster output as geotiff (as the tools in GRASS and in QGIS/GRASS plugin do) -> do you want me to file a ticket about this?

but as far as I know, there is no support for forcing a CRS for the output in SAGA (I think it might not even have capability to write that CRS or the world file...). As for OTB, i do not know, maybe Julien can tell us...

see above, it seems to me that does not depend on the toolbox (but I may be very well wrong).

#3 Updated by Julien Malik over 7 years ago

For OTB it is more or less the same as GDAL : a tiff + world file is interpreted as being WGS84.

If for the output you choose a file with TIFF extension, it will automatically create a GeoTIFF, so the WGS84 CRS will be burned into the output file.

For such an input (tiff+world file+ crs set in qgis by user) to be properly recognized, we should feed OTB (or SAGA or others) not with the original file, but probably make a temporary VRT
(http://www.gdal.org/gdal_vrttut.html) merging all info source into one gdal-compatible standalone dataset. Then OTB could interpret the CRS specified from QGis.

As for specifying the output crs, it is usually not possible and depend on the particular application.
The default case is that OTB produces outputs in the same CRS as its input (say classification, segmentation, all pixel-based algorithms, etc).
Some apps are meant to change the crs (those who can do resampling typically ortho).

#4 Updated by Julien Malik over 7 years ago

I'm surprised about

SEXTANTE "forces" the layer to be opened in the same CRS as the input (quite logical...)

Is it 'always' or only when the layer does not have a CRS ?

#5 Updated by Victor Olaya over 7 years ago

  • Status changed from Open to Feedback

the problem is that, when you use a tiff+world file, you are using a format that cannot store CRS info...so there is no way the external app can know about it. We should think of some solution, like the one Julien propose. In the meantime, maybe I can add a warning notice, to tell users that the file is going to be generated but with a wrong CRS, so they should use something like gdal to fix it...

I'm surprised about

SEXTANTE "forces" the layer to be opened in the same CRS as the input (quite logical...)

Is it 'always' or only when the layer does not have a CRS ?

the output layer is asumed to be in the same CRS as the input one. that means that if OTB generates something based on a layer with WGS84, SEXTANTE assumes the result is also a WGS84. Maybe this behaviour should be changed for some cases. I just did it to avoid the CRS screen that always appears, which I find annoying, since in most cases with SEXTANTE you know the CRS, since it is the same as the input.

#6 Updated by Julien Malik over 7 years ago

- When the output file contains CRS information, it seems strange to me that sextante forces it to the input CRS, whatever it is. All modules doing reprojection become buggy (just tested gdalwarp, and when warping you don't get layers which superimpose well)

- The fact that sextante reuse the input CRS when the output file has no CRS info at all sounds like a good idea (I don't see in what other situation we could be).

Those 2 points are only related to how to handle the output of a module.

For the input side (tiff+wld file case) it can become a good mess : otb will generate as output a geotiff, and will use what gdal knows about the file, so it will burn a wgs84 crs into the output geotiff. screwed !
Any other idea than using a gdal vrt ?
Do you foresee any issue with other backends ? Seems like everyone is doing gdal->internal format conversion, so they should accept a vrt file...

#7 Updated by Victor Olaya over 7 years ago

hen the output file contains CRS information, it seems strange to me that sextante forces it to the input CRS, whatever it is. All modules doing reprojection become buggy (just tested gdalwarp, and when warping you don't get layers which superimpose well)

Right. I would like to tell QGIS when opening the layer something like "use the output layer CRS if the layer has it, otherwise use the input layer CRS (currently defined as the first CRS found in the input layers), and only show the CRS selection dialog is there is no CRS in the input layers...or no input layers at all)"

As far as I know what I am doing is something like "Use this CRS (defined from the inputs) and show the dialgo if this CRS is None". It works for most algorithms, but for those like gdalwarp that thange the CRS, is not the right way to go.

Can anyone help me to implement the above solution? I do not know much about how this is done in QGIS, and looking in the code of other plugins, I just found what is currently implemented.

#8 Updated by Giuseppe Sucameli over 7 years ago

Victor Olaya wrote:

I would like to tell QGIS when opening the layer something like "use the output layer CRS if the layer has it, otherwise use the input layer CRS (currently defined as the first CRS found in the input layers), and only show the CRS selection dialog is there is no CRS in the input layers...or no input layers at all)"

To get the CRS of the output file before adding it to QGis you can see at GdalTools_utils.py getRasterSRS() method. It executes gdalinfo to get that information, but I think could be easily done using the osgeo.gdal python module as well (I didn't investigate).

Can anyone help me to implement the above solution?

Let me know what other info you need to implement it or how I can help you.

#9 Updated by Victor Olaya over 7 years ago

While we think about a more global solution, there is an easy one for those modules like GDAL warp, that change the CRS. Before running an algorihtm, sextante analyzes the input and extracts the crs of the output (assuming that it will be the same), and puts it into the self.crs variable. But this variable can be changed in the processalgorithm method (which is called later), setting it to the real CRS output (in the case of gdalwarp we know it, since the user has entered it). This crs will be used later to open the layer

This should fix the problem of those algorithms (which, fortunately, are not many)

The word file problem seems a bit more difficult, though...

#10 Updated by Giovanni Manghi over 7 years ago

The word file problem seems a bit more difficult, though...

the same applies also to shapes without the .prj file but given manually the right CRS.

Victor, what about the v.out.ogr and r.out.gdal modules in Sextante (see my first comment): they always output shapes without the .prj and a normal tiff + wld. While by default the same modules in GRASS output a shape with .prj and a geotiff... seems a missing flag, do you want me to file a separate ticket?

#11 Updated by Filipe Dias about 6 years ago

Is this still true?

#12 Updated by Giovanni Manghi about 6 years ago

  • Status changed from Feedback to Open

I'm checking, I may have discovered the issue in the processing code.

#13 Updated by Giovanni Manghi over 5 years ago

  • Project changed from 78 to QGIS Application
  • Crashes QGIS or corrupts data set to No
  • Affected QGIS version set to 2.2.0
  • Category deleted (63)

#14 Updated by Giovanni Manghi over 5 years ago

  • Affected QGIS version changed from 2.2.0 to master
  • Category set to 94
  • Target version set to Future Release - High Priority

#15 Updated by Giovanni Manghi over 4 years ago

  • Category changed from 94 to Processing/Core

#16 Updated by Giovanni Manghi almost 3 years ago

  • Priority changed from High to Normal

#17 Updated by Giovanni Manghi over 2 years ago

  • Easy fix? set to No
  • Regression? set to No

#18 Updated by Giovanni Manghi 9 months ago

  • Status changed from Open to Closed
  • Resolution set to end of life

Also available in: Atom PDF