On Sun, Feb 10, 2013 at 10:20 PM, Even Rouault <[email protected] > wrote:
> Provided that GeoServer can read VRT through GDAL. But I'm a bit surprised > to > see that only just a few GDAL formats are listed in > http://docs.geoserver.org/stable/en/user/data/raster/gdal.html . Not sure > why > it is a limited list. > > Ah, this is a complicated and sad story, if you want to hear it, not sure where to start. First thing, the list of formats is a reflection of a design decision back then in imageio-ext, where in order to expose a format you actually have to write a small class. Nothing fancy, but one class per format in order to properly extract some metadata from the files (I believe this a reflection of what the first format supported by imageio-ext were). Then, there is the fact that adding the binding for GDAL geotiff in GeoServer makes GeoServer stop reading TIFFs at all. We never had time to investigate. Moving forward, there is a tremendous pushback against using native libraries in the java world, which came from different angles. When the GDAL wrappers were first introduced part of the GeoTools community was starkly against having such readers, as it would have violated "java pureness" or something like that (don't remember exactly the wording, sorry). That eventually came to pass as that group moved away and founded GeoToolkit. But it's not only that, installation wise there is typically a lot of troubles too. First off, having to use a native library against a Java application is seen both as a security and stability risk, so in some enviroments that is simply a no go (funny you're proposing to have an external server to handle closed source formats in these days, something like that would help making usage of GDAL more palatable in such enviroments, it's just that instead of isolating the proprietary formats we'd have to isolate the whole GDAL... and the client to those server pool would have to be pure java). It is not a case that GeoServer is basically the only java OGC server that leverages GDAL (as far as I remember, at least). In other enviroments it's ok to add native libraries to the mix, but you have to use the distribution own packages, which often lack the JNI support, or miss some formats that are desired. And again, installing a compiler on those machines is simply a no go, and asking to install custom made packages (e.g., custom rpm made for CentOS or RedHat) is again sometimes a no go. Finally, importantly, and probably related to the above considerations, the reception of GDAL/OGR used as libraries has been rather tiepid in the user community, especially that part of the user community that funds the GeoTools/GeoServer development. To make you an example, I've tried two times to setup a OGR base data store in GeoToools, using my spare time, because it sounded like a interesting project, and cause it seemed like a good gesture of collaboration among OSGeo projects. Well, both times the store ended up rotting, personally I don't have a use for it, and I'm not aware of any significant usage of it within the user community either. Hope this clarifies things a bit Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it -------------------------------------------------------
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
