Plot windfield

[NicolasColombi]

Describe the bug
When defining centroids from -180 to 180 longitude, the plotting function only plots one very narrow longitude line.

To Reproduce

tc = TCTracks.from_ibtracs_netcdf(year_range=(2000,2003))
lon_min, lat_min, lon_max, lat_max = -180, -70, 180, 70
centr = Centroids.from_pnt_bounds(points_bounds=(lon_min, lat_min, lon_max, lat_max), res=1)
tc_haz = TropCyclone.from_tracks(tc, centroids=centr, ignore_distance_to_coast=100, store_windfields=True)
tc_haz.check()
tc_haz.plot_intensity(event=0)

centroids:

tracks:

Develop branch, python 3.9.18, Mac

[chahank]

Can you please confirm that this is related to the longitudes? What do the centroids look like? What if you choose -179.9, 179.9?
Please also try without storing the windfields in the cyclones just to be sure. Please also check what the intensity matrix looks like and this is as expected. Then we can find out what the issue might be.

[NicolasColombi]

(-179.9,179.9)

(-180,179)

storing windfields do not affect it (the plots in this comment are without storing windfields

[simonameiler]

I encountered the same issue. You can solve it by normalizing the longitude values from 0-360 before plotting. In climada.util.coordinates, there is a function called lon_normalize. I standardize my hazard object as follows:

from climada.util.coordinates import lon_normalize

def standardize_longitudes(hazard):
    """Convert longitudes from [-180, 180] to [0, 360) using lon_normalize()."""
        lons = hazard.centroids.lon.copy()
        lon_normalize(lons, center=180.0)
        lats = hazard.centroids.lat
        crs = hazard.centroids.crs
        hazard.centroids = Centroids(lon=lons, lat=lats, crs=crs)

If you think this is useful, I can create a pull request and add this function to hazard/base.py, for example. But with the util function, this may not be needed.

[simonameiler]

Update, I actually think this was bad advice. While it solved the plotting issue, longitudes from 0, 360 may create more conflict downstream. It seems like it may be a plotting issue to fix in Hazard.plot_intensity().

[NicolasColombi]

Interesting! I think ithe issue might be inutil.plot.geo_im_from_array() as

crs_epsg, _ = u_plot.get_transformation(self.centroids.geometry.crs) (which was my primary suspect)

seems to work fine, and the other functions keep passing arguments down to util.plot.geo_im_from_array(). And, plot.geo_im_from_array()is the only function that handles the coordinates extent...

To note, when I define centroids specifying a different crs (e.g crs=ccrs.Mercator())

centr = Centroids.from_pnt_bounds(points_bounds=(lon_min, lat_min, lon_max, lat_max), res=1, crs=ccrs.Mercator())

The the plot displays perfectly (with out world map) even with lon -180 to +180

I will take some time next week to fix that.

[NicolasColombi]

I might have found the culprit 😅 @simonameiler @chahank

proj_plot = ccrs.PlateCarree(central_longitude=0.5 * (xmin + xmax))

when central longitude is between -1 and 1 the issue arise.

the lines of code before

xmin, xmax = u_coord.lon_bounds()

returns xmin, xmax = -179,180 if the centroids span -180,180 hence: central longitude = 0.5 --> problem
Now, the question is: why is central longitude near 0 a problem ? 0 is even the default option of ccrs.PlateCarree().

As a test, I bypassed u_coord.lon_bounds() enforcing xmin, xmax = -180, 180 and central longitude = 1. Enforcing xmin, xmax = -178, 180 without manipulating central longitude is also fine, as central longitude will be computed as central_longitude=0.5 * (xmin + xmax) = 1. Here is the following plot for both cases (probably shifted by 1° in the first case?):

[chahank]

hmmm, so where does the error arise? It is still unclear to me. Since ccrs.PlateCarree(central_longitude=0.5) is allowed (is it?), this cannot be the line which causes the issue right?

[chahank]

In the documentation of the ccrs.PlateCarree there is a note that

# Set the threshold around 0.5 if the x max is 180.

This might be the problem.

The value 0.5 seems to be the default.

[NicolasColombi]

Agree, I am also confused. The issue must originate somewhere else, but it is triggered with those central values.

[chahank]

Have you seen my comment above about the documentation of ccrs? Does this explain it?

[NicolasColombi]

Have you seen my comment above about the documentation of ccrs? Does this explain it?

Yes yes I read through it, but I still don't understand.

What is this threshold ? the central longitude ?

[chahank]

Using LeChat:

The threshold argument you're referring to is likely related to the set_extent method or similar functionality in Cartopy when using the PlateCarree projection. This argument is used to control the granularity or resolution of the map features, such as coastlines or borders, that are displayed.

Here's a brief explanation of how the threshold might be used in this context:

• Threshold Value: The threshold value typically ranges between 0 and 1. A lower value (closer to 0) means higher resolution and more detailed features, while a higher value (closer to 1) means lower resolution and less detailed features.

• Setting the Threshold: When the threshold is set around 0.5, it means you are balancing between detail and performance. For example, if the x-axis maximum value is 180 degrees (which is typical for a global map in the Plate Carrée projection), setting the threshold to 0.5 would provide a moderate level of detail.

• Purpose: The purpose of adjusting the threshold is to optimize the rendering of map features. If you have a large map or are zoomed out, a higher threshold can reduce the amount of data rendered, improving performance. Conversely, if you are zoomed in or need detailed features, a lower threshold would be appropriate.