-
Notifications
You must be signed in to change notification settings - Fork 51
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
xy_coords
introduces unexpected (?) pixel shift
#68
Comments
Thanks for the great issue @maawoo. I don't think you're doing anything wrong here; this is probably a bug. Which version are you using, btw? 1) I noticed #60 hasn't been released yet and 2) #35 from >= 0.2.0 is slightly related (though I highly doubt relevant here). Would it be possible for you to try with One other thing to be aware of is that I believe rioxarray follows xarray conventions (rather than typical raster conventions) and expects coordinates to refer to pixel centers. So I'd think (but haven't tried) that |
Hi Gabe, Unfortunately the problem persists after installing from git and #60 doesn't fix it, which also means that I did the following quick test regarding rioxarray with
The output is still perfectly aligned afterwards, so I assume rioxarray/rasterio somehow handle the conversion between raster and xarray conventions internally. I would've been very suprised if not tbh. I think that the error lies somewhere here because there's no offset problem with |
Yup, something is definitely wrong with the I also don't have a ton of time to look into this, but hopefully I can next week. If you could provide a full copy-pasteable reproducer, that would help a ton. What's your |
No problem and as a user I'm always happy to contribute to projects that I have a personal interest in! You can find a stripped-down example scene here: I tested it with the following code, except that the asset href in the STAC Item needs to be changed to absolute to work with stackstac of course.
Hope that helps! |
I think I'm observing something that is related: |
@maawoo I'm pretty sure This is what I'm observing: xx.attrs['transform'], xx.rio.transform()
(Affine(10.0, 0.0, 499980.0,
0.0, -10.0, 9200020.0),
Affine(10.0, 0.0, 499980.0,
0.0, -10.0, 9200030.0)) which is consistent with your reports. But if I apply a fix: xx.y.data[:] = xx.y.data[:] - float(xx.resolution) then I get consistent output from
|
Hi all!
Either the shift in pixels that I have observed is actually unexpected and needs to somehow be adjusted in the
to_coords
function or I'm simply missing something or misunderstanding the concept behind geotransforms and it's only unexpected for me at the moment. Hope someone can help me out either way 🙂In the following screenshots, the colored image is always the original raster, while the greyscale image is always the one created with these lines of code:
Transform and projection of the raster:
'proj:transform': [10, 0, 399960, 0, -10, 52000020]
&'proj:epsg': 32632
(UTM 32N)xy_coords=False
xy_coords='center'
| pixel shift: 0, 1 (expected: 0.5, -0.5)xy_coords='topleft'
| pixel shift: -0.5, 0.5 (expected: 0, 0)As expected, no shift is observed in (1). Now with (2) and (3), I'm confused. My original raster is a COG following the usual raster conventions, e.g. being top left aligned. Therefore I'd assume that using the default as in (3) results in no pixel shift at all. I'd also assume that the pixels are shifted by 0.5 and -0.5 in x and y respectively when using 'center' as in (2).
Looking forward to hearing some other thoughts on this!
Cheers, Marco
The text was updated successfully, but these errors were encountered: