Re: [gdal-dev] Bumping TileDB minimum from 2.7 to 2.15 for GDAL 3.9?
Le 25/04/2024 à 00:39, Andrew C Aitchison via gdal-dev a écrit : On Wed, 24 Apr 2024, Even Rouault via gdal-dev wrote: A future TileDB version will remove various deprecated API that the GDAL TileDB driver currently uses. https://github.com/OSGeo/gdal/pull/9725 migrates away from those deprecated APIs, but that causes the minimum requirement from TileDB to go from 2.7 to 2.15. It would probably be wise to backport this cleanup in the 3.9 branch, so that it doesn't cause later packaging issues, typically with conda-forge builds as soon as they will package the future TileDB version removing the deprecated APIs, which might occur during the GDAL 3.9.x life cycle. Does anyone see an issue in doing this bump? The few distributions I'm aware of shipping TileDB meet the >= 2.15 requirement: Conda-forge already ships TileDB 2.22, Alpine Linux is a 2.17.4. https://docs.tiledb.com/main/how-to/installation/building-from-source suggests that TileDB requires a C++20 compiler. Is that an issue ? I don't think so. For now, the public C++ API of TileDB even of the latest versions is C++17 compatible. And to build TileDB itself, digging into their CMakeLists.txt, I see that up to 2.16, it used to be C++17 compatible, so it should be possible to have a GDAL build against TileDB with only a C++17 compiler by sticking to TileDB 2.15 or 2.16. The requirement for C++20 to build TileDB has started with 2.17.0. On a somewhat related note, I should not that the upcoming version of Poppler (2024.05) requires a C++20 compiler, including to include its headers from GDAL (as we use a somewhat semi-public/semi-private C++ API, not much care is done on it to be usable). So some of our dependencies might require C++20 in their latest versions. And before we switched GDAL to require C++17 we already had to force C++17 for some drivers like TileDB, Poppler, PDFIUM. Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bumping TileDB minimum from 2.7 to 2.15 for GDAL 3.9?
On Wed, 24 Apr 2024, Even Rouault via gdal-dev wrote: A future TileDB version will remove various deprecated API that the GDAL TileDB driver currently uses. https://github.com/OSGeo/gdal/pull/9725 migrates away from those deprecated APIs, but that causes the minimum requirement from TileDB to go from 2.7 to 2.15. It would probably be wise to backport this cleanup in the 3.9 branch, so that it doesn't cause later packaging issues, typically with conda-forge builds as soon as they will package the future TileDB version removing the deprecated APIs, which might occur during the GDAL 3.9.x life cycle. Does anyone see an issue in doing this bump? The few distributions I'm aware of shipping TileDB meet the >= 2.15 requirement: Conda-forge already ships TileDB 2.22, Alpine Linux is a 2.17.4. https://docs.tiledb.com/main/how-to/installation/building-from-source suggests that TileDB requires a C++20 compiler. Is that an issue ? -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bumping TileDB minimum from 2.7 to 2.15 for GDAL 3.9?
Not knowing any detail about TileDB, I find good this bump in GDAL 3.9.0, that is already changing many other dependency minimum versions. On Wed, 24 Apr 2024 at 20:45, Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > A future TileDB version will remove various deprecated API that the GDAL > TileDB driver currently uses. https://github.com/OSGeo/gdal/pull/9725 > migrates away from those deprecated APIs, but that causes the minimum > requirement from TileDB to go from 2.7 to 2.15. It would probably be > wise to backport this cleanup in the 3.9 branch, so that it doesn't > cause later packaging issues, typically with conda-forge builds as soon > as they will package the future TileDB version removing the deprecated > APIs, which might occur during the GDAL 3.9.x life cycle. Does anyone > see an issue in doing this bump? The few distributions I'm aware of > shipping TileDB meet the >= 2.15 requirement: Conda-forge already ships > TileDB 2.22, Alpine Linux is a 2.17.4. > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Bumping TileDB minimum from 2.7 to 2.15 for GDAL 3.9?
Hi, A future TileDB version will remove various deprecated API that the GDAL TileDB driver currently uses. https://github.com/OSGeo/gdal/pull/9725 migrates away from those deprecated APIs, but that causes the minimum requirement from TileDB to go from 2.7 to 2.15. It would probably be wise to backport this cleanup in the 3.9 branch, so that it doesn't cause later packaging issues, typically with conda-forge builds as soon as they will package the future TileDB version removing the deprecated APIs, which might occur during the GDAL 3.9.x life cycle. Does anyone see an issue in doing this bump? The few distributions I'm aware of shipping TileDB meet the >= 2.15 requirement: Conda-forge already ships TileDB 2.22, Alpine Linux is a 2.17.4. Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading interpolated values on DSM
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 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 list gdal-dev@lists.osgeo.org https://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@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Michael Sumner Software and Database Engineer Australian Antarctic Division Hobart, Australia e-mail: mdsum...@gmail.com -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading interpolated values on DSM
Or a grouping function that returned the cell index for neighbours and weighting that are involved in whatever calculation summary is wanted. Maybe the warper could return this as a starting point rather than doing the "task at hand". ? On Wed, Apr 24, 2024 at 8:51 PM Even Rouault via gdal-dev < gdal-dev@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@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@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Michael Sumner Software and Database Engineer Australian Antarctic Division Hobart, Australia e-mail: mdsum...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading interpolated values on DSM
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 list gdal-dev@lists.osgeo.org https://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@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading interpolated values on DSM
Hi Javier I regularly use PROJ for that. It’s a bit of a hack but it works. Here’s a demonstration using the DVR90_2023 geoid. The lower left grid point is at (7,53.5) and the horizontal grid spacing is 0.1 degree. Below I first get the actual grid values at two adjacent grid points and then lastly interpolate the grid value in between those two points: echo 7 53.5 | cct -t0 -z0 +proj=vgridshift +grids=dk_sdfi_dvr90_2023.tif +multiplier=1 7.00 53.50 40.27200. (fire-dev) C:\Temp\fire\obs-beregning>echo 7 53.51 | cct -t0 -z0 +proj=vgridshift +grids=dk_sdfi_dvr90_2023.tif +multiplier=1 7.00 53.51 40.25900. (fire-dev) C:\Temp\fire\obs-beregning>echo 7 53.505 | cct -t0 -z0 +proj=vgridshift +grids=dk_sdfi_dvr90_2023.tif +multiplier=1 7.00 53.505000 40.26550. The grid values are obviously the third component of the output coordinates. /Kristian From: gdal-dev On Behalf Of Javier Jimenez Shaw via gdal-dev Sent: 24. april 2024 10:33 To: gdal dev Subject: [gdal-dev] Reading interpolated values on DSM 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 list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading interpolated values on DSM
Hi, How about making a VRT file with doubled pixel size by applying your favourite resampling method and then making a query from the VRT file with gdallocationinfo? -Jukka Rahkonen- Lähettäjä: gdal-dev Puolesta Javier Jimenez Shaw via gdal-dev Lähetetty: keskiviikko 24. huhtikuuta 2024 11.33 Vastaanottaja: gdal dev Aihe: [gdal-dev] Reading interpolated values on DSM 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 list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading interpolated values on DSM
I think it is not QGIS 3 compatible. It is very old (yes, I tried to install from the zip,.. and failed) On Wed, 24 Apr 2024 at 10:51, Paul Harwood wrote: > If you want to do it in QGIS ... > > https://plugins.qgis.org/plugins/rasterinterpolation/ > > On Wed, 24 Apr 2024, 09:33 Javier Jimenez Shaw via gdal-dev, < > gdal-dev@lists.osgeo.org> wrote: > >> 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 list >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading interpolated values on DSM
If you want to do it in QGIS ... https://plugins.qgis.org/plugins/rasterinterpolation/ On Wed, 24 Apr 2024, 09:33 Javier Jimenez Shaw via gdal-dev, < gdal-dev@lists.osgeo.org> wrote: > 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 list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Reading interpolated values on DSM
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 list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
