[gdal-dev] Re: Java wrapper of GDAL/OGR application
ivan.lucena at pmldnet.com
Tue May 4 10:15:46 EDT 2010
Even Rouault wrote:
> 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
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 :
> 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
> 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
> 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
> 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
> Best regards,
> 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
>> 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
More information about the gdal-dev