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