[gdal-dev] Issues with Java Bindings in 1.5 ...

[abhay menon]

Hi,

 The GDAL Java Bind for GDAL 1.5 got compiled but the GDALTest.Java failed
to compile.

at line 295

cm = poBand.GetRasterColorTable().getIndexColorModel(
                                gdal.GetDataTypeSize(buf_type));

Is the getIndexColorModel method been deprecated is there any other method
that is return ColorModel which is available in GetRasterColorTable ??

Rgds

Abhay

On Jan 15, 2008 2:40 AM, Tamas Szekeres <szekerest at gmail.com> wrote:

> Rick,
>
> You can get further information about the history of the related
> changes from this ticket:
> http://trac.osgeo.org/gdal/ticket/1578
>
> According to the changeset http://trac.osgeo.org/gdal/changeset/11640
> The ColoryEntry is treated as objects for all of the binding instead
> of arrays. Therefore the typemaps for GDALColorEntry in java has
> become outdated.
> It seems to me that these typemaps in the java bindings are tending to
> map GDALColorEntry directly to java/awt/Color which is a target
> language specific type.
>
> I can consider the following 2 trivial options to fix this problem:
>
> 1, Revert the change for java
>
> Index: gdal.i
> ===================================================================
> --- gdal.i      (revision 13527)
> +++ gdal.i      (working copy)
> @@ -258,7 +258,7 @@
>  // GDALColorEntry
>  //
>
>  //************************************************************************
> -#ifndef SWIGPERL
> +#if !definied(SWIGPERL) and !defined(SWIGJAVA)
>  %rename (ColorEntry) GDALColorEntry;
>  typedef struct
>  {
>
>
> 2. Strip the GDALColorEntry typemaps and thread ColorEntry as a separate
> class.
>
> Index: typemaps_java.i
> ===================================================================
> --- typemaps_java.i     (revision 13527)
> +++ typemaps_java.i     (working copy)
> @@ -65,46 +65,9 @@
>
>
>
> -%typemap(in) (GDALColorEntry *) (GDALColorEntry tmp) {
> -  /* %typemap(in) (GDALColorEntry *) (GDALColorEntry tmp) */
> -  $1 = NULL;
> -  float *colorptr = 0;
> -  const jclass Color = jenv->FindClass("java/awt/Color");
> -  const jmethodID colors = jenv->GetMethodID(Color, "getRGBComponents",
> -    "([F)[F");
>
> -  jfloatArray colorArr = jenv->NewFloatArray(4);
> -  colorArr = (jfloatArray)jenv->CallObjectMethod($input, colors,
> colorArr);
>
> -  colorptr = (float *)jenv->GetFloatArrayElements(colorArr, 0);
> -  tmp.c1 = (short)(colorptr[0] * 255);
> -  tmp.c2 = (short)(colorptr[1] * 255);
> -  tmp.c3 = (short)(colorptr[2] * 255);
> -  tmp.c4 = (short)(colorptr[3] * 255);
> -  /*printf( "  %d, %d, %d, %d\n",
> -                    tmp.c1, tmp.c2, tmp.c3, tmp.c4 );*/
> -  $1 = &tmp;
> -}
>
> -%typemap(out) (GDALColorEntry *) {
> -  /* %typemap(out) (GDALColorEntry *) */
> -  const jclass Color = jenv->FindClass("java/awt/Color");
> -  const jmethodID ccon = jenv->GetMethodID(Color, "<init>",
> -    "(IIII)V");
> -  $result = jenv->NewObject(Color, ccon, $1->c1, $1->c2, $1->c3, $1->c4);
> -}
> -
> -%typemap(jni) (GDALColorEntry *) "jobject"
> -%typemap(jtype) (GDALColorEntry *) "java.awt.Color"
> -%typemap(jstype) (GDALColorEntry *) "java.awt.Color"
> -%typemap(javain) (GDALColorEntry *) "$javainput"
> -%typemap(javaout) (GDALColorEntry *) {
> -    return $jnicall;
> -  }
> -
> -
> -
> -
>  /*
>  * Typemap argout of GDAL_GCP* used in Dataset::GetGCPs( )
>  */
>
> I would suggest to apply #2 in the development version since it
> reduces the divergence between the java and the other languages,
> however it breaks the backward compatibility.
>
> Best regards,
>
> Tamas
>
>
>
>
> 2008/1/14, Rick Brownrigg <brownrigg at sunflower.com>:
> > I have spent some time investigating the build issues for the Java
> > bindings in 1.5, and for the most part there are a couple of nearly
> > trivial fixes to the Makefile and the environment settings that are
> > required. However, the most troublesome issue seems to be a swig
> > type-mapping issue, which at present I do not know how to correct. It
> > centers upon the gdal type ColorEntry, which is mapped in
> > ...../swig/include/gdal.i    For reasons I don't understand, the
> > generated file ..../swig/java/org/gdal/gdal/ColorEntry.java tries to
> > pass arguments of type long (a pointer presumably) to the various native
> > settors/gettors implemented in gdalJNI.java (also a generated file),
> > which is expecting java.awt.Color objects instead. Hence the code will
> > not compile.  I don't understand the source of the mismatch,
> > particularly as these two files are generated by swig.
> >
> > Note that this mismatch was present in 1.4.x, but was masked by a #ifdef
> > SWIGCSHARP directive around the mapping in gdal.i.  (and thus there was
> > no Java proxy for the gdal type ColorEntry in 1.4.x (?)).
> >
> > I had indicated I would volunteer to support the Java bindings, but with
> > this experience, I am now not confident  that I can do so in a timely
> > fashion.
> >
> > FWIW...
> > Rick Brownrigg
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080119/3e7e7b15/attachment-0001.html