This project has moved and is read-only. For the latest updates, please go here.

OSGeo4W and SharpMap

Topics: SharpMap v0.9 / v1.x, SharpMap v2.0
Jan 19, 2010 at 12:51 AM

Hi all,

I've been using FWTools in SharpMap for displaying ECW imagery (via the GDALRasterLayer) and it has been performing quite well, but recently I ahve encountered a few issues with ECW files and have been advised by Frank Warmerdam that I'd be better off using the OSGeo4W implementation of GDAL. 

I noticed some previous discussion between JohnDiss and Frank on a web forum about using OSGeo4W in SharpMap and was wondering about how easy that is to change over to use.  I've got OSGeo4W installed on my machine but could not find any C# bindings in it. 

Can anyone offer some more advice on how I might go about using OSgeo4W from SharpMap?


Jan 19, 2010 at 10:08 AM

Hi Steve, I m not 100% sure but you may be able to use the bindings from a close version of FWTools against the equivalent version of GDAL.

You would add the key FWToolsBinPath to your app|web config with the absolute physical path to the directory that you unpacked gdal to (It doesn't need to be in the /bin dir).

In the SharpMap.Extensions project you would remove the reference to the current c# bindings and add a reference to the new ones fixing any compile errors that may result..

It may be a good idea to refactor the class|property|field names that start with FWTools to OSGeoTools or similar and update what is currently FWToolsHelper.FWToolsVersion to "1.6.x" (whatever the gdal version you use is).

If the c# bindings from FWTools do not work you will probably need to generate some new ones using swig at that point you may find yourself downloading and building the GDAL source (which isn't difficult as there is a VCProj or makefile if you prefer)..

hth jd

Jan 19, 2010 at 9:48 PM

Thanks for the suggestion jd, I'll give it a go later today.  I've been using 0.9 SharpMap and will update my source at the same time, as I do not currently have a FWToolsHelper methods anyway in my source.  From looking at the source, all this seems to do is point to the FWTools directory so that the user doesn't need to copy all the unmanaged DLLs over into their bin - please correct me if it does more than this.




Jan 19, 2010 at 10:04 PM
Edited Jan 19, 2010 at 10:05 PM

Hi Steve, yes that is the idea.. watch out though it didnt work out exactly to plan.. You may get TypeLoadExceptions when I meant them to fire a more helpful exception.

BTW the version of FWTools that the current 0.9 trunk is built against is far more recent than the one you are likeley to have been using. perf may have improved by magic ;)

hth jd

Jan 20, 2010 at 6:52 AM
Edited Jan 20, 2010 at 6:55 AM

I tried pointing the gdal_csharp wrapper to the OSGeo installation of gdal (by changing the FWToolsDirectory reference in the web.config.

When the GDALRasterLayer tries to create, it throws the following error: "The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception."

This is followed up by this message: 

Unable to load DLL 'gdal_wrap': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

[DllNotFoundException: Unable to load DLL 'gdal_wrap': The specified module could not be found. (Exception from HRESULT: 0x8007007E)]
OSGeo.GDAL.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate applicationDelegate, ExceptionDelegate arithmeticDelegate, ExceptionDelegate divideByZeroDelegate, ExceptionDelegate indexOutOfRangeDelegate, ExceptionDelegate invalidCastDelegate, ExceptionDelegate invalidOperationDelegate, ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate, ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate overflowDelegate, ExceptionDelegate systemExceptionDelegate) +0
OSGeo.GDAL.SWIGExceptionHelper..cctor() +762

[TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.]
OSGeo.GDAL.SWIGExceptionHelper..ctor() +0
OSGeo.GDAL.GdalPINVOKE..cctor() +41

[TypeInitializationException: The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.]
OSGeo.GDAL.GdalPINVOKE.AllRegister() +0
OSGeo.GDAL.Gdal.AllRegister() +24
SharpMap.Layers.GdalRasterLayer..ctor(String strLayerName, String imageFilename) in C:\source\Libraries\SharpMap\Trunk\SharpMap.Extensions\Layers\GdalRasterLayer.cs:393

I've trimmed off the stack trace above to just show the useful bits from when the raster layer gets created.

I am using the csharp wrappers from FWTools 2.4.6 and pointing to an installation of OSGeo containing gdal16. 

My thought is that it is probably failing because the file it is looking for (gdal_fw.dll) to load up imagery is missing (or has the name gdal16.dll), but maybe there is not such a direct link between these files - I don't know.  Any thought whether renaming files could work for me?  If so, could you have a punt at which files might need renaming.  I am unclear about what role the gdal_wrap file plays.

Any comments/ideas welcome about how to progress this.

Thanks, Steve



Jan 20, 2010 at 8:29 AM
Edited Jan 20, 2010 at 8:43 AM

Hello Steve,

There are several reasons why you cannot use FWTools bindings with OSGeo4W binaries:

The native gdal libraries provided via FWTools are named *_fw.dll, with OSGeo4W the suffix _fw is missing.
FWTools 2.4.6 provides binaries with version 1.7.0dev. (or above) and the version installed with OSGeo4W is 1.5.4 or 1.6.x.

You will need to find/compile plain c#bindings for one of these versions.




Jan 27, 2010 at 12:43 AM

Just to wrap this up, I've managed to use the C# bindings compiled and available at this address:

This was done by pointing the FWToolsBinPath to the bin directory of the GDAL download, then also adding in a line to the FWToolsHelper that sets a GDAL configuration path to the plugins directory (as needed for the ECW stuff). 

The line I added to the FWToolsHelper looks something like this:

OSGeo.GDAL.Gdal.SetConfigOption("GDAL_DRIVER_PATH", "c:\gdalbin\plugins");

I've tested this and have not had any of the problems I'd previously encountered with some troublesome ECW files, so fingers crossed it is all working well now.

Thanks all for your advice and also for the help from the GDAL devs. 

Jan 27, 2010 at 8:36 AM

Good to hear that you find a way.

I noticed these packages, too, and since compiling gdal is not at all a trivial task plan to use
them for Gdal in SharpMapV2. @JohnDiss: there are even x64-packages :-).



Jan 27, 2010 at 10:46 AM

Excellent news.. now if we could find some GDAL ARM binaries around that would may help tidy up CF too.. jd