Deciding on default grid registration and grid type for PyGMT

PyGMT v0.1.1 assumes that input xarray.DataArray grids are gridline registered ( GMT_GRID_NODE_REG ), and of cartesian type ( GMT_GRID_IS_CARTESIAN ). Currrently we are working on allowing for either pixel/gridline registered and cartesian/geographic grids at #476, by changing the virtualfile_from_grid mechanism. But we’ll need to decide on a good default going forward (i.e. for v0.2.0).

GMT defaults to using gridline registration (aka data values represent top left corner of pixel), and PyGMT currently follows this convention. Should we change it to pixel registration which is what xarray follows? Place your vote below!

Registration type:

  • Gridline (left image)
  • Pixel (right image)

0 voters

Grid type:

  • Cartesian, i.e. GMT_GRID_IS_CARTESIAN
  • Geographic, i.e. GMT_GRID_IS_GEO

0 voters

Feel free to leave your comments below, or on Github at https://github.com/GenericMappingTools/pygmt/issues/487 where there will be some more context.

GMT does not have a default for grid or pixel registration. It simply handles both of them. Some modules, like surface do have the gridline default but GMT in itself doesn’t. Can’t PyGMT do the same? If xarrays need to be pixel-registered just make sure they are and no resample is needed. Just do the same as grdedit -T does.

Just to clarify, this is a non-issue for users passing in a NetCDF filename directly into PyGMT, in that case, the gridline/pixel registration type will be handled like normal in GMT.

It is when we’re creating a virtualfile grid from an xarray object via the C API, and passing that onto GMT, that we have to explicitly state whether it is gridline or pixel registered. For some cases, where an xarray is created from a NetCDF file, we can detect whether an xarray is gridline/pixel registered (and we’ve almost got this automated method sorted).

The default then would really only affect users creating their grid from scratch in pure Python, as there won’t be a NetCDF ‘source’ we can run grdinfo on to detect the registration type. In this case, would it be better to assume that the user created a pixel registered or gridline registered grid?

In case you find it useful, that’s how I deal with it in Julia

1 Like

Thanks for linking to that! I was thinking of using a boolean flag as well last night (instead of the current implementation which parses a string like reg="g" or reg="p"). Will take a closer look later, what does HDR stand for?

HDR is an header vector (explained in the function)
HDR 1x9 [xmin xmax ymin ymax zmin zmax reg xinc yinc] header descriptor
We have this guy since the very early grdreader in Matlab tens of years ago.