I'm wondering is that the expected since it looks like the raster cell
value is determined by point locations. I would have expected a much
more smooth surface without any obvious circular shapes. To me it looks
like the computation was not done cell by cell but instead point by point.
What am I missing or misunderstanding?
ps: This tool is in group 'Raster analysis'. In my opinion it should be
in a group 'Point data tools' or something.
[gdal-dev] Fwd: Re: Wondering gdal_grid moving average interpolation
Interesting result. It looks roughly right: pixels with only dark points in their surrounding window are dark and pixels with only light point in the window are light.
However, it does seem that the legend used for pixels uses different interval values than that for the pixels. Otherwise it would be hard to explain why pixels that have only a single point in their window do not have the same color as that point.
The second thing that is concerning is the ragged edge of the apparent circles. It suggests that the distance calculation is not accurate. It shouldn't be more than a pixel off.
You will always have these awkward edge effects in moving window analysis. However it can be reduced by 1) using a window radius considerably larger than the distance between points. 2) use a distance weighted kernel (my weapon of choice).
Re: Wondering gdal_grid moving average interpolation
On 13.03.2018 09:54, Rutger wrote:
> It looks alright to me. The moving average algorithm searches (for each
> pixel) for points within the specified radius, and then averages the values
> of all those points.
> "gdal_grid" also supports inverse distance or linear interpolation if you
> want a more smooth result.
> It is perhaps surprising that QGIS only exposes a small subset of
> gdal_grid's capabilities.
Yes, you're right, I was just a bit flabbergasted that it looked so bad.
There's nothing to make it smooth.
The QGIS "bindings" to GDAL are a bit limited, perhaps there hasn't been
much interest in expanding them from the initial commits(?). I believe
there are also some things that could be thought as bugs - I did a PR(*)
a year ago which was not merged (but the issue has been fixed since) - I
think a good review of them would be useful. I fixed one issue
recently(**) but it is a rather slow process.