I was using GDALRasterizeLayersBuf from gdal_alg.h from the C++ API (on
Linux, version lilbgdal-dev 2.4.0). In the documentation for the different
rasterize functions, it is stated that:
"The output raster may be of any GDAL supported datatype, though currently
internally the burning is done eithe
>
> --> this returns a GDALDatasetH. You need to GDALClose() it before
> being able to reopen it, so that its content gets flushed to storage.
>
Well, I have to say I'm impressed. Everything works smoothly. Thank you
for your help :)
Julien Osman.
__
I have solved my curl problem and now it works.
You are a great community, thank you
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/g
On jeudi 1 octobre 2020 23:19:22 CEST Javier Jimenez Shaw wrote:
> Hi
>
> I have seen that XMP is not copied into a COG file when CreateCopy is
> called. Actually it is also not done in CreateCopy of GTiff.
> Does it make sense to include the copy of this metadata automatically? And
> what about o
According to `gdalinfo`, MOD021KM (and MYD021KM for the matter), list
identical bands under two different subdatasets (SDSes).
For example, SDS 3 (see `gdalinfo`'s report on it
https://gitlab.com/thermopolis/public/code/-/snippets/2021406)
and SDS 24 (see `gdalinfo`'s report on it
https://gitlab.
