I've uploaded my GeoTiff to my GeoServer after I called nearblack -white on the result of gdaladdo. This tiff did have some white artefacts, but they are not visually blocking as you can see here: http://www.smartdakscan.nl/website/tmp/artifacts.png http://www.smartdakscan.nl/website/tmp/artifacts-zoom.png
I did use the "input transparent color" in GeoServer and it is working great. I can now continue with my task. When I'm done I'll do some more experimenting with different order of steps and different compression to get a clean tiff. Thanks all for your help! Paul *Paul Meems * Release manager, configuration manager and forum moderator of MapWindow GIS. www.mapwindow.org Owner of MapWindow.nl - Support for Dutch speaking users. www.mapwindow.nl * * 2013/2/11 Andrea Aime <[email protected]> > 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
