QGIS » QGIS Application

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

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

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

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 ?

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

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.

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.

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

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?

Is this still true?