raster reconstruct in 0-360 format

[nickywright]

Hi,

I'm still getting issues with reconstructing rasters in 0-360 format (previously reported in #289),

Example is here

v1. By default (if I don't specify the extent), when supplying a an xarray dataset to gplately.Raster it just assumes my extent is [-180, 180, -90, 90], rather than looking at the longitudes at all. So my reconstruction is all offset by 180° relative to my grid... v2. If I supply extent=[0, 360, -90, 90], it only reconstructs the 0-180 portion. But this is reconstructed in the correct hemisphere. So the result is similar to what I used to get in #289 v3. If I supply extent=[0, 360, -90, 90] and realign=True, it works.

I don't quite understand, why is realign needed if I am explicitly supplying an extent here? Or can this be an internal workaround in GPlately somehow ([0, 360, -90, 90] is still a global grid!) FYI, realign isn't listed as a parameter here

[michaelchin]

Hi @jcannon-gplates,

Do you have time right now to look into this issue? Setting realign=True was a temporary workaround for the problem in https://github.com/GPlates/gplately/issues/289. The Raster class may need significant overhaul to support input data from various sources, such as xarray object, netcdf file, rasterio, numpy, geopandas, etc. This was the reason that I had created https://github.com/GPlates/gplately/issues/310 to track the improvement, but never got time to do it.

I am currently working on the GPlates app and it takes much longer than I thought. I need to focus on it for now to catch up the progress. If you don't have time either right now, I can do it after the GPlates app task is under control. Right now I am a bit panicked dealing with the app.

[jcannon-gplates]

Do you have time right now to look into this issue? Setting realign=True was a temporary workaround for the problem in #289.

That should be fine - I'll take a look next week (and mark this for the 2.1 release).

It does seem that internally GPlately/pyGPlates would like to use [-180,180] (instead of [0,360]) - for example, when reconstructing. So I might try something like Ben's comment. And then maybe we won't have to specify realign=True when the input is [0,360].

The Raster class may need significant overhaul to support input data from various sources, such as xarray object, netcdf file, rasterio, numpy, geopandas, etc.

That does sound like it's needed. Hopefully for this issue can be resolved by looking at the min/max of the lons read from the input source.

[jcannon-gplates]

@nickywright, does it work if you just specify realign=True without specifying extent=[0, 360, -90, 90] ? Because that's what worked in #289.

[nickywright]

@nickywright, does it work if you just specify realign=True without specifying extent=[0, 360, -90, 90] ? Because that's what worked in #289.

Nope doesn't work anymore, I've updated my notebook here so you can see.

[jcannon-gplates]

Thanks for that, and for providing the notebook to test with.

[michaelchin]

For #289, it was a netcdf file. In this case, I think the code run into a different path. Maybe the grid got flipped?????

[jcannon-gplates]

Yeah, I had wondered what that flip comment. Then I saw that the _realign_grid function says "flips the array if the latitudinal coordinates are decreasing". So I'm guessing the grid in question doesn't decrease. Besides, it looks like read_netcdf_grid also calls _realign_grid, so I guess it should be consistent (whether using a file or numpy array): https://github.com/GPlates/gplately/blob/5e32f045a9d4ca660278f54d94a623765b1ef6d3/gplately/grids.py#L297-L299

In any case, I'll take a look soon 👍