Hello Even, 2009/8/2 Even Rouault <[email protected]>: > Le Sunday 02 August 2009 13:56:52 Jorge Arévalo, vous avez écrit : >> Hello, >> So, I can create an array of children datasets to store the overviews, >> but I shouldn't add the datasets as metatada under SUBDATASETS domain. >> Is it right? > > Right, you shouldn't use SUBDATASETS for reporting overviews.
Thanks for confirmation > >> >> When I create an overview (a children dataset), its properties are the >> same properties of the general dataset (his parent), apart from pixel >> size, table name and column_name, of course. The problem appears when >> sharing the PGconn object. >> >> My code looks like this: >> >> poDS->overview[i]->hPGconn = poDS->hPGconn >> >> If each dataset's destructor (from the general one and from the >> overviews) calls PQfinish over the same object, I get a segmentation >> fault after the first time, of course. So, I have 2 options: >> - Detect when a connection object has been freed, and perform only one >> call. How should I do this? >> - Don't share the PGconn object. Should I declare a static PGconn pointer? >> >> What is the best approach? > > A static variable is rarely a good idea. It would prevent the user from having > multiple WKTRaster datasets opened at the same time. > > Perhaps you should add a bBase flag to the WKTRasterDataset object (like it's > done for the GTiffDataset). You set it to TRUE for the base dataset and to > FALSE for the overviews. Then you only call PQfinish() if it is TRUE. Very good idea. I think I'll use it. Many thanks! > > (I've no looked at what your code does recently, so the following remark might > be irrelevant. But if you use transactions and their life cycle runs accross > several calls of GDAL API, using the same connection object for the base > dataset and its overviews might not be appropriate, or might require having a > flag to know that a transaction is opened. --> You want to be able to mix > RasterIO() calls on the base dataset and overviews) > No, I'm not using transactions just now, but I'll take it into account if I use them. Thanks again. Best regards, Jorge _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
