[gdal-dev] Re: PHP bindings

[Even Rouault]

Mike,

> Hello again,
> 
> I think I stumbled upon the part that was tripping up the methods I was
> using with the php_osr.so library.  Posted at http://pastebin.com/SXKKfe6v
> is a patch that should work on both 1.8.0, and the trunk svn.  It adds the
> missing CSL typemap, and corrects the OGRErr related typemaps to ensure
> that it only returns results for non-zero error responses.
> 

I'm not sure if/when someone will act on this, but you should perhaps open a 
GDAL Trac ticket and attach your patch there so it is kept in a safer place 
than a pastebin that will be lost in a few days/weeks.

> The patch also includes changes to the GNUmakefile in the swig/php folder
> to make sure that the gdal libs are linked, and that all of the php
> modules are compiles instead of just php_gdal.so (not sure if this is
> fully necessary, but I was having trouble with linking before).
> 
> In addition to this, I had to substitute all instances of
> 'zend_error_noreturn' that swig inserts into the *_wrap.cpp files with
> 'zend_error'...I don't know if this is just specific to my environment, but
> the best I could determine from searching online is that more recent
> versions of PHP no longer define zend_error_noreturn, yet swig still uses
> it.  It seems that zend_error is a sufficient substitute (without this, I
> would find that when the module raised errors, it would cause a segfault
> instead of actually producing a descriptive error in Apache/PHP).

Perhaps something to share with the swig mailing list ?

> 
> If this patch is applied and gdal is configured/compiled with the
> '--with-php' option, then when swig/php/php_osr.so is installed and loaded
> into the PHP environment, the following PHP script will work as expected:
> 
> <?php
> include("/path/to/gdal/swig/php/osr.php");
> $sr = new SpatialReference();
> $sr->ImportFromProj4('+init=epsg:4326');
> echo $sr->ExportToProj4();
> ?>
> 
> This is about as far as I can get for now - looking through typemaps_php.i,
> I think I see plenty of stuff that still needs fixing/updating.  There are
> also function name conflicts if I try to load php_gdal.so and/or
> php_ogr.so.  I think that's out of my league, however.  Hopefully this is
> enough to peak the interest of someone who has a little more familarity
> with c/swig/php, and we could get a more fully-supported set of PHP
> bindings.
> 
> Best regards,
> Mike
> 
> On Thursday, February 24, 2011 19:45:16 Mike Leahy wrote:
> > Hello all,
> > 
> > To keep this topic somewhat alive, I might note that I can identify that
> > at the very least, php_osr.so works in some ways, but not how I would
> > expect compared with the same bindings in other languages.
> > 
> > I also found that at least one typemap was needed in typemaps_php.i:
> > 
> > /* Almost same as %typemap(out) char **options */
> > /* but we CSLDestroy the char** pointer at the end */
> > %typemap(out) char **CSL
> > {
> > 
> >   /* %typemap(out) char ** -> ( string ) */
> >   char **stringarray = $1;
> >   if ( stringarray == NULL ) {
> >   
> >     RETVAL_NULL();
> >   
> >   }
> >   else {
> >   
> >     int len = CSLCount( stringarray );
> >     array_init($result);
> >     for ( int i = 0; i < len; ++i, ++stringarray ) {
> >     
> >       add_next_index_string( $result, *stringarray, 1 );
> >     
> >     }
> >   
> >   }
> >   CSLDestroy($1);
> > 
> > }
> > 
> > This seems to have removed the warnings about that being missing when I
> > compile the osr library (I'm continuing to focus just on this binding as
> > a simple case).
> > 
> > In terms of actually using php_osr.so, I can successfully import a proj4
> > string, and export that to WKT using the '__str__' method:
> > 
> > <?php
> > $sr = new_SpatialReference();
> > SpatialReference_ImportFromProj4($sr,'+init=epsg:4326');
> > echo SpatialReference___str__($sr);
> > ?>
> > 
> > I would expect that the last line would be equivalent to
> > "SpatialReference_ExportToWkt($sr);", but that isn't the case...I'm still
> > getting zero, which I think stems from the fact that the data type for
> > the ExportToWkt (and similar functions) in osr.i is of the type
> > 'OGRErr', and this is what is getting returned in PHP instead of the
> > desired wkt output.
> > 
> > I'm guessing that there's a difference in how swig interprets these
> > functions when compiling in PHP versus the other languages.  In osr.i, I
> > added an extra declaration that mimics how the __str__ function works,
> > but returns proj4 strings.  It looks like this:
> > 
> > %newobject ExportToProj4Test;
> > 
> >   char *ExportToProj4Test() {
> >   
> >     char *buf = 0;
> >     OSRExportToProj4( self, &buf );
> >     return buf;
> >   
> >   }
> > 
> > After compiling that, the following code will successfully return a Proj4
> > string:
> > 
> > <?php
> > $sr = new_SpatialReference();
> > SpatialReference_ImportFromProj4($sr,'+init=epsg:4326');
> > echo SpatialReference_ExportToProj4Test($sr);
> > ?>
> > 
> > So...with this in mind, does this suggest that PHP will essentially need
> > an entirely rewritten list of functions?  I would hope that there's a
> > more effective way to go about it this, and that I'm just looking at
> > this with my relatively novice perspective.
> > 
> > Best regards,
> > Mike