[Gdal-dev] Re: [UMN_MAPSERVER-DEV] MapServer and ECW

Frank Warmerdam fwarmerdam at gmail.com
Tue Jun 28 12:12:19 EDT 2005


On 6/28/05, Daniel Morissette <dmorissette at dmsolutions.ca> wrote:
> This question is probably more for Frank, but I am interested in
> feedback from anyone else who has played with MapServer and ECW on Linux
> already...
> 
> We've just gone through a painful experience trying to get MapServer to
> work with MrSid files via GDAL on Linux a few weeks ago. Initially we
> suspected corrupted data files because some of them worked and some
> didn't, but it turned out that there were some recent fixes in the GDAL
> CVS that we didn't have. Rebuilding with the latest GDAL from CVS did
> the trick.
> 
> Now that ER-Mapper has modified its license to allow use of the ECW SDK
> with open source server software such as MapServer, we need to get
> Mapserver working with ECW on one of our client's servers. However,
> before we go through the same experience as for MrSid, I'd like to know
> if anyone else has tested/used MapServer with ECW files on Linux? Are
> there specific requirements (GDAL version, DSDK version, etc.)? Anything
> else we should know about?

Daniel, 

There are definately "challenges" with using ECW though they are all
quite overcomable.  

On Linux there have been ongoing issues with the ECW SDK and 
threads handing as files are closed.  In a MapServer context this will
result in map renders not completing and the cgi hanging around
till killed due to timeouts.  Bill Binko has some patches that are helpful.
I applied his patches to the ECW SDK 3.2beta1 and was able to get
things working reliably. 

Building the ECW SDK from source (the only approach available on Linux)
can be quite challenging.  ERMapper provides two approaches to building
in the 3.2beta.  I found it easiest to build by doing:

  cd Sources/NCSBuildQmake
  make -f Makefile-linux-shared

Then manually installing stuff:

  mv ../../lib /usr/local/lib
  cp ../include/* /usr/local/include

One quirk of the ECW SDK is that the include files depend on external
macros setting various platform specific flags.  Rather than hack GDAL to
include different variations of these for each platform, I have taken the 
approach of hacking the ECW SDK include files to define them.  I create
a file called NCSDefines.h and modify their existing NCSTypes.h to include
it.  I put the following in NCSDefines.h for Linux:

#ifndef LINUX
#define LINUX
#define POSIX
#define UNICODE
#define _LARGEFILE_SOURCE
#define _LARGEFILE64_SOURCE
#define _FILE_OFFSET_BITS 64 
#define _GNU_SOURCE
#define LIBECWJ2
#endif

One problem with the "qmake" derived makefiles for the ECW SDK is that
they produce a different library name than was produced by earlier versions
of the SDK.  I just manually hack GDALmake.opt to refer to this library 
(-lecwj2) instead of the old library name (-lNCSEcw).  

If you use the 3.2beta build of the ECW SDK you will also need to 
use the latest version of GDAL from CVS.  I added some initialization
needed by 3.2beta in GDAL just a few days ago.  

Another approach would be to try and use the ECW SDK 3.1 RC2
with Bill Binko's changes.  It uses a different build mechanism though,
which I found somewhat tricky.  It should work with GDAL 1.2.6 out of
the box. 

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent



More information about the Gdal-dev mailing list