First week of “real” coding. First of all, I decided the GDAL version to work with, and I took a snapshot. It was the 1.7.0. In the first weekly report, I said that I checked out the last version of GDAL from repository, but I need to export one version (not check it out), to import it into my own repository.

The second thing was to create my own repository. That’s it:

Once I had a repository, I created the skel of the driver. This is:

  • WKTRaster.h: Main header file for the driver, with class definitions
  • WKTRasterDataset.cpp : Driver’s dataset
  • WKTRasterRasterband.cpp : Driver’s raster band
  • GNUMakefile: Makefile to build the driver under GNU enviroments
  • Makefile to build the driver under Windows enviroments, with Visual C
  • install, todo, readme: Typical information files

The code is still a skel, only. But enough to test a configure-make-make install cycle. So, I did it. Following the instructions of install file (taken from PGCHIP driver), I added my driver to the supported ones and executed

gdalinfo --formats

getting this:


UPDATE 2009/09/16:

If you get the message

gdalinfo: error while loading shared libraries: cannot open shared
object file: No such file or directory

while executing gdalinfo, the fastest solution is to add the directory (/usr/local/lib) to /etc/ and execute

sudo ldconfig

After this, you will execute any gdal-related program without problems.

I’m currently working on writing code, of course.

Things to remark

  1. The connection string syntax. I chose this:
    PG:"dbname='db_name' host='host' port='port' user='user' passwd='passwd'
    table='table_name' where='sql_where'"

    Apart from table and where options, the rest of the string is prepared to be directly passed to PGconnectdb function. The sql_where part will be pased to the server in the same way. No SQL processing here. Anyway, this decision is opened to comments.

  2. I’ve installed my own trac software to manage the bugs and tasks of this project, without interfering in the official GDAL trac

Doubts and problems

  • How should be the “perfect” method header comment? I couldn’t find a recommendation for this. When I start a method, I use to put this information in the header comment:
    • Name of the method
    • What does the method do
    • Inputs
    • Outputs

    Is enough? Maybe I can put the external libraries used, for example. Suggestions?

  • What is exactly a sibiling list? I read this concept in the OGR datasource code, but I didn’t find further information, and I think it may be important
  • CPL/VSI functions. Used for portability and allowing virtual file systems. Really interesting. I would like to have further information on them, because are widely used in the GDAL code, and maybe I should learn how to use them properly
  • Ignore list.  I created an ignore list with the command svn propedit svn:ignore.  Then, I added patterns to be ignored, one per line. Is it the correct way?
  • Compiling. I only compile the WKTRaster code. Is it correct? When I have a working code, I compile the whole library again.

Next week

I will be focused in the code to connect with database, and check if the table selected has a raster column.  I will create code for testing, of course.

Related with this, I would need some test data. Where could I find it?