[Gdal-dev] Re: Problem using EPSG in C#
Tomas R
monshi at home.se
Fri May 11 11:36:37 EDT 2007
The code I use to produce the error is:
> int rtX = 1620000;
> int rtY = 6597000;
> Gdal.SetConfigOption("GDAL_DATA",
> @"C:\Program\FWTools1.3.0\data");
> Gdal.PushFinderLocation(@"C:\Program\FWTools1.3.0\data");
> SpatialReference source = new SpatialReference("");
> int res = source.ImportFromEPSG(3021);
> string srcTest, dstTest;
> source.ExportToWkt(out srcTest);
> put(srcTest);
> SpatialReference wgs84 = new SpatialReference(WGS);
> wgs84.ExportToWkt(out dstTest);
> put(dstTest);
>
>
> CoordinateTransformation toWGS = new
> CoordinateTransformation(wgs84, wgs84);
> double[] data = new double[3];
> toWGS.TransformPoint(data, rtX, rtY, 0);
> put(data[0].ToString() + " " + data[1].ToString());
Where Put is just a call to a routine which displays the text on screen.
Without gdal14.dll or all the wrapper dlls included in the project the
code halts at first call to Gdal. With the wrappers and the gdal dll
included in the project the SpatialRefernces are correctly initialized
(wgs from a WKT-string, just for testing, source from ESPG (have tested
other than RT90)) but instead it halts at call to TransformPoint. The
exceptions InnerException is null, error in OGR/OSR_sharp.dll. I have
tested with both reference to OGR and OSR.
I have also tried copying all dlls from FWTool to the project but with
no difference.
Thank you for your help! The time you take to clear this up is highly
appreciated!
Yours
Tomas
Tamas Szekeres skrev:
> 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
>>
More information about the Gdal-dev
mailing list