[gdal-dev] Converting ecw to tif for Geoserver

[Paul Meems]

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 <andrea.aime at geo-solutions.it>

> 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/20130213/97625e14/attachment.html>