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

[Tomas R]

Ok, thanks for the educating response.

What I am developing is a plugin for SportTracks. In simple terms it 
will act as an alternative source of maps to Google Earth and provide 
translation from/to the maps local projection to WGS84. This will also 
include a mechanism to import the maps into such a format it will be 
easy and fast to read and handle. It will be a local "server" to 
SportTracks providing SportTracks with maps the user has provided.

Some Q's arises from what you have written:
Anyway to single out which DLLs that provide the functions I need?
If I use my own build of gdal will the dll have the necessary bindings 
to the dll-files distributed with FWtool?
But on the other hand I guess I can, in the next release of FWTool, grab 
the whole bunch of dlls and data-files and use them. This solution is  
only for a short  time, I will not have to compile gdal myself after 
FWTool has been upgraded.

And is it necessary to set the system path to make it possible for the 
Csharp bindings to find the gdal dll? It isn't possible to find them by 
a path stored/computed by my code?

Perhaps worth noting, the trunk revision  I have tested with is the one 
after your last edit, i.e. revision 11458.

/Tomas

Tamas Szekeres skrev:
> 2007/5/11, Tomas R <monshi at home.se>:
>> 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!
>
> I my previous letter I've noted that with this setting the *_wrap.dll
> will link to the gdal14.dll therefore this dll should also be
> available for your application to load.
> In my personal opinion if you would distribute your app with this
> functionality you might include these dll-s in your package.
> Apparently, in the same folder where your application resides.
>
>> 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.
>>
>
> Most of the functionality of the GDAL/OGR core is exposed to the C#
> interface. But indeed many of them might require further dll-s to
> include (can normally be found in the FWTools/bin directory). In this
> case you might add these dll in your application folder as well.
>
>> 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.
>>
>
> It depends on the architecture of the application. In fact all of the
> dll-s mentioned before should be available to load by the executable
> either by adding the location in the PATH environment or copying them
> in the application folder.
>
> Best regards,
>
> Tamas