[gdal-dev] using GDAL in a java-program

[Even Rouault]

Le Friday 16 January 2009 18:14:00 Frank Warmerdam, vous avez écrit :
> I'm not exactly sure how to make the callback work for reporting progress.
> Hopefully you can just pass null for that.  There are a couple very brief
> examples of Java use in gdal/swig/java/apps though they don't cover
> building overviews.

I should mention that I'm currently working on improving the Java bindings.

In fact, the BuildOverviews() is one of the methods whose signature has 
changed in trunk.

Previously (1.5.X and 1.6.0), the signature was :

  public int BuildOverviews(String resampling, int[] overviewlist,
                                         SWIGTYPE_p_GDALProgressFunc callback,
                                         java.nio.ByteBuffer callback_data)

which was obviously wrong (wrong and missing typemaps for the callback).


In trunk, we now have :
   public int BuildOverviews(String resampling, int[] overviewlist,
                                          ProgressCallback callback);

where callback :
- can be passed as null,
- or used like this for the standard GDAL progress on the terminal:

	BuildOverviews(resampling, overviewlist, new TermProgressCallback());

- or for a custom progress method:

	BuildOverviews(resampling, overviewlist,
                        new ProgressCallback()  {
                           public int run(double dfProgress, String message) {
                              System.out.println(message + " " +
                                                      100 * dfProgress + "%");
                                return 1;
                            }
                        });

And (not commited yet), the callback argument will be an optional argument.


Do people think that these changes (only made when previous typemaps were 
wrong or missing) will be too disruptive ? If so, we could imagine adding 
compatibilty methods, to keep the same number of arguments. For example:

  public int BuildOverviews(String resampling, int[] overviewlist,
                                         Object unused1, Object unused2)
  {
     return BuildOverviews(resampling, overviewlist, null);
  }

but even if the number of argument is the same, the binary signature of the 
method would be different and people would have to recompile their Java code 
to run against the new GDAL .jar file. In any event, if people really need 
such a compatibilty layer, we'd need to know which methods they are using.

I should also mention that the API for many methods (like 
Dataset.ReadRaster(), Dataset.WriteRaster(), Dataset.SetGCP(), anything 
related to ColorTable) was so broken that they probably could not be used.

Any thought ?

Even