[gdal-dev] Create big COG file (C++)

[Javier Jimenez Shaw]

Thanks Even.

So if I understand correctly, the steps would be:
 1- Create() the GTiff dataset (with a valid filename)
 2- write all the data with [many] RasterIO() calls
 3- close the dataset (to dump everything into disk)
 4- open the GTiff dataset in read mode
 5- CreateCopy() with COG driver (with in a different valid filename),
based on the dataset (opened in 1 or 4, see below)
 6- close COG file.
 7- optionally delete the GTiff file (if only COG is needed)

I am not sure if I need steps 3 and 4. If not, should I move step 5 between
1 and 2?

Looks like this duplicates used disk space, and takes time to write the
second time. Why is it needed? Is there any workaround to create the COG
directly?

Thank you. Regards.
Javier.

.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Mon, 14 Sep 2020 at 19:49, Even Rouault <even.rouault at spatialys.com>
wrote:

> Javier,
>
>
>
> > I want to create a big (I mean bigger than my RAM size) COG file in C++
>
> > with GDAL 3.1.
>
> > COG driver does not have the "Create()" method, but "CreateCopy()". I am
>
> > not sure how I have to do it. Should I Create() first the dataset with
> the
>
> > MEM driver, write on it, and then call the CreateCopy with the COG
> driver?
>
> > (by the way, before closing the MEM dataset? Is then everything copied?)
>
>
>
> You shouldn't use the MEM driver for datasets that can't fit entirely into
> RAM.
>
> MEM datasets are temporary. Once you've closed the dataset handle, it is
> destroyed. So if you use a MEM dataset, you must pass to CreateCopy() the
> handle you got when calling Create() for the MEM dataset
>
>
>
> > Or should I use a normal GTiff dataset, and then CreateCopy() with
>
> > the COG driver?
>
>
>
> Yes
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200914/08436788/attachment.html>