[gdal-dev] Re: Java wrapper of GDAL/OGR application

Lucena, Ivan ivan.lucena at pmldnet.com
Tue May 4 10:15:46 EDT 2010

Even, Miguel,

Even Rouault wrote:
> Miguel,
> I took the liberty to CC the gdal-dev mailing list as other may have the same 
> questions/interests or ideas to help you.
> The migration of applications to Java was mainly an easy way to test the 
> GDAL/OGR Java API, but not an aim per se. So I've no real plans to migrate 
> gdal_grid and gdal_contour at the moment, but we'd be happy to get your 
> contribution.

That was also my intension when I wrote the GDAL's Proximity algorithm in Java, to test the the 
feasibility of writing this kind of raster processing in Java/GDAL.


And the performance is surprisingly good...

> The key to migrate an application is to make sure that the core API used by 
> each utility are available by SWIG bindings.
> * For gdal_grid, the core API is GDALGridCreate(), which hasn't been mapped to 
> SWIG bindings. 
> The C prototype of the function :
> CPLErr
> GDALGridCreate( GDALGridAlgorithm eAlgorithm, const void *poOptions,
>                 GUInt32 nPoints,
>                 const double *padfX, const double *padfY, const double *padfZ,
>                 double dfXMin, double dfXMax, double dfYMin, double dfYMax,
>                 GUInt32 nXSize, GUInt32 nYSize, GDALDataType eType, void 
> *pData,
>                 GDALProgressFunc pfnProgress, void *pProgressArg );
> The only thing that will be difficult to map is the poOptions. Depending on 
> the value of the eAlgorithm parameter, poOptions points to a different C 
> structure. I can't imagine something harder to map with SWIG... A solution 
> would be to have a variant of GDALGridCreate (or a wrapper for it) that would 
> accept an array of strings to pass the options and transform it into the 
> appropriate C structure. Then the mapping to SWIG would be doable.
> * For gdal_rasterize, the core API is GDALRasterizeGeometries(), which hasn't 
> been mapped to SWIG either. But GDALRasterizeLayers() has been mapped. See 
> http://gdal.org/java/org/gdal/gdal/gdal.html#RasterizeLayer%28org.gdal.gdal.Dataset,
> %20int[],%20org.gdal.ogr.Layer,%20double[],%20java.util.Vector,
> %20org.gdal.gdal.ProgressCallback%29
> As far as I see, the only reason for using RasterizeGeometries() instead of 
> RasterizeLayers() in the C++ program is because of the -i option that needs 
> to invert the geometries of the source layer. However I think this could be 
> workaround by using an intermediate in-memory layer with the MEM driver that 
> would hold the inverted geometries.
> Or, other solution, map RasterizeGeometries() to SWIG. This should be 
> moderately involved. Basically this will involve writing a typemap for (int 
> nGeomCount, OGRGeometryH *pahGeometries). You could take inspiration of the 
> typemap for (int object_list_count, GDALRasterBandShadow **poObjects) to do 
> so.
> In conclusion, the translation of gdal_rasterize.cpp to Java should be doable 
> with a moderate effort. gdal_grid is another story... I'd note that the 
> performance of gdal_grid is known to be not good when a big number of points 
> are used. In the event this is improved, an alternate API to GDALGridCreate() 
> might be necessary (for example passing a quadtree of points instead of an 
> array of coordinates, or any data structure that has efficient spatial lookup 
> capability)
> Best regards,
> Even
> Le Tuesday 04 May 2010 17:07:44 Miguel Angel Manso (UPM), vous avez écrit :
>> Dear Even,
>> My name is Miguel A. Manso from Technical University of Madrid (UPM)
>> Topographic, GEdesy and Cartography Engieniering scholl.
>> I'm old user of Gdal/OGr library and lover and defender of open source.
>> I've see that you are an active player in Java wrapper of Gdal/Ogr, and
>> almost of apps has been migrated to java from c++.
>> I'm interesting on two apps that have not yet migrated: gdal_grid and
>> gdal_contour
>> Do you have plans to migrate?
>> Can you help us (student and i) to do it?
>> Thank you for your attentions.
>> Best regards,
>> Miguel A.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Best regards,


More information about the gdal-dev mailing list