Xyz2grd no longer attaching longitude and latitude

Hi all,
I am using xyz2grd to grid text files of remote sensing data, where the first two columns are longitude and latitude, and following columns contain different variables.

I’m using code that has previously worked just fine, but suddenly the latitude and longitude info is being lost and I can’t plot it as a netcdf4 anymore. There are ‘x’ and ‘y’ fields in the variable attributes (where there used to be ‘lon’ and ‘lat’) and as a result the images now plot in netCDF viewing programs upside down. Comparing “old” and “new” files the new ones no longer say they follow the COARDS convention. The GMT version is 6.3.0. I’m using Ubuntu 22.04

Example code:


gmt xyz2grd ${input}.asc -i,0,1,4 -G${input}.grd -I300e -R/-68.8/-63.1/43.1/46.2 -V

So far I have reinstalled GMT but am thinking maybe the issue stems from dependencies (e.g. versions of HDF5 or Netcdf) or my GMT setup. Figured I would post here as I’m not making headway. The input file (as a .txt) is attached as well as some .pngs of the Metadata.

A2021066162500.L2_SWIR_v3.txt (5.3 KB)

This should be -i0,1,4 but that’s not the soucre of the problem. The source is, the code is the same but the data is not. You have -I300e, that is an increment of 300 meters but your data points seem to have a separation of ~1 km.

And note xyz2grd is NOT a gridder. It does not grid text files. What it does is to reformat it and assumes data is already gridded, which I don’t know if it’s really the case.

Hey Joaquim,

Thanks for your response. I’ll update -i0,1,4. I had grabbed a random file small enough to share here but removed NA pixels - turns out the remaining pixels were separated at ~ 1km like you mention. Part of another image with better coverage is attached. A2021280172500.L2_SWIR_v3.txt (420 KB)

A bit of background getting to your second point - these are satellite images processed at approximately 250 m per pixel resolution, which I have been removing NA data and writing out to text file then applying xyz2grd to assign them to a 300m grid. Some have very little data or have gaps between pixels with available data (at swath edge, like in the one I originally shared).

And note xyz2grd is NOT a gridder . It does not grid text files . What it does is to reformat it and assumes data is already gridded, which I don’t know if it’s really the case.

Sorry I am a bit confused by this statement. Do you mean that xyz2grd is not appropriate for, for example, point data collected with a GPS (e.g. not regular)? Or do you mean that text files created from gridded data, like in my case, aren’t appropriate for “re-gridding” to 300 m?


Yes, that’s precisely the point. xyz2grd is NOT appropriate for that. See the introduction of its man page

xyz2grd reads one or more x, y, z or z tables and creates a binary grid file. xyz2grd will report if some of the nodes are not filled in with data. Such unconstrained nodes are set to a value specified by the user [Default is NaN]. Nodes with more than one value will be set to the mean value. As an option (using -Z), a 1-column z table may be read assuming all nodes are present (z tables can be organized in a number of formats, see -Z below.) Note: xyz2grd does not grid the data, it simply reformats existing data to a grid structure. For gridding, see surface, greenspline, nearneighbor, or triangulate.

What you want in your case is probably nearneighbor

On a more different (but much more friendly) option, see Aqua SST · RemoteS.jl

Thanks for confirming.

There is something going wrong with this function for me still, as the issue persists when using other old code and old data that I successfully gridded. The geolocation is getting lost, though the latitude and longitude are still there as attributes.



Don’t remember what GMT5 did but you must use -fg to tell that data is in geographical coords.

Thank you! At least now I know how to make this work with geographic data again!
I did not find this in the changelog so didn’t realize the difference with -fg between versions 5 and 6.