[gdal-dev] image-io extension
Simone Giannecchini
simone.giannecchini at geo-solutions.it
Fri Dec 10 10:26:23 EST 2010
Ciao Ivan,
well, what you are suggesting (deprecation/removal) cycle is a
standard policy within the porjects we have been involved, therefore
I am in favour of it. It is a natural way for having an API evolving.
On the other hand GDAL is well known for the rock solid stability of
its API, but yeah this "instability" would apply only to the Java
bindings
and would follow a well known practice.
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo
-------------------------------------------------------
On Fri, Dec 10, 2010 at 3:22 PM, Ivan Lucena <ivan.lucena at pmldnet.com> wrote:
> Ciao Simone, Salut Even,
>
> You guy did a great job improving the performance of reading and writing pixels buffer.
>
> http://www.mail-archive.com/search?l=gdal-dev%40lists.osgeo.org&q=ReadRaster_Direct
>
> But, "With great power comes great responsibility."
>
> Now we find users asking for changes that are not essential and that break backward compatibility.
>
> Let's see this one here for example:
>
>> Method names begin with Capital letters. The Java standard is that methods always begin with lowercase letters; classes begin with Upper Case letters. Constants should be all UPPER_CASE.
>>
>> Dataset hDataset = gdal.Open(filename,gdalconstConstants.GA_ReadOnly).GetDriver().getLongName();
>>
>> should read
>>
>> Dataset hDataset = Gdal.open(filename,GdalconstConstants.GA_READONLY).getDriver().getLongName();
>
> So what should we do?
>
> Prepare for change in GDAL 2.0 sound good to me.
>
> We can have two Java wrapper with a deprecated warning on the older (maintain it for about a year or two) and the new one would complain with Java standards and updated to whatever the language have evolved so far.
>
> IMHO.
>
> Regards,
>
> Ivan
>
>
>> -------Original Message-------
>> From: Simone Giannecchini <simone.giannecchini at geo-solutions.it>
>> To: Even Rouault <even.rouault at mines-paris.org>
>> Cc: gdal-dev at lists.osgeo.org, Viji V Nair <viji at fedoraproject.org>
>> Subject: Re: [gdal-dev] image-io extension
>> Sent: Dec 10 '10 04:27
>>
>> Ciao Even,
>> I have asked daniele to make those changes (which have not been reviewed yet)
>> in order to move away from the explicit usage of Vector and HashTable in method
>> signatures in favour of using the respective interfaces (List and Map).
>> Daniele can add more as needed...
>>
>> As you mentioned this change can break old code, but it should
>> make the java bindings more ... javaish :).
>>
>> We have other changes in the queue which we might submit to your review
>> early next year, but this is another topic...
>>
>>
>> Viji , I don't think you need to use the patch you are referring to since
>> that is needed for imageio-ext 1.1 which has not been released yet.
>> The latest (and greatest) is 1.0.8 which uses an older gdal version.
>>
>> Ciao,
>> Simone.
>> -------------------------------------------------------
>> Ing. Simone Giannecchini
>> GeoSolutions S.A.S.
>> Founder
>>
>> Via Poggio alle Viti 1187
>> 55054 Massarosa (LU)
>> Italy
>>
>> phone: +39 0584962313
>> fax: +39 0584962313
>> mob: +39 333 8128928
>>
>>
>> http://www.geo-solutions.it
>> http://geo-solutions.blogspot.com/
>> http://www.linkedin.com/in/simonegiannecchini
>> http://twitter.com/simogeo
>>
>> -------------------------------------------------------
>>
>>
>>
>> On Thu, Dec 9, 2010 at 8:25 PM, Even Rouault
>> <even.rouault at mines-paris.org> wrote:
>> > Hi Viji,
>> >
>> > I maintain the GDAL Java bindings, but the image-io GDAL plugin is another
>> > project whose maintener is Daniele I think. He'll correct me if I'm wrong, but
>> > I saw his name on http://docs.codehaus.org/display/GEOTOOLS/ImageIO-EXT+GDAL
>> > ;-) . I've CC'ed him so he has a chance to comment and explain the rational of
>> > the patch.
>> >
>> > I wasn't aware of this patch. I've skimmed through it quickly, and it seems
>> > that it only replaces old-fashionned data structures like Vector to use more
>> > trendish ArrayList + Java 1.5 generics. Well, this is certainly not a bad idea
>> > (something to consider for GDAL 2.0 ?), but I fail to see why it was
>> > *necessary* . I'm not particularly keen on applying this patch in GDAL
>> > mainline as it changes the API of the Java bindings, thus breaking working
>> > code of other users. I fail to see why ImageIO-EXT cannot use the existing
>> > API, even if it is perhaps not as convenient as it could be if it was using
>> > more modern Java API.
>> >
>> > Best regards,
>> >
>> > Even
>> >
>> > Le jeudi 09 décembre 2010 14:18:18, Viji V Nair a écrit :
>> >> Hi,
>> >>
>> >> I am one of the GDAL co-maintainer for Fedora, I would like to have
>> >> the image-io extension support, currently it been supported through
>> >> the following patch from image-io. But I dont think this is a good
>> >> idea as the modifications are bit heavy.
>> >>
>> >> https://imageio-ext.dev.java.net/svn/imageio-ext/trunk/patches/gdal1.7.2.pa
>> >> tch (Username : guest, Password: guest)
>> >>
>> >> Is there any work going on related to this? Please share the ideas
>> >>
>> >> Thanks
>> >> Viji
>> >> _______________________________________________
>> >> 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
>> >
>> _______________________________________________
>> 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
>
More information about the gdal-dev
mailing list