[gdal-dev] Re: PHP bindings

[Mike Leahy]

Hello all,

To keep this topic somewhat alive, I might note that I can identify that 
php_osr.so works partially 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, which I 
determined by looking at the Python typemaps:

/* 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 library for 
now).

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);
?>

This suggests to me that the underlying objects work as expected.  However, I 
would expect that the last line would be equivalent to using 
"SpatialReference_ExportToWkt($sr);", but that isn't the case.  When using 
that function, I still get 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.

My guess is that there's a difference in how swig is interpreting these 
functions when compiling for 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 that substitute those that are currently 
there now?  I would hope that there's a more efficient/effective way to go about 
this, and that I'm just looking at this with my relatively novice perspective.

Best regards,
Mike

> Hi Even,
> 
> It looks like adding '-L../../.libs -lgdal' did the trick to ensure
> that the libraries are linked.  E.g.,:
> 
> swig -Wall -I../include -I../include/php -I../include/php/docs \
> 
>    -I/scratch2/gdal/gdal-1.8.0 -c++ -php -o osr_wrap.cpp
>    ../include/osr.i
> 
> g++ -L../../.libs -lgdal -I../../port -I../../gcore -I../../alg \
> 
>    -I../../ogr `php-config --includes` -fpic -c osr_wrap.cpp
> 
> gcc -L../../.libs -lgdal -shared osr_wrap.o -o php_osr.so
> 
> After doing that, ldd shows a respectable number of linked libraries,
> inlcuding libgdal.  I can load php_osr.so without trouble, same as
> before. But php_gdal.so module now reports several conflicts when it is
> loaded (e.g., duplicate functions named 'rmdir', 'mkdir', 'unlink',
> etc...), so there's a bit more to fix up in that area.
> 
> However, I'm sticking with php_osr.so as a simpler test case to start
> off. As an example, I would expect the PHP code below should create a
> spatial reference object for the wgs84 long/lat referenc system based
> on the epsg number 4326, and export the equivalent WKT text, but I'm
> still getting a zero integer returned:
> 
> php code:
> 
> $sr = new_SpatialReference();
> var_dump($sr);
> var_dump(SpatialReference_ImportFromProj4($sr,'+init=epsg:3587'));
> var_dump(SpatialReference_ExportToWkt($sr));
> 
> outputs:
> 
> "resource(3) of type (_p_OSRSpatialReferenceShadow) int(0) int(0)"
> 
> In python, I can do the following:
> 
> srs = osgeo.osr.SpatialReference()
> srs.ImportFromProj4('+init=epsg:3587')
> print srs.ExportToWkt()
> 
> And I get the following output:
> 
> "GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,2
> 98 .2
> 57223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]"
> 
> So maybe I just don't know how to interact with the spatial reference
> object within the PHP environment.  Any further suggestions here?
> 
> Regards,
> Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110224/fc90cb13/attachment-0001.html