Wrap GDALColorTable and GDALColorEntry with C API

[Mateusz Łoskot]

The GDALColorTable and GDALColorEntry should be wrapped with C API in order to avoid potential problems with crossing modules boundaries under Windows system, as well as to keep GDAL API consistent without forcing users to mix C++ API when they use C API, for some features.

[warmerdam]

GDALColorEntry is a C structure already.

There are already GDALColorTable related C functions. I'm not sure why they aren't used by gdal/swig/include/ColorTable.i

[warmerdam]

Howard has volunteered to fix up swig/include/ColorTable.i to use the C API.

Reassigning.

[hobu]

ColorTable.i rewritten in r11501 I'm confused about ColorEntry though... isn't it just a struct? We have it defined as such in gdal.i

[hobu]

ah, I see it is brought up to swig only for C#. Tamas, do you have any comment? Should we define the GDALColorEntry struct in gdal.i for all languages instead of just .NET? Do you remember why you defined it in gdal.i?

[tamas]

Replying to hobu:

ah, I see it is brought up to swig only for C#. Tamas, do you have any comment? Should we define the GDALColorEntry struct in gdal.i for all languages instead of just .NET? Do you remember why you defined it in gdal.i?

At that time I wouldn't want to affect the others by adding the new ColorEntry class. However gdal.i is the right place to implement such things, and someday the '#if defined(SWIGCSHARP)' can be removed when the other bindings would require this functionality. Generally I prefer to provide the implementation this way, and *would object* to treat this class as a fixed sized array for example.

[hobu]

Tamas or Frank,

Any objection to making the GDALColorEntry struct available to all swig languages? SWIG should take care of all access to it, as it is fairly simple.

Howard

[warmerdam]

I can live with exposing it through swig, though I hate the amount of gunk swig produces for stuff like this.

[hobu]

done. r11640

[tamas]

Replying to hobu:

Tamas or Frank,

Any objection to making the GDALColorEntry struct available to all swig languages? SWIG should take care of all access to it, as it is fairly simple.

Howard

I don't object. I prefer to expose classes instead of arrays whenever it is possible to keep the interface unambiguous.

Tamas

[Ari Jolma]

Replying to hobu:

done. r11640

If you gentlemen do not object, I'd like to put #ifndef SWIGPERL around the GDALColorEntry struct, i.e., prevent it becoming an object in Geo::GDAL.

[hobu]

Ari,

Is there a problem having this defined specific to Perl? Is it just the name? Without having this defined, a user in Perl won't be able to interact with ColorTables and its entries, correct?

Howard

[hobu]

I see Ari made this change already in r11661

[Ari Jolma]

Replying to hobu:

Ari,

Is there a problem having this defined specific to Perl? Is it just the name? Without having this defined, a user in Perl won't be able to interact with ColorTables and its entries, correct?

Yes they can see ​http://map.hut.fi/doc/Geo-GDAL/html/class_geo_1_1_g_d_a_l_1_1_color_table.html

The main reason is that there are Perl typemaps for color entry and they convert the rgba values between a perl array and gdal color entry struct. The new color entry class broke the perl wrappers and I couln'd figure out how to integrate the old wrappers and the new class so I just nuked the new class. :)

Howard

[hobu]

looks like no further problems with this. Closing for now...

[Even Rouault]

Problem similar to Perl bindings with Java. Solved by r16007. See #2331