[gdal-dev] Re: [SoC] GDAL WKTRaster weekly report #9

[Jorge Arévalo]

Hello,

On Fri, Jul 31, 2009 at 8:41 PM, Even
Rouault<even.rouault at mines-paris.org> wrote:
> Le Friday 31 July 2009 18:04:14 Jorge Arévalo, vous avez écrit :
>>
>> Yes, it's not commited yet. But, where do you store the overviews? The
>> overviews are a kind of datasets exposed via GetOverview method and
>> based in the first level dataset, right? So, when I'm creating a
>> dataset, I can create overviews as other datasets that are stored in
>> an array in the more general dataset. Then, they are like "children
>> datasets". Is this point incorrect?
>
> You can have a look at the GTiff driver (but just a quick one as it is an
> horrible complex thing. I don't want you to have an headache ;-)), for an
> example of a driver that support its own overviews, especially
> GTiffRasterBand::GetOverviewCount() and GTiffRasterBand::GetOverview() in
> frmts/gtiff/geotiff.cpp

Yes, I've read the GTiff code several times and I think it's really
complex, but very useful too. Many thanks for the tip Even :-)

>
> It works exactly the way you've described : the base dataset has an array of
> children datasets, one for each overview level. It is responsible for
> instanciating them and destroying them in its own destructor.
>

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?

>>
>> > Is there any mechanism currently for creating overviews?  How have
>> > you been testing overviews?
>>
>> gdal2wktraster script is able to construct overview tables, as Mateusz
>> said. I tested the code by creating an overview of a dataset (with
>> gdal2wktraster script) and reading it with gdalinfo as metadata of
>> SUBDATASETS domain. I need more testing at this point, to somehow read
>> each overview and maybe store it as out-db raster. I'm not sure on how
>> to test it properly.
>
> If you support overviews with the standard GetOverview() mechanism of a raster
> band, you should be able to display them by using any GDAL based viewer
> (qgis, openev) and zooming out the raster by the appropriate factor. Or
> gdal_translate -outsize 50% 50% in_dataset out_ovr_2.tif, will just extract
> the overview of factor 2.
>

OK. Successfully tested :-). But I've found a mistake.

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?

Thanks in advance
Best regards,
Jorge


>>
>> > Under DOUBTs you ask what happens if the bounding box of a block
>> > does not match any real block in the table, what should happen.  In this
>> > case IReadBlock() should fill the buffer with the nodata value (zero if
>> > nodata is not set).
>>
>> Ok, understood.
>>
>> > You also mention a doubt about how to handle the 16BF type, which is
>> > apparently "16-bit float".  I have never seen such a thing before and I'm
>> > not sure why it is part of the WKTRaster specification. I would suggest
>> > removing it.
>> >
>> > However, if we wanted to support it (and you could figure out what it
>> > actually is), then I think it would be most appropriate to transform it
>> > into a 32bit float as it is read in IReadBlock().  Presumably the full
>> > range of a 16bit float could not be kept in a 16 bit integer.
>>
>> Actually, now I transform it in a 32bit float
>>
>> > Likewise, 1BB, 2BUI, and 4BUI values (if supported) should be
>> > translated on the fly into GDT_Byte values.  However, there is a special
>> > NBITS metadata item in the IMAGE_STRUCTURE metadata domain that can
>> > be set in these cases to represent the special nature of the image data.
>> > Likewise there is a special value to indicate signed eight bit integers.
>> > These values are discussed in:
>> >
>> >  http://trac.osgeo.org/gdal/wiki/rfc14_imagestructure
>> >
>> > However, I consider implementation of these esoteric types optional given
>> > the relatively limited time remaining.
>>
>> Ok. Added to my todo list.
>>
>>
>> Thanks Frank
>>
>> Best regards,
>> Jorge
>>
>> > Best regards,
>> > --
>> > ---------------------------------------+---------------------------------
>> >----- I set the clouds in motion - turn up   | Frank Warmerdam,
>> > warmerdam at pobox.com
>> > light and sound - activate the windows | http://pobox.com/~warmerdam
>> > and watch the world go round - Rush    | Geospatial Programmer for Rent
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>