pytroll / pyresample

Geospatial image resampling in Python
http://pyresample.readthedocs.org
GNU Lesser General Public License v3.0
346 stars 94 forks source link

Negative pixel size if area is flipped #433

Open sfinkens opened 2 years ago

sfinkens commented 2 years ago

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

djhoese commented 2 years ago

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.

sfinkens commented 2 years ago

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.

pnuu commented 2 years ago

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

gerritholl commented 2 years ago

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

sfinkens commented 2 years ago

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?

pnuu commented 2 years ago

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

djhoese commented 2 years ago

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.

sfinkens commented 9 months ago

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.