[gdal-dev] C#: Gdal on Win64

[Tomas R]

Is it possible to use gdal (C# wrapped) from FWTools on a Win64 system
(Vista 64)?

I have a plugin for SportTracks which gives other libraries access to
GDAL. This is achieved by adding the path to the GDAL binaries to system
PATH (for the running program).

On a Win64, i.e. Vista 64, the exception below is thrown when trying to
read the version of the GDAL libraries. Is this normal behaviour or is
there anything I can do to avoid this exception? I use GDAL 1.6.0dev
from FWTools 2.1.0. All supportive libraries from FWTools are available
to Gdal.

System.TypeInitializationException: The type initializer for
'OSGeo.GDAL.GdalPINVOKE' threw an exception. --->
System.TypeInitializationException: The type initializer for
'SWIGExceptionHelper' threw an exception. --->
System.BadImageFormatException: An attempt was made to load a program
with an incorrect format. (Exception from HRESULT: 0x8007000B)
at
OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate
applicationDelegate, ExceptionDelegate arithmeticDelegate,
ExceptionDelegate divideByZeroDelegate, ExceptionDelegate
indexOutOfRangeDelegate, ExceptionDelegate invalidOperationDelegate,
ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate,
ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate
overflowDelegate, ExceptionDelegate systemExceptionDelegate)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.GDAL.GdalPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
at OSGeo.GDAL.Gdal.SetConfigOption(String arg0, String arg1)
at GDALPlugin.Gdal_Interface..ctor()


Yours
Tomas

[Tamas Szekeres]

Tomas,

Currently I have no opportunity to test on Vista 64 at the moment and
therefore I cannot decide whether this is a Vista specific issue or
not. I'm not sure which .NET framework you are running against. You
might want to do a test with my Windows Server 2003 x64 compilation
can be downloaded from the buildbot:

http://vbkto.dyndns.org:1080/gdal/szekerest-vc80-full/gdal/

I could also make the x64 versions of related dlls like proj.dll
available to download.

Best regards,

Tamas

Post by Tomas R
Is it possible to use gdal (C# wrapped) from FWTools on a Win64 system
(Vista 64)?
I have a plugin for SportTracks which gives other libraries access to
GDAL. This is achieved by adding the path to the GDAL binaries to system
PATH (for the running program).
On a Win64, i.e. Vista 64, the exception below is thrown when trying to
read the version of the GDAL libraries. Is this normal behaviour or is
there anything I can do to avoid this exception? I use GDAL 1.6.0dev
from FWTools 2.1.0. All supportive libraries from FWTools are available
to Gdal.
System.TypeInitializationException: The type initializer for
'OSGeo.GDAL.GdalPINVOKE' threw an exception. --->
System.TypeInitializationException: The type initializer for
'SWIGExceptionHelper' threw an exception. --->
System.BadImageFormatException: An attempt was made to load a program
with an incorrect format. (Exception from HRESULT: 0x8007000B)
at
OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate
applicationDelegate, ExceptionDelegate arithmeticDelegate,
ExceptionDelegate divideByZeroDelegate, ExceptionDelegate
indexOutOfRangeDelegate, ExceptionDelegate invalidOperationDelegate,
ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate,
ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate
overflowDelegate, ExceptionDelegate systemExceptionDelegate)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.GDAL.GdalPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
at OSGeo.GDAL.Gdal.SetConfigOption(String arg0, String arg1)
at GDALPlugin.Gdal_Interface..ctor()
Yours
Tomas
_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Tomas R]

Neither have I access to a computer with Vista 64, or any other 64 bit
system, it is a user who has reported the error. I'm waiting to see if
there will be another user with a 64 bit system who will test the plugin
so as you say, it is not yet confirmed it is a 64 bit error.


The plugin is compiled to .Net2.0 and, of course on Vista, run on .Net3.5.

Since I personally can't test it is a bit harder/slower to verify if it
works. A quick test on my computer (Win XP, 32 bit), after renaming the
gdal16dev.dll to gdal_fw.dll, together with FWTools C# wrappers and
supporting libraries I am able to query the gdal version but not, with
existing code, set up a spatial reference. (Pinvoke error, Can't read
the DLL-file osr_wrap)

Strange - is it a 64 bit "version" of gdal? should it then at all work
on my 32 bit system? That it fails on setting up a spatial reference I
guess is because it it is not able to reference to the FWtools version
of the supporting dlls. Or?

I will see if the user is willing to try this dll I downloaded from your
link and see if he is able to retrieve version information. If that
works we can move on to the rest of the libraries if you are willing.


Yours
Tomas

Post by Tamas Szekeres
Tomas,
Currently I have no opportunity to test on Vista 64 at the moment and
therefore I cannot decide whether this is a Vista specific issue or
not. I'm not sure which .NET framework you are running against. You
might want to do a test with my Windows Server 2003 x64 compilation
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80-full/gdal/
I could also make the x64 versions of related dlls like proj.dll
available to download.
Best regards,
Tamas

Post by Tomas R
Is it possible to use gdal (C# wrapped) from FWTools on a Win64 system
(Vista 64)?
I have a plugin for SportTracks which gives other libraries access to
GDAL. This is achieved by adding the path to the GDAL binaries to system
PATH (for the running program).
On a Win64, i.e. Vista 64, the exception below is thrown when trying to
read the version of the GDAL libraries. Is this normal behaviour or is
there anything I can do to avoid this exception? I use GDAL 1.6.0dev
from FWTools 2.1.0. All supportive libraries from FWTools are available
to Gdal.
System.TypeInitializationException: The type initializer for
'OSGeo.GDAL.GdalPINVOKE' threw an exception. --->
System.TypeInitializationException: The type initializer for
'SWIGExceptionHelper' threw an exception. --->
System.BadImageFormatException: An attempt was made to load a program
with an incorrect format. (Exception from HRESULT: 0x8007000B)
at
OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate
applicationDelegate, ExceptionDelegate arithmeticDelegate,
ExceptionDelegate divideByZeroDelegate, ExceptionDelegate
indexOutOfRangeDelegate, ExceptionDelegate invalidOperationDelegate,
ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate,
ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate
overflowDelegate, ExceptionDelegate systemExceptionDelegate)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.GDAL.GdalPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
at OSGeo.GDAL.Gdal.SetConfigOption(String arg0, String arg1)
at GDALPlugin.Gdal_Interface..ctor()
Yours
Tomas
_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Tamas Szekeres]

Grrr. I've posted a reference to the x32 builder, here are the correct ones:

http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-full/gdal/
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-bin

Best regards,

Tamas

Post by Tomas R
Neither have I access to a computer with Vista 64, or any other 64 bit
system, it is a user who has reported the error. I'm waiting to see if
there will be another user with a 64 bit system who will test the plugin
so as you say, it is not yet confirmed it is a 64 bit error.
The plugin is compiled to .Net2.0 and, of course on Vista, run on .Net3.5.
Since I personally can't test it is a bit harder/slower to verify if it
works. A quick test on my computer (Win XP, 32 bit), after renaming the
gdal16dev.dll to gdal_fw.dll, together with FWTools C# wrappers and
supporting libraries I am able to query the gdal version but not, with
existing code, set up a spatial reference. (Pinvoke error, Can't read
the DLL-file osr_wrap)
Strange - is it a 64 bit "version" of gdal? should it then at all work
on my 32 bit system? That it fails on setting up a spatial reference I
guess is because it it is not able to reference to the FWtools version
of the supporting dlls. Or?
I will see if the user is willing to try this dll I downloaded from your
link and see if he is able to retrieve version information. If that
works we can move on to the rest of the libraries if you are willing.
Yours
Tomas

Post by Tamas Szekeres
Tomas,
Currently I have no opportunity to test on Vista 64 at the moment and
therefore I cannot decide whether this is a Vista specific issue or
not. I'm not sure which .NET framework you are running against. You
might want to do a test with my Windows Server 2003 x64 compilation
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80-full/gdal/
I could also make the x64 versions of related dlls like proj.dll
available to download.
Best regards,
Tamas

Post by Tomas R
Is it possible to use gdal (C# wrapped) from FWTools on a Win64 system
(Vista 64)?
I have a plugin for SportTracks which gives other libraries access to
GDAL. This is achieved by adding the path to the GDAL binaries to system
PATH (for the running program).
On a Win64, i.e. Vista 64, the exception below is thrown when trying to
read the version of the GDAL libraries. Is this normal behaviour or is
there anything I can do to avoid this exception? I use GDAL 1.6.0dev
from FWTools 2.1.0. All supportive libraries from FWTools are available
to Gdal.
System.TypeInitializationException: The type initializer for
'OSGeo.GDAL.GdalPINVOKE' threw an exception. --->
System.TypeInitializationException: The type initializer for
'SWIGExceptionHelper' threw an exception. --->
System.BadImageFormatException: An attempt was made to load a program
with an incorrect format. (Exception from HRESULT: 0x8007000B)
at
OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate
applicationDelegate, ExceptionDelegate arithmeticDelegate,
ExceptionDelegate divideByZeroDelegate, ExceptionDelegate
indexOutOfRangeDelegate, ExceptionDelegate invalidOperationDelegate,
ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate,
ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate
overflowDelegate, ExceptionDelegate systemExceptionDelegate)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.GDAL.GdalPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
at OSGeo.GDAL.Gdal.SetConfigOption(String arg0, String arg1)
at GDALPlugin.Gdal_Interface..ctor()
Yours
Tomas
_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Tomas R]

No harm done....

I won't even bother to try these on my computer. It looks like a 64 bit
version, the files are bit bigger :)

/Tomas

Post by Tamas Szekeres
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-full/gdal/
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-bin
Best regards,
Tamas

Post by Tomas R
Neither have I access to a computer with Vista 64, or any other 64 bit
system, it is a user who has reported the error. I'm waiting to see if
there will be another user with a 64 bit system who will test the plugin
so as you say, it is not yet confirmed it is a 64 bit error.
The plugin is compiled to .Net2.0 and, of course on Vista, run on .Net3.5.
Since I personally can't test it is a bit harder/slower to verify if it
works. A quick test on my computer (Win XP, 32 bit), after renaming the
gdal16dev.dll to gdal_fw.dll, together with FWTools C# wrappers and
supporting libraries I am able to query the gdal version but not, with
existing code, set up a spatial reference. (Pinvoke error, Can't read
the DLL-file osr_wrap)
Strange - is it a 64 bit "version" of gdal? should it then at all work
on my 32 bit system? That it fails on setting up a spatial reference I
guess is because it it is not able to reference to the FWtools version
of the supporting dlls. Or?
I will see if the user is willing to try this dll I downloaded from your
link and see if he is able to retrieve version information. If that
works we can move on to the rest of the libraries if you are willing.
Yours
Tomas

Post by Tamas Szekeres
Tomas,
Currently I have no opportunity to test on Vista 64 at the moment and
therefore I cannot decide whether this is a Vista specific issue or
not. I'm not sure which .NET framework you are running against. You
might want to do a test with my Windows Server 2003 x64 compilation
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80-full/gdal/
I could also make the x64 versions of related dlls like proj.dll
available to download.
Best regards,
Tamas

Post by Tomas R
Is it possible to use gdal (C# wrapped) from FWTools on a Win64 system
(Vista 64)?
I have a plugin for SportTracks which gives other libraries access to
GDAL. This is achieved by adding the path to the GDAL binaries to system
PATH (for the running program).
On a Win64, i.e. Vista 64, the exception below is thrown when trying to
read the version of the GDAL libraries. Is this normal behaviour or is
there anything I can do to avoid this exception? I use GDAL 1.6.0dev
from FWTools 2.1.0. All supportive libraries from FWTools are available
to Gdal.
System.TypeInitializationException: The type initializer for
'OSGeo.GDAL.GdalPINVOKE' threw an exception. --->
System.TypeInitializationException: The type initializer for
'SWIGExceptionHelper' threw an exception. --->
System.BadImageFormatException: An attempt was made to load a program
with an incorrect format. (Exception from HRESULT: 0x8007000B)
at
OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate
applicationDelegate, ExceptionDelegate arithmeticDelegate,
ExceptionDelegate divideByZeroDelegate, ExceptionDelegate
indexOutOfRangeDelegate, ExceptionDelegate invalidOperationDelegate,
ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate,
ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate
overflowDelegate, ExceptionDelegate systemExceptionDelegate)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.GDAL.GdalPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
at OSGeo.GDAL.Gdal.SetConfigOption(String arg0, String arg1)
at GDALPlugin.Gdal_Interface..ctor()
Yours
Tomas
_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Tomas R]

Sad to say, same error occured with these dlls. I renamed them to
gdal_fw.dll and proj_fw.dll and also kept a copy of proj.dll with
original name and told the user to overwrite the existing ones.

Same error.

I will not say it is a Vista problem, or a 64-bit problem, until I have
a confirmation from someone else.
If anyone here, with a 64-bit system (Vista, XP or Server 2003), is
willing to give it a try:
1: Install SportTracks
http://www.zonefivesoftware.com/SportTracks/
2: Install my GDAL-plugin
http://mapplugin.googlepages.com/gdal

Start SportTracks, go to the settings view. Locate the plugin and check
if it is installed correctly. Version info should be displayed.

Yours
Tomas

Post by Tamas Szekeres
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-full/gdal/
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-bin
Best regards,
Tamas

Post by Tomas R
Neither have I access to a computer with Vista 64, or any other 64 bit
system, it is a user who has reported the error. I'm waiting to see if
there will be another user with a 64 bit system who will test the plugin
so as you say, it is not yet confirmed it is a 64 bit error.
The plugin is compiled to .Net2.0 and, of course on Vista, run on .Net3.5.
Since I personally can't test it is a bit harder/slower to verify if it
works. A quick test on my computer (Win XP, 32 bit), after renaming the
gdal16dev.dll to gdal_fw.dll, together with FWTools C# wrappers and
supporting libraries I am able to query the gdal version but not, with
existing code, set up a spatial reference. (Pinvoke error, Can't read
the DLL-file osr_wrap)
Strange - is it a 64 bit "version" of gdal? should it then at all work
on my 32 bit system? That it fails on setting up a spatial reference I
guess is because it it is not able to reference to the FWtools version
of the supporting dlls. Or?
I will see if the user is willing to try this dll I downloaded from your
link and see if he is able to retrieve version information. If that
works we can move on to the rest of the libraries if you are willing.
Yours
Tomas

Post by Tamas Szekeres
Tomas,
Currently I have no opportunity to test on Vista 64 at the moment and
therefore I cannot decide whether this is a Vista specific issue or
not. I'm not sure which .NET framework you are running against. You
might want to do a test with my Windows Server 2003 x64 compilation
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80-full/gdal/
I could also make the x64 versions of related dlls like proj.dll
available to download.
Best regards,
Tamas

Post by Tomas R
Is it possible to use gdal (C# wrapped) from FWTools on a Win64 system
(Vista 64)?
I have a plugin for SportTracks which gives other libraries access to
GDAL. This is achieved by adding the path to the GDAL binaries to system
PATH (for the running program).
On a Win64, i.e. Vista 64, the exception below is thrown when trying to
read the version of the GDAL libraries. Is this normal behaviour or is
there anything I can do to avoid this exception? I use GDAL 1.6.0dev
from FWTools 2.1.0. All supportive libraries from FWTools are available
to Gdal.
System.TypeInitializationException: The type initializer for
'OSGeo.GDAL.GdalPINVOKE' threw an exception. --->
System.TypeInitializationException: The type initializer for
'SWIGExceptionHelper' threw an exception. --->
System.BadImageFormatException: An attempt was made to load a program
with an incorrect format. (Exception from HRESULT: 0x8007000B)
at
OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate
applicationDelegate, ExceptionDelegate arithmeticDelegate,
ExceptionDelegate divideByZeroDelegate, ExceptionDelegate
indexOutOfRangeDelegate, ExceptionDelegate invalidOperationDelegate,
ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate,
ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate
overflowDelegate, ExceptionDelegate systemExceptionDelegate)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.GDAL.GdalPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
at OSGeo.GDAL.Gdal.SetConfigOption(String arg0, String arg1)
at GDALPlugin.Gdal_Interface..ctor()
Yours
Tomas
_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Tamas Szekeres]

Tomas,

I did some tests with your files on my Win2003 x64 Server. I can see
your assembly is actually running against the x64 version of the .NET
framework 2.0, but the binaries in FWTools have been compiled for the
.NET FW 1.0.

Although these assemblies can work side by side in case if both of the
framework versions are installed. Despite I have both of these
installed I got the badimageformat exception as well. The most
possible reason of this is that the 64 bit version of the framework
expects to load only the x64 versions of the unmanaged dll-s (like
gdal_wrap.dll, proj.dll).

I couldn't actually check the statements above because I have no
chance to recompile your plugin against my gdal binaries.

However for supporting x64 you have at least the following 2 options:

1. Compile gdal and all of the dependencies for x64 and use these
binaries instead of the FWTools version. You'll have to distribute 2
versions of your package (x64 and x32) in this case.

2. Force your dll to run against the 32 bit version of the .NET
Framework 2.0 by using the /platform:x86 csc command line option. If
you are using the VS2005 IDE you can find this option project
settings/Build tab/Platform target. In this case I think the FWTools
binaries will become usable, but I recommend to compile gdal for the
2.0 version of the .NET framework anyway.


Best regards,

Tamas

Post by Tomas R
Sad to say, same error occured with these dlls. I renamed them to
gdal_fw.dll and proj_fw.dll and also kept a copy of proj.dll with
original name and told the user to overwrite the existing ones.
Same error.
I will not say it is a Vista problem, or a 64-bit problem, until I have
a confirmation from someone else.
If anyone here, with a 64-bit system (Vista, XP or Server 2003), is
1: Install SportTracks
http://www.zonefivesoftware.com/SportTracks/
2: Install my GDAL-plugin
http://mapplugin.googlepages.com/gdal
Start SportTracks, go to the settings view. Locate the plugin and check
if it is installed correctly. Version info should be displayed.
Yours
Tomas

Post by Tamas Szekeres
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-full/gdal/
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-bin
Best regards,
Tamas

Post by Tomas R
Neither have I access to a computer with Vista 64, or any other 64 bit
system, it is a user who has reported the error. I'm waiting to see if
there will be another user with a 64 bit system who will test the plugin
so as you say, it is not yet confirmed it is a 64 bit error.
The plugin is compiled to .Net2.0 and, of course on Vista, run on .Net3.5.
Since I personally can't test it is a bit harder/slower to verify if it
works. A quick test on my computer (Win XP, 32 bit), after renaming the
gdal16dev.dll to gdal_fw.dll, together with FWTools C# wrappers and
supporting libraries I am able to query the gdal version but not, with
existing code, set up a spatial reference. (Pinvoke error, Can't read
the DLL-file osr_wrap)
Strange - is it a 64 bit "version" of gdal? should it then at all work
on my 32 bit system? That it fails on setting up a spatial reference I
guess is because it it is not able to reference to the FWtools version
of the supporting dlls. Or?
I will see if the user is willing to try this dll I downloaded from your
link and see if he is able to retrieve version information. If that
works we can move on to the rest of the libraries if you are willing.
Yours
Tomas

Post by Tamas Szekeres
Tomas,
Currently I have no opportunity to test on Vista 64 at the moment and
therefore I cannot decide whether this is a Vista specific issue or
not. I'm not sure which .NET framework you are running against. You
might want to do a test with my Windows Server 2003 x64 compilation
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80-full/gdal/
I could also make the x64 versions of related dlls like proj.dll
available to download.
Best regards,
Tamas

Post by Tomas R
Is it possible to use gdal (C# wrapped) from FWTools on a Win64 system
(Vista 64)?
I have a plugin for SportTracks which gives other libraries access to
GDAL. This is achieved by adding the path to the GDAL binaries to system
PATH (for the running program).
On a Win64, i.e. Vista 64, the exception below is thrown when trying to
read the version of the GDAL libraries. Is this normal behaviour or is
there anything I can do to avoid this exception? I use GDAL 1.6.0dev
from FWTools 2.1.0. All supportive libraries from FWTools are available
to Gdal.
System.TypeInitializationException: The type initializer for
'OSGeo.GDAL.GdalPINVOKE' threw an exception. --->
System.TypeInitializationException: The type initializer for
'SWIGExceptionHelper' threw an exception. --->
System.BadImageFormatException: An attempt was made to load a program
with an incorrect format. (Exception from HRESULT: 0x8007000B)
at
OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate
applicationDelegate, ExceptionDelegate arithmeticDelegate,
ExceptionDelegate divideByZeroDelegate, ExceptionDelegate
indexOutOfRangeDelegate, ExceptionDelegate invalidOperationDelegate,
ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate,
ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate
overflowDelegate, ExceptionDelegate systemExceptionDelegate)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.GDAL.GdalPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
at OSGeo.GDAL.Gdal.SetConfigOption(String arg0, String arg1)
at GDALPlugin.Gdal_Interface..ctor()
Yours
Tomas
_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Tomas R]

Oh, thanks for testing my plugin. Really appreciate your assistance!

The source project, the whole VSE solution, you can find here:
http://mapplugin.googlepages.com/GDALPlugin_source.zip
Excluded are ALL DLLs from FWTools, just to keep down the size. I guess
you have those. Copy all DLL files in FWTools\bin to the folder GDALBin
in the project and set all files to be copied to target. Probably you
also have to set the target folder of the build to another location
since it is set to the location of the installation of SportTracks on my
computer.

1: Oh, my. No chance you (or who ever) moves FWTools to Net2 and
possibly Win64 soon? I guess it is possible for me, on a XP 32 bit, to
compile it all to Win64 but it is unknown territory for me.
What would I need to recompile? Just the files the C# wrapper directly
interact with (gdal, gdalwarp, osr, ogr, gdalconst, mapscript) or all
(!) files of the FWTools package I may need? Which I actually need of
those - no idea.

2: Quick, dirty and may work. I will give it a try but, as you indicate,
it is far from a perfect solution. Took some time but I finally found
how to set this option in Visual Studio Express, this page helped me:
http://www.thescripts.com/forum/thread755379.html
Will give the Vista 64 user a version with the flag set and see if it
works.

Yours
/Tomas

Post by Tamas Szekeres
Tomas,
I did some tests with your files on my Win2003 x64 Server. I can see
your assembly is actually running against the x64 version of the .NET
framework 2.0, but the binaries in FWTools have been compiled for the
.NET FW 1.0.
Although these assemblies can work side by side in case if both of the
framework versions are installed. Despite I have both of these
installed I got the badimageformat exception as well. The most
possible reason of this is that the 64 bit version of the framework
expects to load only the x64 versions of the unmanaged dll-s (like
gdal_wrap.dll, proj.dll).
I couldn't actually check the statements above because I have no
chance to recompile your plugin against my gdal binaries.
1. Compile gdal and all of the dependencies for x64 and use these
binaries instead of the FWTools version. You'll have to distribute 2
versions of your package (x64 and x32) in this case.
2. Force your dll to run against the 32 bit version of the .NET
Framework 2.0 by using the /platform:x86 csc command line option. If
you are using the VS2005 IDE you can find this option project
settings/Build tab/Platform target. In this case I think the FWTools
binaries will become usable, but I recommend to compile gdal for the
2.0 version of the .NET framework anyway.
Best regards,
Tamas

Post by Tomas R
Sad to say, same error occured with these dlls. I renamed them to
gdal_fw.dll and proj_fw.dll and also kept a copy of proj.dll with
original name and told the user to overwrite the existing ones.
Same error.
I will not say it is a Vista problem, or a 64-bit problem, until I have
a confirmation from someone else.
If anyone here, with a 64-bit system (Vista, XP or Server 2003), is
1: Install SportTracks
http://www.zonefivesoftware.com/SportTracks/
2: Install my GDAL-plugin
http://mapplugin.googlepages.com/gdal
Start SportTracks, go to the settings view. Locate the plugin and check
if it is installed correctly. Version info should be displayed.
Yours
Tomas

Post by Tamas Szekeres
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-full/gdal/
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-bin
Best regards,
Tamas

Post by Tomas R
Neither have I access to a computer with Vista 64, or any other 64 bit
system, it is a user who has reported the error. I'm waiting to see if
there will be another user with a 64 bit system who will test the plugin
so as you say, it is not yet confirmed it is a 64 bit error.
The plugin is compiled to .Net2.0 and, of course on Vista, run on .Net3.5.
Since I personally can't test it is a bit harder/slower to verify if it
works. A quick test on my computer (Win XP, 32 bit), after renaming the
gdal16dev.dll to gdal_fw.dll, together with FWTools C# wrappers and
supporting libraries I am able to query the gdal version but not, with
existing code, set up a spatial reference. (Pinvoke error, Can't read
the DLL-file osr_wrap)
Strange - is it a 64 bit "version" of gdal? should it then at all work
on my 32 bit system? That it fails on setting up a spatial reference I
guess is because it it is not able to reference to the FWtools version
of the supporting dlls. Or?
I will see if the user is willing to try this dll I downloaded from your
link and see if he is able to retrieve version information. If that
works we can move on to the rest of the libraries if you are willing.
Yours
Tomas

Post by Tamas Szekeres
Tomas,
Currently I have no opportunity to test on Vista 64 at the moment and
therefore I cannot decide whether this is a Vista specific issue or
not. I'm not sure which .NET framework you are running against. You
might want to do a test with my Windows Server 2003 x64 compilation
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80-full/gdal/
I could also make the x64 versions of related dlls like proj.dll
available to download.
Best regards,
Tamas

Post by Tomas R
Is it possible to use gdal (C# wrapped) from FWTools on a Win64 system
(Vista 64)?
I have a plugin for SportTracks which gives other libraries access to
GDAL. This is achieved by adding the path to the GDAL binaries to system
PATH (for the running program).
On a Win64, i.e. Vista 64, the exception below is thrown when trying to
read the version of the GDAL libraries. Is this normal behaviour or is
there anything I can do to avoid this exception? I use GDAL 1.6.0dev
from FWTools 2.1.0. All supportive libraries from FWTools are available
to Gdal.
System.TypeInitializationException: The type initializer for
'OSGeo.GDAL.GdalPINVOKE' threw an exception. --->
System.TypeInitializationException: The type initializer for
'SWIGExceptionHelper' threw an exception. --->
System.BadImageFormatException: An attempt was made to load a program
with an incorrect format. (Exception from HRESULT: 0x8007000B)
at
OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate
applicationDelegate, ExceptionDelegate arithmeticDelegate,
ExceptionDelegate divideByZeroDelegate, ExceptionDelegate
indexOutOfRangeDelegate, ExceptionDelegate invalidOperationDelegate,
ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate,
ExceptionDelegate outOfMemoryDelegate, ExceptionDelegate
overflowDelegate, ExceptionDelegate systemExceptionDelegate)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.GDAL.GdalPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
at OSGeo.GDAL.Gdal.SetConfigOption(String arg0, String arg1)
at GDALPlugin.Gdal_Interface..ctor()
Yours
Tomas
_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Tamas Szekeres]

Post by Tomas R
Oh, thanks for testing my plugin. Really appreciate your assistance!
http://mapplugin.googlepages.com/GDALPlugin_source.zip
Excluded are ALL DLLs from FWTools, just to keep down the size. I guess
you have those. Copy all DLL files in FWTools\bin to the folder GDALBin
in the project and set all files to be copied to target. Probably you
also have to set the target folder of the build to another location
since it is set to the location of the installation of SportTracks on my
computer.

I couldn't download this file, I always got the following response:

"The bandwidth or page view limit for this site has been exceeded and
the page cannot be viewed at this time. Once the site is below the
limit, it will once again begin serving as normal."

Post by Tomas R
1: Oh, my. No chance you (or who ever) moves FWTools to Net2 and
possibly Win64 soon? I guess it is possible for me, on a XP 32 bit, to
compile it all to Win64 but it is unknown territory for me.
What would I need to recompile? Just the files the C# wrapper directly
interact with (gdal, gdalwarp, osr, ogr, gdalconst, mapscript) or all
(!) files of the FWTools package I may need? Which I actually need of
those - no idea.
2: Quick, dirty and may work. I will give it a try but, as you indicate,
it is far from a perfect solution. Took some time but I finally found
http://www.thescripts.com/forum/thread755379.html
Will give the Vista 64 user a version with the flag set and see if it
works.

I'm afraid I couldn't express my priorities properly. I would support
option 2 much better than option 1. I'm saying this because compiling
some parts of the gdal is much painful, some of those (like SDE)
cannot be compiled at all. You also have to compile such way the
dependent libraries as well, and I guess some of those have no WIN64
support either.
However I'll be trying to put together a GDAL WIN64 wiki for reference.


Best regards,

Tamas

[Tomas R]

Google Pages seems not to be ideal to act as place from where others can
download files. Not at all.

Try this address instead:
http://goto.glocalnet.net/stfiles/GDALPlugin_source.zip
No bandwidth limit there. None that I know of at least (space given by
my ISP).

Did try number 2. No success. When user tried to use that version of the
DLL SportTracks didn't even bother to try to load the plugin. I guess
there is some complex interaction between different version of .Net
libraries. Or whatever.

The roundabout time is not to big, the user is quite fast at trying my
patches but still, if it is not much to ask of you, could you try and
see if you can get my plugin to play along nicely with both SportTracks
and GDAL? Could it perhaps work if I target the project to .Net3.5?

Or if SportTracks were to be compiled with the flag perhaps...

Should perhaps mention that with the x86-flag set the plugin functions
as usual on my computer. No difference whatever .Net version I target it
on. Well, I do almost nothing in the code so not much can go wrong there.

Yours
tired Tomas signing out

Post by Tamas Szekeres

Post by Tomas R
Oh, thanks for testing my plugin. Really appreciate your assistance!
http://mapplugin.googlepages.com/GDALPlugin_source.zip
Excluded are ALL DLLs from FWTools, just to keep down the size. I guess
you have those. Copy all DLL files in FWTools\bin to the folder GDALBin
in the project and set all files to be copied to target. Probably you
also have to set the target folder of the build to another location
since it is set to the location of the installation of SportTracks on my
computer.

"The bandwidth or page view limit for this site has been exceeded and
the page cannot be viewed at this time. Once the site is below the
limit, it will once again begin serving as normal."

Post by Tomas R
1: Oh, my. No chance you (or who ever) moves FWTools to Net2 and
possibly Win64 soon? I guess it is possible for me, on a XP 32 bit, to
compile it all to Win64 but it is unknown territory for me.
What would I need to recompile? Just the files the C# wrapper directly
interact with (gdal, gdalwarp, osr, ogr, gdalconst, mapscript) or all
(!) files of the FWTools package I may need? Which I actually need of
those - no idea.
2: Quick, dirty and may work. I will give it a try but, as you indicate,
it is far from a perfect solution. Took some time but I finally found
http://www.thescripts.com/forum/thread755379.html
Will give the Vista 64 user a version with the flag set and see if it
works.

I'm afraid I couldn't express my priorities properly. I would support
option 2 much better than option 1. I'm saying this because compiling
some parts of the gdal is much painful, some of those (like SDE)
cannot be compiled at all. You also have to compile such way the
dependent libraries as well, and I guess some of those have no WIN64
support either.
However I'll be trying to put together a GDAL WIN64 wiki for reference.
Best regards,
Tamas

[Tamas Szekeres]

Yes I can see that the .NET framework 2.0 x64 cannot load assemblies
compiled with the x86 option, definitely. Funny enough that the x64
2.0 framework can work along with the 1.1 version pretty well but our
FWTools bundle has 32 bit images so this option is not usable either
as you have experienced before.

I've recompiled your project with my 64 GDAL compilation and it seems
working well. I've uploaded the modified project and the binaries.
Currently I've included only the gdal and the proj4 related files.

http://vbkto.dyndns.org:1280/GDALPlugin/GDALPlugin_sourcex64.rar
http://vbkto.dyndns.org:1280/GDALPlugin/GDALPluginx64.rar

Best regards,

Tamas

Post by Tomas R
Google Pages seems not to be ideal to act as place from where others can
download files. Not at all.
http://goto.glocalnet.net/stfiles/GDALPlugin_source.zip
No bandwidth limit there. None that I know of at least (space given by
my ISP).
Did try number 2. No success. When user tried to use that version of the
DLL SportTracks didn't even bother to try to load the plugin. I guess
there is some complex interaction between different version of .Net
libraries. Or whatever.
The roundabout time is not to big, the user is quite fast at trying my
patches but still, if it is not much to ask of you, could you try and
see if you can get my plugin to play along nicely with both SportTracks
and GDAL? Could it perhaps work if I target the project to .Net3.5?
Or if SportTracks were to be compiled with the flag perhaps...
Should perhaps mention that with the x86-flag set the plugin functions
as usual on my computer. No difference whatever .Net version I target it
on. Well, I do almost nothing in the code so not much can go wrong there.
Yours
tired Tomas signing out

Post by Tamas Szekeres

Post by Tomas R
Oh, thanks for testing my plugin. Really appreciate your assistance!
http://mapplugin.googlepages.com/GDALPlugin_source.zip
Excluded are ALL DLLs from FWTools, just to keep down the size. I guess
you have those. Copy all DLL files in FWTools\bin to the folder GDALBin
in the project and set all files to be copied to target. Probably you
also have to set the target folder of the build to another location
since it is set to the location of the installation of SportTracks on my
computer.

"The bandwidth or page view limit for this site has been exceeded and
the page cannot be viewed at this time. Once the site is below the
limit, it will once again begin serving as normal."

Post by Tomas R
1: Oh, my. No chance you (or who ever) moves FWTools to Net2 and
possibly Win64 soon? I guess it is possible for me, on a XP 32 bit, to
compile it all to Win64 but it is unknown territory for me.
What would I need to recompile? Just the files the C# wrapper directly
interact with (gdal, gdalwarp, osr, ogr, gdalconst, mapscript) or all
(!) files of the FWTools package I may need? Which I actually need of
those - no idea.
2: Quick, dirty and may work. I will give it a try but, as you indicate,
it is far from a perfect solution. Took some time but I finally found
http://www.thescripts.com/forum/thread755379.html
Will give the Vista 64 user a version with the flag set and see if it
works.

I'm afraid I couldn't express my priorities properly. I would support
option 2 much better than option 1. I'm saying this because compiling
some parts of the gdal is much painful, some of those (like SDE)
cannot be compiled at all. You also have to compile such way the
dependent libraries as well, and I guess some of those have no WIN64
support either.
However I'll be trying to put together a GDAL WIN64 wiki for reference.
Best regards,
Tamas

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Tomas R]

Seems to be working, reports back Version 1.6.0Dev released 2008/00/00.

Have now created a small test plugin to test if my custom map plugin,
which relies on GDAL to work, will work with this minimalistic GDAL
distribution.

If I do a try on my computer, removing all files but my current versions
of the file you have provided in 64 bit versions, nothing at all works.
Can't even retrieve version number. Perhaps caused by the fact that it
is a version targeted for FWTools.

I will have to wait on my guinea pig for the actual results.One result
back as I am writing this, number 2 below works. Number 1 not tested,
some strange error in my code stops the execution before any call to
GDAL is made.

In essential, what I need to be able to do, the use my map plugin has of
GDAL are:
1: Set up a pair of spatial references (OSGeo.OGR), by use of EPSG or
WKT strings, and use in a CoordinateTransformation.
2: Read images/bitmaps from various file formats. Using code close to
the SaveBitmapDirect example found in the C# tutorial files.

In short - what functionality do the FWTools libraries contribute with?
Perhaps I can skip them and just distribute the GDAL binaries and the
proj4 binary? Would that be enough for what I wish todo? And for the
elevation plugin to perhaps? But the I would need to compile GDAL
myself. Or?

Another plugin which uses GDAL is one which retrieves elevation data
from files partly by use of GDAL. No idea what it actually do or how
(DEM files?). Will have to wait a week to test his calls since he is
away on vacation now.


Yours
Tomas

Post by Tamas Szekeres
Yes I can see that the .NET framework 2.0 x64 cannot load assemblies
compiled with the x86 option, definitely. Funny enough that the x64
2.0 framework can work along with the 1.1 version pretty well but our
FWTools bundle has 32 bit images so this option is not usable either
as you have experienced before.
I've recompiled your project with my 64 GDAL compilation and it seems
working well. I've uploaded the modified project and the binaries.
Currently I've included only the gdal and the proj4 related files.
http://vbkto.dyndns.org:1280/GDALPlugin/GDALPlugin_sourcex64.rar
http://vbkto.dyndns.org:1280/GDALPlugin/GDALPluginx64.rar
Best regards,
Tamas

Post by Tomas R
Google Pages seems not to be ideal to act as place from where others can
download files. Not at all.
http://goto.glocalnet.net/stfiles/GDALPlugin_source.zip
No bandwidth limit there. None that I know of at least (space given by
my ISP).
Did try number 2. No success. When user tried to use that version of the
DLL SportTracks didn't even bother to try to load the plugin. I guess
there is some complex interaction between different version of .Net
libraries. Or whatever.
The roundabout time is not to big, the user is quite fast at trying my
patches but still, if it is not much to ask of you, could you try and
see if you can get my plugin to play along nicely with both SportTracks
and GDAL? Could it perhaps work if I target the project to .Net3.5?
Or if SportTracks were to be compiled with the flag perhaps...
Should perhaps mention that with the x86-flag set the plugin functions
as usual on my computer. No difference whatever .Net version I target it
on. Well, I do almost nothing in the code so not much can go wrong there.
Yours
tired Tomas signing out

Post by Tamas Szekeres

Post by Tomas R
Oh, thanks for testing my plugin. Really appreciate your assistance!
http://mapplugin.googlepages.com/GDALPlugin_source.zip
Excluded are ALL DLLs from FWTools, just to keep down the size. I guess
you have those. Copy all DLL files in FWTools\bin to the folder GDALBin
in the project and set all files to be copied to target. Probably you
also have to set the target folder of the build to another location
since it is set to the location of the installation of SportTracks on my
computer.

"The bandwidth or page view limit for this site has been exceeded and
the page cannot be viewed at this time. Once the site is below the
limit, it will once again begin serving as normal."

Post by Tomas R
1: Oh, my. No chance you (or who ever) moves FWTools to Net2 and
possibly Win64 soon? I guess it is possible for me, on a XP 32 bit, to
compile it all to Win64 but it is unknown territory for me.
What would I need to recompile? Just the files the C# wrapper directly
interact with (gdal, gdalwarp, osr, ogr, gdalconst, mapscript) or all
(!) files of the FWTools package I may need? Which I actually need of
those - no idea.
2: Quick, dirty and may work. I will give it a try but, as you indicate,
it is far from a perfect solution. Took some time but I finally found
http://www.thescripts.com/forum/thread755379.html
Will give the Vista 64 user a version with the flag set and see if it
works.

I'm afraid I couldn't express my priorities properly. I would support
option 2 much better than option 1. I'm saying this because compiling
some parts of the gdal is much painful, some of those (like SDE)
cannot be compiled at all. You also have to compile such way the
dependent libraries as well, and I guess some of those have no WIN64
support either.
However I'll be trying to put together a GDAL WIN64 wiki for reference.
Best regards,
Tamas

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Tamas Szekeres]

Post by Tomas R
In essential, what I need to be able to do, the use my map plugin has of
1: Set up a pair of spatial references (OSGeo.OGR), by use of EPSG or
WKT strings, and use in a CoordinateTransformation.
2: Read images/bitmaps from various file formats. Using code close to
the SaveBitmapDirect example found in the C# tutorial files.

I think only proj have to be included for option1, but option 2
depends on the data formats you actually use.

Post by Tomas R
In short - what functionality do the FWTools libraries contribute with?
Perhaps I can skip them and just distribute the GDAL binaries and the
proj4 binary? Would that be enough for what I wish todo? And for the
elevation plugin to perhaps? But the I would need to compile GDAL
myself. Or?

It would be healthy to compile it yourself and include only the
options you actually use. Then you'll have to deploy only the required
dll-s along with the plugin. This may provide you a similar .NET FW
2.0 compatible package for Win32 just like for Win64.
Recall that FWTools provides only .NET FW 1.1 compatible assemblies at
the moment.

Best regards,

Tamas

[Tomas R]

Healthy idea to compile GDAL myself. Not sure it would be so healthy for
me...It is nice to use FWTools. Very nice since I don't have to worry
about what I need or not need.

File formats I need to support? Well, whatever the user of my plugin
chooses to use! Png, gif, tiff, jpeg, rik, geotiff, Jpeg2000..
whatever.. The file formats listed here:
http://www.gdal.org/formats_list.html
are those the ones GDAL internally support?


Oh, f_ck. I will give it a try. I guess spend half a day or so to
download what I need and a couple of hours more to get it all to work. I
guess I won't be able to create a Win64 version on my computer? Or may I
not at all need a specific Win64 version if I remove all FWTools stuff?
Proj4 - for Win32, just need to download from http://proj.maptools.org/
and include in the same folder as GDAL is in and GDAL finds it? Or an
option while building the project?

So - all in all, if I compile the gdal-project and the C# wrappers,
include the proj4 and then I should have all I need?

Thanks for your patience with me
/Tomas

Post by Tamas Szekeres

Post by Tomas R
In essential, what I need to be able to do, the use my map plugin has of
1: Set up a pair of spatial references (OSGeo.OGR), by use of EPSG or
WKT strings, and use in a CoordinateTransformation.
2: Read images/bitmaps from various file formats. Using code close to
the SaveBitmapDirect example found in the C# tutorial files.

I think only proj have to be included for option1, but option 2
depends on the data formats you actually use.

Post by Tomas R
In short - what functionality do the FWTools libraries contribute with?
Perhaps I can skip them and just distribute the GDAL binaries and the
proj4 binary? Would that be enough for what I wish todo? And for the
elevation plugin to perhaps? But the I would need to compile GDAL
myself. Or?

It would be healthy to compile it yourself and include only the
options you actually use. Then you'll have to deploy only the required
dll-s along with the plugin. This may provide you a similar .NET FW
2.0 compatible package for Win32 just like for Win64.
Recall that FWTools provides only .NET FW 1.1 compatible assemblies at
the moment.
Best regards,
Tamas

[Tamas Szekeres]

Post by Tomas R
Healthy idea to compile GDAL myself. Not sure it would be so healthy for
me...It is nice to use FWTools. Very nice since I don't have to worry
about what I need or not need.
File formats I need to support? Well, whatever the user of my plugin
chooses to use! Png, gif, tiff, jpeg, rik, geotiff, Jpeg2000..
http://www.gdal.org/formats_list.html
are those the ones GDAL internally support?

Some of the drivers are compiled in by default, however some of those
depend on external libararies that should be specified during the
compilation. This might involve the need of adding external dlls to
the package. Anyway you can use 'gdalinfo --formats' to see which
drivers are actually supported by the compilation.

Post by Tomas R
Oh, f_ck. I will give it a try. I guess spend half a day or so to
download what I need and a couple of hours more to get it all to work. I
guess I won't be able to create a Win64 version on my computer? Or may I
not at all need a specific Win64 version if I remove all FWTools stuff?
Proj4 - for Win32, just need to download from http://proj.maptools.org/
and include in the same folder as GDAL is in and GDAL finds it? Or an
option while building the project?

Hmmm. Without having VS2005 or later installed on a 64 bit operating
system it's quite difficult to compile for Win64. (There might be some
3rdpty cross compile tools that I'm not aware of).
Anyway I've just made the buildbot results available for download that
contain many of the binaries (including the executables) of the
development version on various platforms:

.NET FW 2.0 Win64:
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-full/package/bin.zip
.NET FW 2.0 Win32:
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80-full/package/bin.zip
.NET FW 1.1 Win32:
http://vbkto.dyndns.org:1080/gdal/szekerest-vc71-full/package/bin.zip

I don't think these are suitable for use in a production environment, though.

FYI: I'm planning to put some efforts in adding a limited set of the
Win64 binaries into the upcoming osgeo4w installer. For more
information about this topic see:
http://wiki.osgeo.org/wiki/OSGeo_Win32_Installer



Best regards,

Tamas

[Tomas R]

Thanks for the binaries. Have not tried them out, will do that tomorrow.
Instead I have spent some frustrating time (always a bit frustrating
compiling big c++ projects, getting all components you need) trying to
compile GDAL on Visual c++ 2005 Express. I have (tried) to follow the
instructions given on the web
(http://trac.osgeo.org/gdal/wiki/BuildingOnWindows) but building via
nmake on commandprompt failes at finding 'atlbase.h'. Yes I know, Win
SDK paths. have tried setting them. Building GDAL via the GUI, (project
7_1) works though.

Any tips on the use of nmake? What have I missed? Yes, I have set the
paths and called vsvars32.bat before nmake

And - this gives me the gdal dll. But, the rest (ogr_wrap.dll,
proj.dll)? How do I obtain those? Won't I need those, the dll's that are
included in the binaries you have provided so nicely below.

The build I have worked with is the latest official stable build, v 1.5.

And yes, the links on the page above needs to be updated.

/Tomas

Post by Tamas Szekeres
Anyway I've just made the buildbot results available for download that
contain many of the binaries (including the executables) of the
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-full/package/bin.zip
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80-full/package/bin.zip
http://vbkto.dyndns.org:1080/gdal/szekerest-vc71-full/package/bin.zip
I don't think these are suitable for use in a production environment, though.
FYI: I'm planning to put some efforts in adding a limited set of the
Win64 binaries into the upcoming osgeo4w installer. For more
http://wiki.osgeo.org/wiki/OSGeo_Win32_Installer
Best regards,
Tamas

[Tomas R]

ok, ogr_wrap.dll and some others come form swig-wrapper... ok. Then it
is perhaps only proj.dll I further need... perhaps. Will test the build
I have managed (gdal via VSE2005 GUI and swig via command prompt and nmake)

/Tomas

Post by Tomas R
Thanks for the binaries. Have not tried them out, will do that
tomorrow. Instead I have spent some frustrating time (always a bit
frustrating compiling big c++ projects, getting all components you
need) trying to compile GDAL on Visual c++ 2005 Express. I have
(tried) to follow the instructions given on the web
(http://trac.osgeo.org/gdal/wiki/BuildingOnWindows) but building via
nmake on commandprompt failes at finding 'atlbase.h'. Yes I know, Win
SDK paths. have tried setting them. Building GDAL via the GUI,
(project 7_1) works though.
Any tips on the use of nmake? What have I missed? Yes, I have set the
paths and called vsvars32.bat before nmake
And - this gives me the gdal dll. But, the rest (ogr_wrap.dll,
proj.dll)? How do I obtain those? Won't I need those, the dll's that
are included in the binaries you have provided so nicely below.
The build I have worked with is the latest official stable build, v 1.5.
And yes, the links on the page above needs to be updated.
/Tomas

Post by Tamas Szekeres
Anyway I've just made the buildbot results available for download that
contain many of the binaries (including the executables) of the
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80x64-full/package/bin.zip
http://vbkto.dyndns.org:1080/gdal/szekerest-vc80-full/package/bin.zip
http://vbkto.dyndns.org:1080/gdal/szekerest-vc71-full/package/bin.zip
I don't think these are suitable for use in a production environment, though.
FYI: I'm planning to put some efforts in adding a limited set of the
Win64 binaries into the upcoming osgeo4w installer. For more
http://wiki.osgeo.org/wiki/OSGeo_Win32_Installer
Best regards,
Tamas

[Tamas Szekeres]

Post by Tomas R
Thanks for the binaries. Have not tried them out, will do that tomorrow.
Instead I have spent some frustrating time (always a bit frustrating
compiling big c++ projects, getting all components you need) trying to
compile GDAL on Visual c++ 2005 Express. I have (tried) to follow the
instructions given on the web
(http://trac.osgeo.org/gdal/wiki/BuildingOnWindows) but building via
nmake on commandprompt failes at finding 'atlbase.h'. Yes I know, Win
SDK paths. have tried setting them. Building GDAL via the GUI, (project
7_1) works though.
Any tips on the use of nmake? What have I missed? Yes, I have set the
paths and called vsvars32.bat before nmake
And - this gives me the gdal dll. But, the rest (ogr_wrap.dll,
proj.dll)? How do I obtain those? Won't I need those, the dll's that are
included in the binaries you have provided so nicely below.

The csharp bindings should be compiled separately after the core gdal
have been compiled. Here is the corresponding wiki page:
http://trac.osgeo.org/gdal/wiki/GdalOgrCsharpCompile

Best regards,

Tamas

[Tomas R]

Thanks for all the help.

Everything up and running. A small miss in the environmental settings
after a quick fix it compiles without any trouble. (VSE2005)

No hurry, but, a how-to compile the 64-bit version using VSE2008 on
Vista would be nice :)

The 64 bit version of the library you have so kindly provided earlier
works just fine and should do fine for now.

Yours
Tomas

Post by Tamas Szekeres

Post by Tomas R
Thanks for the binaries. Have not tried them out, will do that tomorrow.
Instead I have spent some frustrating time (always a bit frustrating
compiling big c++ projects, getting all components you need) trying to
compile GDAL on Visual c++ 2005 Express. I have (tried) to follow the
instructions given on the web
(http://trac.osgeo.org/gdal/wiki/BuildingOnWindows) but building via
nmake on commandprompt failes at finding 'atlbase.h'. Yes I know, Win
SDK paths. have tried setting them. Building GDAL via the GUI, (project
7_1) works though.
Any tips on the use of nmake? What have I missed? Yes, I have set the
paths and called vsvars32.bat before nmake
And - this gives me the gdal dll. But, the rest (ogr_wrap.dll,
proj.dll)? How do I obtain those? Won't I need those, the dll's that are
included in the binaries you have provided so nicely below.

The csharp bindings should be compiled separately after the core gdal
http://trac.osgeo.org/gdal/wiki/GdalOgrCsharpCompile
Best regards,
Tamas