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