pyresample icon indicating copy to clipboard operation
pyresample copied to clipboard

Negative pixel size if area is flipped

Open sfinkens opened this issue 2 years ago • 8 comments

Code Sample, a minimal, complete, and verifiable piece of code

from pyresample.geometry import AreaDefinition

area_def = AreaDefinition(
    "test",
    "test",
    "test",
    projection={"proj": "geos", "lon_0": 0, "h": 35785831.0},
    width=2,
    height=2,
    area_extent=[1, 1, -1, -1]   # flipped, upper right corner is S-E
)
area_def.pixel_size_x

Problem description

The pixel_size_x/y attribute of a flipped area is negative.

Expected Output

1.0

Actual Result, Traceback if applicable

-1.0

Versions of Python, package at hand and relevant dependencies

pyresample-1.22.3

sfinkens avatar May 11 '22 17:05 sfinkens

Any idea if this ever worked? I think I changed something recently about this so I want to double check that I didn't break this.

djhoese avatar May 11 '22 17:05 djhoese

I noticed it in the past, but then forgot to file an issue. Just tried with an old env that has pyresample-1.18.0, same issue.

sfinkens avatar May 11 '22 18:05 sfinkens

I've always thought that is as expected...

pnuu avatar May 12 '22 05:05 pnuu

If we think of pixel_size as step_size then a negative value is indeed expected.

gerritholl avatar May 12 '22 07:05 gerritholl

Good point. Although I think of it as resolution. The documentation also describes it as width and height of the pixel. We could keep the current behavior in a step_size property?

sfinkens avatar May 12 '22 07:05 sfinkens

Also geotiffs show the pixel size as negative for example for y-direction of geos projection where north is up.

pnuu avatar May 12 '22 08:05 pnuu

I've used the idea of a negative pixel size in the past in Polar2Grid, but don't use it anymore and assume it will be positive. I'm not against forcing it to be positive if it makes everyone happy, but I don't think we need to retain the +/- value in a step_size, at least I don't think so. We'd have to make sure that various calculations that might use pixel size don't assume it can be negative which would make "fixing" the pixel size break this other code.

djhoese avatar May 12 '22 12:05 djhoese

Oh, obviously I forgot about this issue... Now that I read your arguments again, I agree to keep the current behaviour. Maybe I'll just add a note the documentation that pixel size can be negative in certain situations.

sfinkens avatar Dec 07 '23 07:12 sfinkens