[Gdal-dev] Re: Problem using EPSG in C#
Tamas Szekeres
szekerest at gmail.com
Fri May 11 18:15:00 EDT 2007
Tomas,
I couldn't find out what is the actual value of your WGS variable in
SpatialReference wgs84 = new SpatialReference(WGS);
In addition CoordinateTransformation(wgs84, wgs84); doesn't seem to do
anything with the coordinate values.
Here is my equivalent code that worked:
int rtX = 1620000;
int rtY = 6597000;
Gdal.SetConfigOption("GDAL_DATA",@"C:\Program
Files\FWTools1.3.0\data");
Gdal.PushFinderLocation(@"C:\Program Files\FWTools1.3.0\data");
SpatialReference source = new SpatialReference("");
int res = source.ImportFromEPSG(3021);
string srcTest, dstTest;
source.ExportToWkt(out srcTest);
Console.WriteLine(srcTest);
SpatialReference wgs84 = new SpatialReference("");
wgs84.SetWellKnownGeogCS("WGS84");
wgs84.ExportToWkt(out dstTest);
Console.WriteLine(dstTest);
CoordinateTransformation toWGS = new
CoordinateTransformation(source, wgs84);
double[] data = new double[3];
toWGS.TransformPoint(data, rtX, rtY, 0);
Console.WriteLine(data[0].ToString() + " " +
data[1].ToString());
However your memory corruption issue is somewhat frustrating, do you
have a call stack for this error?
Best regards,
Tamas
2007/5/11, Tomas R <monshi at home.se>:
> I have received two answers in my mailbox but don't see them here. I
> reply to one of them:
> 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
>
>
> This was in answer to
> > Could you post your example that produces this behaviour? I haven't
> > found this issue when using a similar test you have mentioned.
> >
> > Tamas
>
>
>
> Tomas R skrev:
> > 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