[Gdal-dev] Re: Problem using EPSG in C#

[Tomas R]

Again I was a bit to quick when reporting success.
Yes, now I am able to create a SpatialReference from an EPSG code and 
from Proj4 (not tested WKT)
And I am able to create a CoordinaTransform object from those 
spatialreferences.
But I'm not able to perform an actual coordinate transformation, an 
exception is thrown (trying to read or write to  protected (in 
ogr_sharp.dll).

So, again I ask:
Have I missed some step or is it still something in GDAL that doesn't work?

/Tomas

Tomas R skrev:
> Ok Tamas, it kind of works...
> 
> I followed the steps you have described for me and those I found on the 
> Wiki:
> 1: Downloaded latest trunk
> 2: Compiled  GDAL (how many of the steps must I do? All? Or just the 
> first, I guess just the first)
> 3: Created the C# interface and compiled it.
> 4: Copied the resulting *_wrap.dlls to Fwtool1.3.0\bin folder
> 5: Added the new CSharp-dlls to my C# project.
> 6: Checked that the system path contains FWTools1.3.0\bin folder
> If I try running my project after those steps I get an exception when 
> trying to call GDAL, whatever *_wrap.dll that is called is not found/not 
> possible to load.
> 
> When I add the wrap-dlls to the "root" of my C#-project, no apparent 
> change.
> When I copy the GDAL-dll to my projects root and include it in the 
> build, together with the wrap-dlls, it works!
> But is this how it now is supposed to be? I guess I with this setup can 
> use GDALs basic function but all the functions which rely on other libs 
> (which I have not tested/any knowledge of yet) are not available? For 
> example reading and writing of GeoTiff images? (That is possible via the 
> C#-bindings?)
> For now I think I'm content with coordinate translation but I think I 
> want to try how efficient GDAL is to use when importing maps of 
> different formats. It would be nice to be able to rip directly from 
> GeoTiff (or RIK) with GDAL.
> 
> Perhaps a bit OT but:
> In basic it boils down to that I have now not a clear idea how to 
> distribute the plugin I am building. Demand that FWTools are installed 
> or include the nessecary dlls? O well, there is time left to think about 
> that.
> 
> /Tomas
> 
> Tamas Szekeres skrev:
>> Oops!  Some recent changes in gdal have been interfering with this
>> setting. I've now fixed up the problem in the gdal-trunk and set the
>> default option to link the C# dll-s dynamically to the gdal libraries.
>> Please, checkout the latest version and repeat your tests.
>>
>> It must be noted that after this change the gdal14.dll should be
>> available to load when running the application or the 'nmake -f
>> makefile.vc test' target.
>>
>> Best regards,
>>
>> Tamas
>>
>>
>> 2007/5/10, Tomas R <monshi at home.se>:
>>> I thought  I had the issue solved, that I had managed to compile the
>>> correct C# bindings and so on.
>>>
>>> But, sadly no.
>>> What have I got?
>>> FWtools 3.0
>>> Gdal source, from the latest Trunk
>>> Got the whole SDK-kit from MS, Swig 1.3.31 and Visual Studio Express C++
>>>
>>> I manage to compile the whole GDAL-project. I manage to compile C#
>>> bindings with CSHARP_STATIC_LINKAGE = YES and CSHARP_STATIC_LINKAGE = NO
>>> but NOT with it commented out.
>>> The compile with CSHARP_STATIC_LINKAGE = NO do not seem to affect the
>>> result as would be needed. When I try to set up a SpatialReference with
>>> an EPSG-code I still get a 6.
>>>
>>> With CSHARP_STATIC_LINKAGE  commented out the compilation halts when
>>> creating gdal_wrap.dll:
>>> > LINK : gdal_wrap.dll not found or not built by the last incremental 
>>> link; perfor
>>> > ming full link
>>> >    Creating library gdal_wrap.lib and object gdal_wrap.exp
>>> > gdal_wrap.obj : error LNK2019: unresolved external symbol 
>>> _GDALIdentifyDriver at 8
>>> > referenced in function "void * __cdecl IdentifyDriver(char const 
>>> *,char * *)" (?
>>> > IdentifyDriver@@YAPAXPBDPAPAD at Z)
>>> > gdal_wrap.dll : fatal error LNK1120: 1 unresolved externals
>>> > NMAKE : fatal error U1077: '"C:\Program\Microsoft Visual Studio 
>>> 8\VC\BIN\link.EX
>>> > E"' : return code '0x460'
>>> > Stop.
>>>
>>> Why is it never as simple? Do I miss something?
>>>
>>> /Tomas
>>>
>>>
>>> Tamas Szekeres skrev:
>>> > Tomas,
>>> >
>>> > You'll have to comment out the
>>> > CSHARP_STATIC_LINKAGE = YES
>>> > in csharp.opt and recompile the C# interface. Using this setting the
>>> > csharp dll-s will link against the gdal14.dll so the
>>> > PushFinderLocation and ImportFromEPSG will operate on the same global
>>> > data. In the future I consider to use this setting as the default
>>> > option.
>>> >
>>> > BTW: I would propose to use the latest development version of the C#
>>> > related stuff. There were some fundamental changes in the interface
>>> > that might cause some changes in the existing code. For more
>>> > information see:
>>> > http://trac.osgeo.org/gdal/wiki/GdalOgrCsharpVersions
>>> >
>>> > You might also use the binaries of the latest FWTools
>>> > http://test.gdal.org/fwtools/FWTools130.exe
>>> > and replace the *_wrap.dll-s and *_csharp.dll-s inside with the
>>> > compiled version.
>>> >
>>> > Best regards,
>>> >
>>> > Tamas
>>> >
>>> >
>>> >
>>>
>>> _______________________________________________
>>> Gdal-dev mailing list
>>> Gdal-dev at lists.maptools.org
>>> http://lists.maptools.org/mailman/listinfo/gdal-dev
>>>