|Version 24 (modified by 6 years ago) ( diff ),|
End user documentation on the driver: http://www.gdal.org/frmt_ecw.html
Download ECW JPEG SDK
In order to use ECW format with GDAL, you need to download the "ERDAS ECW/JP2 SDK" from the Hexagon Geospatial website. The 4.3 or newer read-only SDK should be available for free download after agreeing to licensing terms. In order to write ECW or JPEG2000 files via the ECW SDK it is necessary to purchase a write enabled version of the SDK from Hexagon Geospatial/ERDAS.
If the out of date libecwj 3.3 SDK can be found, it can also be used. It has significantly different licensing details. Some tickets and discussion below are related to the 3.3 SDK.
Building GDAL with ECW support on Unix
Assuming you've installed libecwj library under default location, procedure of adding ECW support to GDAL is simple and you only need to provide GDAL configure with path to the ECW SDK installation prefix:
$ cd /path/to/gdal $ ./configure --with-ecw=/usr/local $ make # make install
You might find it necessary to define -DPOSIX and -DLINUX in CPPFLAGS in gdal/frmts/ecw/GNUmakefile as mentioned in #3344 if there are build problems.
After these steps, you should be able to see the ECW in the list of formats supported by your GDAL installation:
$ gdalinfo --formats|grep ECW ECW (rw): ERMapper Compressed Wavelets JP2ECW (rw+): ERMapper JPEG2000
Note: be sure to restart any services that may depend on GDAL ie. Apache to reload PHP MapScript
Binary ECW SDK and GCC >= 5.2
Since GCC 5.2, GCC uses a new C++ ABI for libstdc++ is used by default, which is incompatible of the ECW SDK binaries (at least to this date). The workaround is to build GDAL with CXXFLAGS="-D_GLIBCXX_USE_CXX11_ABI=0" ./configure [options]
Alternative tutorial for building on Linux
Building GDAL with ECW support on Windows
In the nmake.opt are the following instructions for building with read support with the 4.1 or newer readonly SDK.
# Uncomment the following and update to enable ECW read support with the # 4.1+ readonly SDK #ECWDIR = "c:/Program Files/ERDAS/ERDAS ECW JPEG2000 Read SDK" #ECWFLAGS = -DECWSDK_VERSION=41 \ # -I$(ECWDIR)\include \ # -I$(ECWDIR)\include/ecw/api -I$(ECWDIR)\include/ecw/jp2 \ # -I$(ECWDIR)\include/ecw/ecw #ECWLIB = $(ECWDIR)\lib\vc90\win32\NCSEcw4_RO.lib \ # $(ECWDIR)\lib\vc90\win32\NCSUtil4.lib \ # $(ECWDIR)\lib\vc90\win32\NCScnet4.lib
Once built, you will need to copy the appropriate redistributable ECW DLLs into the path. For the above case with VC9 this might be accomplished something like:
copy "C:\Program Files\ERDAS\ERDAS ECW JPEG2000 Read SDK\redistributable\vc90\win32\*.dll" C:\windows\system32
The above builds ECW support into the core GDAL DLL. In order to build the ECW and JP2ECW drivers as plugins uncomment the plugin line in the nmake.opt:
# To build ECW support as a plugin uncomment the following, and make sure # to do "nmake /f makefile.vc plugin" in gdal/frmts/ecw and copy the two # resulting DLLs to an appropriate place. ECW_PLUGIN = YES
Then do the following in gdal/frmts/ecw (after the GDAL build) to create the plugins:
nmake /f makefile.vc plugin
Then copy the resulting DLLs in that directory somewhere appropriate for GDAL plugins, like into a "gdalplugins" directory under the directory where the .exes live or into a directory pointed to by the GDAL_DRIVER_PATH configuration option (or environment variable).
Building libecwj 3.3 library on Unix
In order to use GDAL with ECW support under Linux, Solaris or Mac OS systems, you will need to build the libecwj library on your own, so it's required to download Image Compression SDK Source Code but not the binary distribution which is dedicated for Windows family systems. Current version is ECW SDK 3.3 and the source code package is named libecwj2-3.3-2006-09-06.zip.
The source code is equipped with configure and Makefile.in scripts. There is also an utility script called bootstrap that can be used to regenerate the configure and Makefile.in files, if you have installed required tools: autoconf, automake, m4, libtool.
In the former case, the procedure is simple:
$ cd /path/to/libecwj2-3.3 $ ./configure $ make # make install
where the last step should be run as superuser.
On SuSE 11, you need to pass a flag to the configure script so it uses c99 compatability.
$ cd /path/to/libecwj2-3.3 $ ./configure CFLAGS="-std=c99" $ make # make install
By default, the libecwj is installed using installation prefix pointing to /usr/local. You can change this location with --prefix option of configure script. Run ./configure --help for more details. If libecwj is compiled with --prefix (e.g. /usr/local/libecwj2-3.3) make install fails, because <prefix>/include is not created automatically. do a mkdir <prefix>/include (e.g. mkdir /usr/local/libecwj2-3.3/include) and run make install again.
On recent platforms (Fedora 16/17/18 and RHEL/CentOS 6) libecwj2 can crash you program when reading JPG2000-files. The error is in the XML-handling code that is bundled with libecwj2 and apparently this has become an issue with recent compilers. One workaround on the above mentioned platforms is to disable optimization when compiling libecwj2. This can be done by passing -O0 to configure:
$ ./configure CFLAGS="-O0" CXXFLAGS="-O0"
or to make:
$ make CFLAGS="-O0" CXXFLAGS="-O0"
Mac OS X notes
There are a few problems possible with libecwj2-3.3 on Mac OS X. For more details, refer to Ticket #2032 - Building with ECW support on Mac OS X
Building libecwj2-3.3 from source using recent compilers may require some improvements that can be found in the ticket #3162 - Fixes and patches for libecwj2.
A problem with opening and closing many ECW files consuming large amounts of memory with libecwj2-3.3 may be resolved using the libecwj patch in http://trac.osgeo.org/mapserver/ticket/3245.
A patch to avoid overflow in Linux implementation of NCSPhysicalMemorySize() in libecwj2-3.3 is available in the ticket #3366. This work around big memory usage for computers with RAM > 2 GB.
A patch to fix crash when creating 16 bit JP2 (that occurs on 64bit platforms) is available in ticket #2593.
A patch to fix a crash in ECWInitialize() on recent platforms such as Fedora 17 using new GCC (4.7 ?) is available in ticket #4868.