Skip to content
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

Resolution and area extent inconsistency in creating AreaDefinition #2755

Open
akasom89 opened this issue Mar 9, 2024 · 1 comment
Open

Comments

@akasom89
Copy link

akasom89 commented Mar 9, 2024

I got an issue which i think is not possible right now.

Description:

When creating an AreaDefinition in the code snippet provided, it's evident that the resolution and area_extent parameters should ideally match to ensure consistency in defining the area. However, in cases where these parameters do not initially align, it appears that the resolution is adjusted to accommodate the given area extent.

area_def = create_area_def('my_area', proj,
resolution=xr.DataArray([2000, 2000], attrs={"units": "meters"}),
area_extent= [-120, -40, 0, 30], units='degrees')

WARNING:root:shape found from radius and resolution does not contain only integers: (11068.715659379493, 8348.961809495519)
Rounding shape to (11069, 8349) and resolution from (2000.0, 2000.0) meters to (1999.9908514781455, 1999.948623973167) meters

Expected Behavior:

Ideally, the behavior should allow for flexibility in adjusting the area_extent to match the specified resolution, without altering the resolution itself. This would enable users to maintain a fixed resolution while dynamically adjusting the area extent as needed.

Proposed Solution:

To address this issue, it would be beneficial to introduce a mechanism that prioritizes keeping the resolution fixed and dynamically adjusts the area_extent to align with the specified resolution. This would provide users with more control and flexibility in defining the area while maintaining the desired resolution.

@djhoese
Copy link
Member

djhoese commented Mar 10, 2024

I would consider this more of a pyresample issue than a satpy issue, but you've already written it so let's just keep it here.

I'm not sure how I feel about this request. Overall I think my opinion is that if you want exact numbers then use exact calculations and don't specify any parameters in non-native projection units. I'm also torn on the preference for preserving resolution versus preserving extents versus providing yet another keyword argument to choose which to preserve.

On one hand the existing behavior is good for people who want to have their various images all cover the exact same outer extents regardless of resolution. This mimics how AreaDefinitions are defined already where extents and number of pixels are specified, not pixel resolutions.

On the other hand, it is cruel to let the user specify the resolution and then basically ignore it. As you say, if someone wants to compare resolutions of the same data they'd really like the resolution to be consistent...but also in that case if the extents aren't the same and aligned to the pixel resolution then how well does that work and how useful would it be. If the extent had to be adjusted to maintain the resolution, in which way does it get adjusted? Does it always expand or shrink to the upper-right? What if I created an area by specifying a center point to create_area_def? In that case I would want it to be equally expanded/shrunk both left/right and top/bottom.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants