Work done

This week I was out for 3 days due to an unexpected personal issue. So, I didn’t finish all my planned tasks. Now, I’m making up these days. Anyway, the work done was:

  • Start the RASTER_COLUMNS table update with the information fetched from database.
  • Create a patch for gdal2wktraster script and send it to the PostGIS track as new ticket, instead of sending the modified script to the list. I’ve delayed the out-db raster support in GDAL because is under development in WKTRaster, and I tried to help in this task.
  • Correct errors. I’ve introduced some changes, like erase the overviews from SUBDATASETS metadata domain, fix some memory leaks due to sharing objects between Datasets and overviews, add NBITS metadata information related with each RasterBand, and some other little fixes.
  • Test overviews support with gdal_translate.
  • Start block caching

Thanks to people from gdal and postgis lists (like Frank, Tamas, Mateusz, Even…) I solved the two doubts I had the last week:

DOUBT: What happens if the bb of a block offset in IReadBlock doesn’t match any real block? Missing-tiles raster?
RESPONSE: In this case, the buffer must be filled with nodata values

DOUBT: Where should I fit WKTRaster “16BF” datatype? In GDT_Uint16?, in a single float?
RESPONSE: It fits in a 32bits float. Anyway, this datatype is proposed to be deleted from WKTRaster:

UPDATE: I forgot to add the graphical proof of overviews running:

Here, the file utm.tif, used for testing (reduced to fit into the blog’ space). Look at the dimensions, at bottom left corner.


Here, the result after loading the image in PostgreSQL with gdal2wktraster, using a block size of 100x100px and converting the image to TIFF format again using gdal_translate with an output size of 50%


Planned work for next week

This week must be the week to end the tasks related with regular_blocking support, and to start with non-regular blocking arrangements.

Problems found

One important problem was to share a PGconn object between one dataset and its overviews (datasets too). The connection is released in the class destructor, but only the general dataset should do it, as the connection owner. Finally, I solved the situation thanks to suggestions from Even Rouault and Mateusz Loskot, by using a boolean var to detect if it’s the dataset or one of its overviews.