[gdal-dev] Re: PHP bindings

[Mike Leahy]

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.

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).

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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110228/ae24c778/attachment.html