My Python application uses GDAL and OGR internally. I install a private copy of GDAL with my app. I do not want to require the user to add GDAL's bin directory to the PATH. To work around this, I have been manually adding the directory to the PATH, importing the needed Python modules (e.g. osgeo.ogr), and removing the directory from the PATH.
This strategy has worked fine until I discovered a compatibility problem with ArcGIS, which my application also uses. Due to an apparent bug in Arc 9.3 SP1, when my application sets the PATH, a certain geoprocessing tool will crash if I call it later, even if I reset the PATH to what it was before. It does not matter what I set the PATH to-I can set it to its current value, theoretically leaving it unchanged-the Arc tool will always crash. So now I'm seeking an alternative, because getting ESRI to fix bugs like this is generally a lost cause. My alternative strategy is: 1. Do not mess with the PATH environment variable at all. 2. Explicitly LoadLibrary gdal16.dll by calling Python win32api.LoadLibrary (must call SetDllDirectory first, as well) 3. Import the Python modules So, in essence, I am wondering: to have the GDAL and OGR classes work properly, can I just load gdal16.dll explicitly before trying the Python bindings, rather than adding the GDAL bin directory to the PATH? >From testing, it looks like it works, but I wanted to check with you to be sure. I know this is kludgy but I am sadly accustomed to developing such workarounds when dealing with ArcGIS... Thanks for your help, Jason
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
