I think I found a major bug in the assignment of TC track points to land or ocean, which occurs at least in tc_track_synth. This seems to be related to how the land geom is retrieved from the track extents. However I am afraid this might have implications elsewhere, too.

In essence, in climada.hazard.tc_tracks_synth, land_geom is retrieved using:

extent = tracks.get_extent()
land_geom = climada.util.coordinates.get_land_geometry(
    extent=extent, resolution=10
)

However, if I read global data as follows

tracks = TCTracks.from_ibtracs_netcdf(
  provider = 'usa'
)
extent = tracks.get_extent()
land_geom = u_coord.get_land_geometry(
    extent=extent, resolution=10
)

Then I get the following value for extent: (31.4, 373.6, -44.800000762939455, 70.79999694824218), and the following for land_geom:

Hence the extent of the land geometry that is being loaded only covers longitude from 31.4 to 180 degrees East. Looks like the underlying function get_land_geometry does not handle spherical coordinates.

The implication is that any track westward of 31.4 degrees East will be said not to be over land. The issue probably won't show up if I had loaded data only for the, e.g. North Atlantic basin, because then the extent would probably be within the [-180, +180] longitude range.

This is a major issue and it might apply to many other code instances than just for the TC synthetic tracks generation. My questions are then:

• Is there a way for get_land_geometry to properly account for spherical coordinates? That would be the easiest way to fix. If not, then at least the function should raise an error if longitude values are outside of [-180, +180] (and since we're at it let's also make sure latitude never goes outside of [-90,90], although this case is very unlikely).
• Where else in the code might this issue lead to mistakes, too?