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.
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/GDALProximity.java
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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Best regards,
Ivan
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
