However, I noticed that this operation interpolates the entire rectangular grid, including areas with null values (-9999) that are not part of the valid data area. How can I restrict the interpolation in grdfill so that it does not fill cells outside the valid data area? I want to prevent cells with -9999 outside the area of interest from being interpolated.
I have also tried using the “Bicubic Spline” interpolation with the following command:
but for some reason it doesn’t work, only the “Nearest Neighbor” interpolation works, I have tried in Linux and I have the same result. Could you tell me where I’m going wrong?
Your grid contains mostly NaN values (94.7%). The grdfill command is typically used when needing to fill small holes inside of a grid.
Your particular grid consists of an outline of a closed body, with a few “islands” inside the closed body. Are you hoping to fill the interior of the closed body with interpolated values?
To do that, and to ignore cells outside the closed body, you might need to mask out the exterior, after the fact. In other words, let grdfill fill wherever it wants, but as a last step, mask out everything outside the closed body.
In your second example, the grdfill command appears twice. That likely won’t work.
To GMT developers: I get a segmentation fault error when trying to issue:
gmt grdfill test.tif -L and gmt grdfill test.tif -Lp
Maybe its just the nature of the grid, in this case (consisting mostly as NaN values).
I have tools in Miro to deal with this, but are a bit too manual. In the fig above the rectangles delimit the detected holes, and we can fill them but unfortunately I did not add an option to do them all at once. One needs to do it one by one.
does GMT gallery example 15 not show a practical way to grid such data, using nearneighbor (or surface) for filling the gaps?
Would be interested to learn in case there are any problems/limitations doing this with multibeam data.
EDIT I read the topic over and over again and finally grasped that the topic starter tried nearneighbor and it worked while grdfill did not (for whatever reason). Why not using with nearneigbor for this task, is there a problem? Explanations are much appreciated as always.
Thank you very much for answering John. Indeed, I made a mistake when writing in the post, but I still have the same result when correcting the command line, It only works with “Nearest Neighbor” (I have only tried with nearest neighbor and bicubic spline).
Hi Joaquim, thanks for replying. It would be great (if you can) if you incorporate that tool in Mirone. I just tested it and as you said, it can only be done one by one. Curiously, it only works for me to fill with surface and sea, I try to fill with cubic and linear, but it doesn’t allow me to do it.
Yes, one can use psmask to create a no-holes polygon and later use it to mask a grid created with surface, but this is a separate issue that to fill holes of a, possibly 3rd party, grid. And involve quite some steps more as well.
I did not think about psmask, rather the preceding steps of grid creation out of (multibeam) sonar data using gmt nearneighbor (or gmt surface), especially preceded with blockmedian or other filtering and maybe bad data removal. This is also a multi step process as far as I can understand, like, one also needs to correct for waves, tide.
the data in the topic do not look particularly thoroughly processed. I think there are likely artifacts present (like strange shapes/changes if depths visible on a larger grdimage plot).
If you have many like this to process and current Mirone is not a solution an alternative is to create the grids (MB-System?) with zeros in place of NaNs, use grdfill (it will work when grids don’t have those very large areas with NaNs (see the issue that I posted the link above)) and at the end reset the NaNs that were disguised as zeros.
EDIT: Forget, silly idea that relied on the ability to tell apart the good NaNs (the holes) from those on the background
As far as I can understand, nearneighbor should be able do approximately this, I mean telling apart the holes from the background NaN planes, depending on the search geometry like shown it the Session Three — GMT 6.5.0 documentation, like, -N is 4, -E is NaN by default. Neighbors in fewer than all 4 sectors would imply the NaN plane. A sane search radius, around 1/2 of the size of the biggest hole, would eliminate the holes.
it appears from the grdfill docs that gmt grdfill ... -An ... can be provided with a search radius for the nearest neighbor algo expressed as a number of grid cells, e.g. gmt grdfill ... -An1 ... for a searching radius of 1 grid cell. Otherwise it fills the whole grid, it appears like grid size becomes the search raduis. Can be -An10 etc.
One thing that I did not look into in detail, is that the data seems to be expanded by the selected number of points, like gmt grdfill -An10 makes the resulting data track “thicker”. It appears gmt grdfill does not allow for a fine tuning of the nearest neighbor algo like gmt nearneighbor does, especially that -N option that restricts filling to the points having neighbors in all 4 sectors within the search radius.
