[gdal-dev] Reading interpolated values on DSM

[Javier Jimenez Shaw]

Hi all

Thanks for your answers

Just to get some values, the VRT was enough to get an idea. Thanks Jukka.
The questions was more like "this should be somewhere, and I do not find
it", but apparently "it was not there".
I see that GDALRasterInterpolateAtPoint could be useful (I am surprised it
was was not needed before). I will try to add it at some point.

Best regards,
Javier.

On Wed, 24 Apr 2024 at 15:16, Even Rouault <even.rouault at spatialys.com>
wrote:

>
> Le 24/04/2024 à 15:00, Michael Sumner a écrit :
>
> Or a grouping function that returned the cell index for neighbours and
> weighting that are involved in whatever calculation summary is wanted.
>
> That doesn't seem super user friendly, as users would still be left to do
> the raster value extraction and applying the weights, taking into account
> nodata, etc. Not trivial. What is the advantage of this compared to
> returning the interpolated value? The only one I see is to potentially save
> a bit of computation if you need to interpolate values at the same location
> in multiple bands, but the performance gain would probably be marginal (or
> if not, then a variant of the function dealing with multiple bands could be
> offered)
>
>
> Maybe the warper could return this as a starting point rather than doing
> the "task at hand". ?
>
> The warper code has indeed a "FilterFuncType
> GWKGetFilterFunc(GDALResampleAlg eResampleAlg)" method that returns a
> function that returns interpolation weights and int
> GWKGetFilterRadius(GDALResampleAlg eResampleAlg). The code in
> GDALRPCGetDEMHeight() has an interesting logic where it caches a window of
> interest around the first queried pixel so that subsequent queries in the
> neighbouroud can be honoured without going to RasterIO(). This
> substantially improves performance in the RPC case, in particular during
> reverse transformation where you use an iterative method and thus may need
> a lot of DEM extraction to compute a single point.
>
>
>
>
> On Wed, Apr 24, 2024 at 8:51 PM Even Rouault via gdal-dev <
> gdal-dev at lists.osgeo.org> wrote:
>
>> Hi,
>>
>> I guess this discussion, and past similar ones, calls for an enhancement.
>> A new API function, like CPLErr
>> GDALRasterInterpolateAtPoint(GDALRasterBandH, double dfPixel, double
>> dfLocation, GDALRIOResampleAlg eInterpolation, double *pdfValue), that
>> could be used by a new mode of gdallocationinfo. The GDALRPCGetDEMHeight()
>> function in alg/gdal_rpc.cpp is a plausible candidate implementation for
>> bilinear and bicubic (we could potentially restrict to that at the moment).
>>
>> Even
>> Le 24/04/2024 à 10:33, Javier Jimenez Shaw via gdal-dev a écrit :
>>
>> Hi
>>
>> I would like to read in QGIS or GDAL an interpolated value in a DSM
>> (well, actually it is a geoid model, but it is the same behaviour). See
>> that I do not want the pixel value, but the linear interpolation among the
>> neighbour pixels, assuming that the pixel value is in the center of the
>> pixel.
>> For instance, this file
>> https://www.isgeoid.polimi.it/Geoid/Asia/Japan/japan2000_g.html
>>
>> Is there any way to get it (without implementing the interpolation
>> myself)?
>> If I understood correctly gdallocationinfo is not interpolating, just
>> giving the pixel value.
>>
>> Thanks
>>
>> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
>>
>> _______________________________________________
>> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> -- http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
> --
> Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> Hobart, Australia
> e-mail: mdsumner at gmail.com
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240429/3ce9e311/attachment.htm>