QGIS » QGIS Application

That's ostrich' strategy. Instead of fixing a bug let's just find a justification for not fixing it.

You are wrong. Re-read my words, I said "as far as I know/understand", this means two things: I may be wrong, and that anyway this reflects how qgis works to my knowledge, it doesn't means that it is perfect or it is that way by design.

Feel free to do something, like submitting patches or supporting the qgis development, the way you think is better for you and the project.

If this were your choice, qgis should either refuse displaying the layer or at least warn that the display will be wrong.

For rasters that are completely missing any CRS info? Sounds reasonable, then see above.

But then please note that a significant part of the work with Sextante aiming to run R & OTB commands and display the results
should better be halted to search for another visualizer.

Why? Anything that enters qgis/sextante has to have crs info, as geotiff or with a worldfile, then the output also will have a proper crs.

In Remote Sensing we deal with the images for a long while before they get georeferenced (as in the case of the example). So this is a huge deal or not depending on whether you want qgis to be useful for the RS community or not.

ok, but how other software packages do show in the right place (overlapping other layers with a proper crs) those images if they have any kind of crs info (internal or worldfile)? This should be the starting point to eventually make qgis work better in such cases.

...and the image gets the by default CRS as in any other case in qgis. And you get wrong coordinates for the input image that complicates using the
list of points in another software to, for example, apply geometric methods that are not currently implemented in qgis.

According to your statement "qgis is not supposed/ready to handle rasters that are completely missing any georefercing", #4377
would not be a bug: the entire georeferencing tool should be removed.

you are mixing up things and my words. The georeferencer can certainly be fixed and made better (but this does not means that at this moment is broken), so again feel free to contribute improve it.

I think it's better you make the worldfile to fit your expectations, I'm not sure of what you mean by a proper worldfile and it's just a matter of
writing few lines in a text file.

I know how a worldfile is made, and as far as I remember they work fine in QGIS.

Excuses, I don't know where to look for the definitions of the different levels and, in my naivety, thought
that placing a raster layer in a wrong place should have a high priority.

All infos you need are in the wiki.

I think you are complicating this discussion far too much.

surprise, I think the same thing about you.

qgis reports a wrong origin and places the image in a wrong origin for raster
layers (at least geotif, have not tested with other formats) that do not have CRS information.

Unless I missed something, the info is wrong only when loading an image that has not any kind of crs info (ex: geotiff or tif+worldfile) that anyway as we already know it is not a thing that at this moment qgis is supposed to do.

The sample tif image and some screenshots were attached in the first post. Do yo mean the vector layer?. I attach it now,

the attached vector is also missing the CRS (it misses the prj file), so maybe this is what you mean: if you load any kind of layer missing the crs info, do you expect anyway to overlap?

Yes, because the raster layer is also missing the crs info. The vector
layer is derived by sampling the raster layer, thus they should overlap.
Both layers are missing the CRS information, but the vector layer
is displayed correctly while the raster layer is shifted.

Giovanni Manghi wrote:

But then please note that a significant part of the work with Sextante aiming to run R & OTB commands and display the results
should better be halted to search for another visualizer.

Why? Anything that enters qgis/sextante has to have crs info, as geotiff or with a worldfile, then the output also will have a proper crs.

Not true. Many OTB functions that work through Sextante are aimed to raster layers with no CRS info because there is a significant part
of the processing that has to be done before the image is georeferenced.

In Remote Sensing we deal with the images for a long while before they get georeferenced (as in the case of the example). So this is a huge deal or not depending on whether you want qgis to be useful for the RS community or not.

ok, but how other software packages do show in the right place (overlapping other layers with a proper crs) those images if they have any kind of crs info (internal or worldfile)? This should be the starting point to eventually make qgis work better in such cases.

Simply by reading the gdal info correctly. The problem here is that while gdalinfo reports a 0,0 origin, qgis reports a 0, 1023.74 origin and displays the
image with such shifted origin.

...and the image gets the by default CRS as in any other case in qgis. And you get wrong coordinates for the input image that complicates using the
list of points in another software to, for example, apply geometric methods that are not currently implemented in qgis.

According to your statement "qgis is not supposed/ready to handle rasters that are completely missing any georefercing", #4377
would not be a bug: the entire georeferencing tool should be removed.

you are mixing up things and my words. The georeferencer can certainly be fixed and made better (but this does not means that at this moment is broken), so again feel free to contribute improve it.

We rather keep the discussion on #4377 in its own place.

I think it's better you make the worldfile to fit your expectations, I'm not sure of what you mean by a proper worldfile and it's just a matter of
writing few lines in a text file.

I know how a worldfile is made, and as far as I remember they work fine in QGIS.

Then it will be very simple for you to test. I do not understand what you asked me to test with the world file, so better
you do it yourself.

I think you are complicating this discussion far too much.

surprise, I think the same thing about you.

No, what I'm saying is very simple and short: While gdalinfo reports a 0,0 origin, qgis reports a 0, 1023.74 origin and displays the image with such a shift. Apparently,
this problem only happens for raster files with no CRS information.

qgis reports a wrong origin and places the image in a wrong origin for raster
layers (at least geotif, have not tested with other formats) that do not have CRS information.

Unless I missed something, the info is wrong only when loading an image that has not any kind of crs info (ex: geotiff or tif+worldfile) that anyway as we already know it is not a thing that at this moment qgis is supposed to do.

Why is not supposed to do it? Where is that statement? Again, in that case, qgis should either refuse displaying the layer or at least warn the user. Who is "we" in
"we already know"? Certainly not the general user. And again, note a
part of the applications meant to be run through sextante will not be displayed by qgis under those conditions.

alobo - wrote:

Yes, because the raster layer is also missing the crs info. The vector
layer is derived by sampling the raster layer, thus they should overlap.
Both layers are missing the CRS information, but the vector layer
is displayed correctly while the raster layer is shifted.

So let me resume:

when loading two layers (vectors or rasters) both missing any CRS information, do you expect to overlap, right?

they should be aligned by the center? or one of the corners?

And what about if you add another similar layer, but from another completely different region, where it should be placed?

Giovanni Manghi wrote:

alobo - wrote:

Yes, because the raster layer is also missing the crs info. The vector
layer is derived by sampling the raster layer, thus they should overlap.
Both layers are missing the CRS information, but the vector layer
is displayed correctly while the raster layer is shifted.

So let me resume:

when loading two layers (vectors or rasters) both missing any CRS information, do you expect to overlap, right?

if they have the same geometry, yes.

they should be aligned by the center? or one of the corners?

They should be displayed according to the coordinates of the corner reported by gdalinfo, as R (see test.jpeg) or Grass
(see testgrass.jpeg) do.

And what about if you add another similar layer, but from another completely different region, where it should be placed?

They should be displayed according to the corner coordinates reported by gdalinfo. They are not georeferenced, so if we
have a set of images acquired with the same sensor (thus the same geometry), they all will overlap despite not having been acquired in the same
scene. Once they become georeferenced, they will be located according to their new geographic coordinates.
For example, all Hyperion images Level L1R (no georeferencing) of the world will overlap, while images level L1T (terrain corrected) will be displayed at their
correct geographic places. if I have an algorithm detecting bad columns o bad pixels in L1R and make a vector of those, this vector should
overlap all L1R images. As those are sensor-related problems, detecting those problems in images of, i.e., the Lybian desert, can be applied to correct
images in i.e., the Amazon. Once these problems are solved, the images are georeferenced.

Oh now I see that you are referring to TTC2770v2_0_1otb.tif, that you haven't attached...

Bottom line is that, as far as I understand how qgis works, you must file anyway also a feature request ticket because qgis does expect the user to load a layer with proper georeferencing (and this looks like pretty much a fact to me). The fact that the origin looks shifted in qgis it seems not really important at this stage because before it would be needed to tell qgis how to handle such layers.