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 , 17 years ago
Component: | default → CSharpBindings |
---|---|
Owner: | changed from | to
comment:2 by , 17 years ago
Cc: | added |
---|---|
Keywords: | GDAL_DATA added |
Owner: | changed from | to
Status: | new → assigned |
comment:3 by , 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 , 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 , 17 years ago
Cc: | added; removed |
---|---|
Owner: | changed from | to
Status: | assigned → new |
comment:6 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I've changed the default option in trunk to build the csharp dll-s dynamically to the gdal libraries. (Changeset r11458)
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.