Opened 17 years ago

Closed 17 years ago

#1621 closed defect (fixed)

Unable to set GDAL data folder (use EPSG-data), C#-bindings

Reported by: tomasr Owned by: tamas
Priority: normal Milestone:
Component: CSharpBindings Version: unspecified
Severity: normal Keywords: GDAL_DATA
Cc: warmerdam

Description

Environment:

Gdal C# from FWTools 1.2.2 FWTools/bin on system PATH. Visual Studio Express 2005. GDAL is configurated by:

gdal.SetConfigOption("GDAL_DATA",@"C:\Program\FWTools1.2.2\data\");

and/or

gdal.PushFinderLocation(@"C:\Program\FWTools1.2.2\data\");

Try

SpatialReference source; 
source = new SpatialReference("");
int EPSG = 3021;
int res = source.ImportFromEPSG(EPSG);

and gets a 6 as result.

Look at process with FileMOn during init shows calls to a number of DLLS in GDALs collection. Most of them has at least one BUFFER OVERFLOW result.

When trying to set up the SpatialReference GDAL ignores the settings above, two paths are searched for the csv-files, two examples:
11:14:03 GdalTest1.vshos:3616 OPEN D:\Documents and Settings\Tomas\Mina dokument\Visual Studio 2005\Projects\GdalTest1\GdalTest1\bin\Debug\csv\horiz_cs.csv PATH NOT FOUND Options: Open Access: 00120189

11:14:03 GdalTest1.vshos:3616 OPEN D:\usr\local\share\epsg_csv\gcs.csv PATH NOT FOUND Options: Open Access: Read

I hope this is specific enough for you to be able to reproduce it.

Change History (6)

comment:1 by tamas, 17 years ago

Component: defaultCSharpBindings
Owner: changed from warmerdam to tamas

comment:2 by warmerdam, 17 years ago

Cc: tamas added
Keywords: GDAL_DATA added
Owner: changed from tamas to warmerdam
Status: newassigned

I have a vague suspicion that the CSVFilename() function used by epsg_fromepsg.cpp is getting called in libgeotiff instead of the one in gdal/port/cpl_csv.cpp. If this occured the finder location and GDAL_DATA setting would be ignored.

I will do a test of this with FWTools from python.

comment:3 by tamas, 17 years ago

Frank,

With the default csharp option we use static linking to the gdal libraries. The PushFinderLocation operates on some global data that is local for a particular dll. Therefore using gdal.PushFinderLocation will affect the variables in gdal_wrap.dll and will not affect the variables residing in osr_wrap.dll or ogr_wrap.dll.

In this regard we might want to consider altering the default settings and/or expose the CSL functions in osr.i and ogr.i as well. However I don't favour the first one too much with some other reasonings.

comment:4 by warmerdam, 17 years ago

Tamas,

Ah, I see the issue.

I think the Csharp bindings wrappers are going to need to link against a single core gdal dll instead of statically linking.

comment:5 by warmerdam, 17 years ago

Cc: warmerdam added; tamas removed
Owner: changed from warmerdam to tamas
Status: assignednew

comment:6 by tamas, 17 years ago

Resolution: fixed
Status: newclosed

I've changed the default option in trunk to build the csharp dll-s dynamically to the gdal libraries. (Changeset r11458)

Note: See TracTickets for help on using tickets.