[gdal-dev] Converting ecw to tif for Geoserver

[Andrea Aime]

On Sun, Feb 10, 2013 at 10:20 PM, Even Rouault <even.rouault at mines-paris.org
> 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

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130211/a2735ce1/attachment-0001.html>