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

[Tamas Szekeres]

Could you post your example that produces this behaviour? I haven't
found this issue when using a similar test you have mentioned.

Tamas


2007/5/11, Tomas R <monshi at home.se>:
> 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
> >>>
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>