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: http://www.gis4free.org/gdal_wktraster.
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.vc: 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
If you get the message
gdalinfo: error while loading shared libraries: libgdal.so: cannot open shared object file: No such file or directory
while executing gdalinfo, the fastest solution is to add the libgdal.so directory (/usr/local/lib) to /etc/ld.so.conf and execute
After this, you will execute any gdal-related program without problems.
I’m currently working on writing code, of course.
Things to remark
- 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.
- 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
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.
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?