Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Better handling of anti-meridian cases

Aperta
  • Qualcosa non va?
#627 5 commenti 0 reazioni 1 assegnatario Vedi su GitHub

@djhoese ci sta già lavorando.

Dal 23/10/2024.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

bug enhancement

Sorry for not following the template, but I'm not sure this fits.

Currently the DynamicAreaDefinition.freeze method has an antimeridian_mode keyword argument that I added for handling cases where the provided lon/lats cross the anti-meridian (-180/180 in lonlat space). This kwarg can be:

1 .modify_crs (default): Add a +pm=180 to shift the prime meridian of the projection to 180 degrees. This means the extents surround 0 instead of being discontinuous over -180/180. See downsides below.
2. modify_extents: Mess with extents of lon/lat projections so the longitudes are 0-360 instead of a -180-180 range. See downsides below.
3. global_extents: Change the extents to be the entire globe. Theoretically if resampling handling this properly you get a full globe with the input data split into two pieces.

The modify_crs is problematic because many tools don't respect +pm=180 (see https://proj.org/en/9.5/usage/projections.html#prime-meridian). The modify_extents is a problem because it seems some (all?) of our resamplers can't handle longitudes outside the -180-180 range either deliberately filtering them as invalid (kdtree nearest neighbor does this) or suffering from PROJ transformation automatically wrapping longitudes to the -180-180 range.

For these reasons I propose a few important changes:

  1. Deprecate modify_exents and combine it with modify_crs, but at the same time change modify_crs to use +lon_wrap=180 instead of +pm=180. See https://proj.org/en/9.5/usage/projections.html#longitude-wrapping which I think is what we normally want anyway.
  2. Change kdtree resamplers to only filter lon/lats >=1e30 instead of doing the full -180/180 and -90/90 validation. This would allow PROJ to handle the wrapping.
  3. Update EWA resampler to use pyproj's Transformer class and be more explicit about convert lon/lats to the target projection. This should hopefully gracefully use the +lon_wrap=180 which I don't think is working right now.

Questions:

  • What does get_lonlats for an area return that has +lon_wrap=180. Should it return 0-360 or -180/180 even though they wouldn't be contiguous? In the past I think we updated this method to assert that lon/lats are always -180/180.
  • Edit: Does +pm=180 get us anything (is it useful to us or our users) that +lon_wrap=180 doesn't?
Lingua principale
Python
Stelle
388
Fork
103
Merge medio
7g 4h
PR unite (30g)
4

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pytroll/pyresample

Tutte le issue di pytroll/pyresample

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.