-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shifted raster: origin in qgis different than that reported by gdalinfo #16997
Comments
Author Name: alobo - (alobo -) Confirmed on ubuntu 1.9.0-Master 18a04b5
|
Author Name: Giovanni Manghi (@gioman) To me seems just a GUI glitch and not a serious bug, but I may be wrong obviously. The fact that a non georefereced raster is loaded in QGIS as wgs84 it just depends on how your qgis is configured in settings -> options -> crs This "issue" then seems to surface only when you (force to) load a non georeferenced raster, because if you load a geotiff or a tiff + worldfile it seems what you see in qgis metadata and gdalinfo is the same. Can you confirm?
|
Author Name: alobo - (alobo -)
Yes, I think. If you take the time to check the coordinates on the display, you'll see that
which is wrong, because the raster does not have georeferencing. Qgis, like, for example grass, should let the user just leave the image in an arbitrary
If we use this as tfw: the position in qgis is the same as with no tfw, but the positions in R and grass are shifted. with sizes 1 and 1: So this just proofs that in qgis the tfw overrides the geoti header, but this does not solve the problem. Agus
|
Author Name: Giovanni Manghi (@gioman)
are we speaking about a raster images that:
correct? If yes, then as far as I know/understand in qgis is not supposed/ready to handle rasters that are completely missing any georefercing, regardless of what the user can force on load, or regardless what crs is given by qgis (by settings -> options -> crs). Probably qgis would better handle this cases in a different way (you may want to file a feature request) but imho it is not a huge deal, layers are supposed to have a proper georeferencing (?).
feature request?
it is not absurd, is a bug (see #14309) but this does not stops the georefencer to work as expected: when it asks the crs just click "cancel".
so, your raster does not goes in the right place with a proper worldfile? Can you please attach sample data, the previous attachments are confusing to me. Thanks. PS
|
Author Name: alobo - (alobo -) Giovanni Manghi wrote:
That's ostrich' strategy. Instead of fixing a bug let's just find a justification for not fixing it.
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.
According to your statement "qgis is not supposed/ready to handle rasters that are completely missing any georefercing", #14309
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
The sample tif image and some screenshots were attached in the first post. Do yo mean the vector layer?. I attach it now,
Excuses, I don't know where to look for the definitions of the different levels and, in my naivety, thought I think you are complicating this discussion far too much. qgis reports a wrong origin and places the image in a wrong origin for raster
|
Author Name: Giovanni Manghi (@gioman)
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.
For rasters that are completely missing any CRS info? Sounds reasonable, then see above.
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.
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.
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 know how a worldfile is made, and as far as I remember they work fine in QGIS.
All infos you need are in the wiki.
surprise, I think the same thing about you.
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. |
Author Name: Giovanni Manghi (@gioman)
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? |
Author Name: alobo - (alobo -) Yes, because the raster layer is also missing the crs info. The vector |
Author Name: alobo - (alobo -) Giovanni Manghi wrote:
Not true. Many OTB functions that work through Sextante are aimed to raster layers with no CRS info because there is a significant part
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
We rather keep the discussion on #14309 in its own place.
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
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,
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 |
Author Name: Giovanni Manghi (@gioman) alobo - wrote:
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? |
Author Name: alobo - (alobo -) Giovanni Manghi wrote:
if they have the same geometry, yes.
They should be displayed according to the coordinates of the corner reported by gdalinfo, as R (see test.jpeg) or Grass
They should be displayed according to the corner coordinates reported by gdalinfo. They are not georeferenced, so if we |
Author Name: Giovanni Manghi (@gioman) With GDAL 1.10 and a copy if QGIS compiled against GDAL 1.10 (as it is now fpr qgis master on Windows and Ubuntu), the response is the same, no origin (see below and attached image); giovanni@sibirica$ gdalinfo TTC2770v2_0_1.tif
|
Author Name: Giovanni Manghi (@gioman) Oh now I see that you are referring to TTC2770v2_0_1otb.tif, that you haven't attached... |
Author Name: Giovanni Manghi (@gioman) 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. |
Author Name: Paolo Cavallini (@pcav)
|
Author Name: Giovanni Manghi (@gioman) closing for lack of feedback and because the general notion that layers that are not georeferenced should align is not valid, at least in qgis.
|
Author Name: alobo - (alobo -)
Original Redmine Issue: 8178
Affected QGIS version: master
Redmine category:rasters
After processing a raster layer (TTC2770v2_0_1.tif) with OTB (TTC2770v2_0_1otb.tif), I get a shifted display of
the new layer in Qgis.
While gdalinfo reports a 0,0 origin, qgis reports a 0, 1023.74 origin.
The origin of the original file is reported as 0,0 by both gdalinfo and qgis
See attached screenshot.
Also, while gdalinfo reports no projection (because there is none) Qgis reports
longlat wgs84 in the Metadata (not only in General).
Tested on qgis 1.8 (on Ubuntu) and 2.0-dev clf8230 (on Mac)
Agus
The text was updated successfully, but these errors were encountered: