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!
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?
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.
Hi! I am having a weird new issue that I think is related to this discussion.
I have a text file that I converted to netCDF. It plots fine as the text file, but the netCDF gives me the following error: “grdimage [WARNING]: Guessing of registration in conflict between x and y, using gridline”
These are the commands I performed on my data.
pygmt.xyz2grd(data=‘data.txt’, spacing=.05, region=[-127.5, -65, 20, 50], outgrid=‘data.nc’)
Please let me know if you have any ideas about which (likely missing) parameter is causing the registration error. Figure.grdimage does not have a registration option, so I’m not sure where to start. Thanks for your help!
@weiji14 Using the pixel registration gives the error “xyz2grd [WARNING]: 1157 values gave bad indices: Pixel vs Gridline registration confusion?” so I reverted to gridline registration.
I realized I was using the wrong function … Sorry for the trouble.
I haven’t worked with this dataset for awhile and forget this version uses an irregular grid.
Everything works perfectly when I triangulate the data. Thanks for your help!