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

[Even Rouault]

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.

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.