Skip to content

GSoC 09 Weekly Report #4: 12/06 – 19/06

June 20, 2009

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

gdalinfo --formats

getting this:

captura_wktraster

UPDATE 2009/09/16:

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

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?

Advertisements
5 Comments leave one →
  1. June 24, 2009 11:29 am

    Jorge,

    A couple of comments:

    1. The spelling of PostGIS is PostGIS not Postgis, PostgreSQL not Postgresql, also it’s “WKT Raster” but not “WKT raster”. It’s fairly important.

    2. What sibling list you mean? Link it to specific place in GDAL/OGR code from Trac source browser and it will be easier to find out.

    3. Check this for svn:ignore (http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.3)

    4. What you mean as “I only compile the WKTRaster code”?
    The WKT Raster has one direct dependency (PostGIS) and one indirect (GEOS). The WKT Raster requires very recent version of PostGIS (I suggest to grap source from its SVN trunk) and that recent version of PostGIS requires very recent version of GEOS (again, GEOS from SVN trunk). I build, run tests and install both of them every morning without problems – it’s easy.

    I am going to put a post about WKT Raster installation, hopefully tonight.
    Feel free to ask if you have any questions.

  2. June 25, 2009 3:22 am

    Hello Mateusz,

    I answer your comments

    1. Ok. I try to spell always in the way you like, but I’ll correct the errors. I’m sorry for this.

    2. Oh, it was a minor doubt. I was trying to understand what kind of information has a GDALOpenInfo object, and when it’s created, and I read the concept “sibling list” in this file http://trac.osgeo.org/gdal/browser/trunk/gdal/gcore/gdalopeninfo.cpp (line 127). But I think it’s not really important now.

    3. I checked that page to create my ignore list, actually. Many thanks for the link, anyway

    4. Maybe it’s not clear. I checked out PostGIS and GEOS from SVN. Then, I compiled them and installed them. I did the same with the WKT Raster extension, of course. When I said “I only compile the WKTRaster code” I was talking about GDAL WKT Raster driver’s code. And this is a doubt: I can do ./configure – make – make install with GDAL sources every time that I make a change (in my driver’s code). But I can simply re-build the driver’s code with each change, not the whole GDAL library. Is correct?

    I’m very interesting in your post, I’ll keep an eye on your blog 🙂

    Thanks for your comments!

  3. June 25, 2009 12:01 pm

    I never do “make install” when I want to test and debug GDAL or GDAL-based programs.
    Just configure your environment the way GDAL library can be found by your program.

    Here are my configuration scripts I use:

    http://mateusz.loskot.net/tmp/gdal/gdal.source
    http://mateusz.loskot.net/tmp/gdal/config.sh

  4. Even Rouault permalink
    June 29, 2009 12:09 am

    The sibling list is just a list of files in the same directory of the file to be GDALOpen’ed. This was an attempt to improve performance for file-based drivers that need to read auxiliary info in files next to the main file (for example a .tfw file for a TIFF file). See http://trac.osgeo.org/gdal/wiki/rfc11_fastidentify. (I’d note that it can actually decrease performance when there’s a huge number of files in the directory). The sibling list may be safely NULL and in your use case, you don’t have to care at all about it since you’re developing a server based driver ;-). You just need poOpenInfo->pszFilename and perhaps the poOpenInfo->eAccess flag if you want to distinguish read-only/read-write

    CPL/VSI functions : some of them are documented at http://gdal.org/files.html.

    I’ve looked a bit at your repository. One stylistic remark : avoid using tabulation character. Use spaces instead. In WKTRasterDataset::GetGeoTransform(), you can remove the code for if (padfTransform == NULL) : it’s illegal to call GetGeoTransform() with padfTransform == NULL and your code would crash anyway 😉
    In

  5. June 29, 2009 3:51 am

    Thanks for the info Even!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: