0

I recently gave up trying to get the gisinternals versions of GDAL's Python bindings to work, and sought instead to use the 'gohlke' approach - getting the appropriate wheel from the UCI repository.

For me, the 'appropriate' whl was GDAL-2.0.2-cp27-none-win32.whl, as I am running 32-bit Python 2.7.11.

When I was using the gisinternals version, I had used gdal-201-1500-core.msi for the core, and GDAL-2.1.0.win32-py2.7.msi for the Python bindings. My Python is compiled against MCSV1500, as is evident below.

Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)] on win32

Having installed the gisinternals stuff I did tout ce qu'il faut: i.e.,

  • added GDAL_DATA to the environment with value C:\Program Files (x86)\GDAL\gdal-data (having verified that was the directory)
  • put C:\Program Files (x86)\GDAL at the start of the PATH

GDAL and OGR ran perfectly from the command line, ogrinfo --version gave the right version, and I thought I was off to the races.

Then I tried to run a Python script that tried to import ogr - fail (same for from osgeo import ogr.

I checked double-checked, triple-checked and so forth, and eventually gave up and ditched the gisinternals stuff.

I have set the gisinternals Python bindings up before in such a way that they worked against Python 2.7.3 MCSV1500 and GDAL 1.1, and I was looking var by var at the two machines and there was literally no difference in the PATH or GDAL_DATA variables (since Python and GDAL paths on the two machines were the same: C:\Python27 and C:\Program Files (x86)\GDAL).

OK - long story even longer, I downloaded the whl referred to above, and pip-ed it into place without drama.

Then I fired up Python, typed import ogr, and everything worked.

Enthused almost beyond the human capacity for joy, I opened a ConEMU window and typed ogrlinfo --version, and got the dreaded "OG-what? Never heard of it" message.

I figured that the 'gohlke' package must have put GDAL somewhere other than C:\Program Files (x86)\GDAL - so off I went to find it and amend that PATH and GDAL_DATA variables as appropriate.

And here's the thing: I don't have any GDAL folder anywhere, it seems.

So - finally - the questionS:

  1. Are those who install the Gohlke GDAL, effectively giving up any hope of being able to use GDAL/OGR at the command line? That seems unlike something that's intended, but I've never seen any reference to command-line use of GDAL installed by the 'gohlke' route.

  2. Second question - in the hope that I've got screen-hypnosis and looked straight past teh Gohlke GDAL folder... does Gohlke's whl install GDAL to a non-standard folder? [UPDATE: Yes. Yes, it does. See self-answer below]

GT.
  • 858
  • 9
  • 19
  • 3
    Both the Gohlke and GIS Internals distributions of gdal work fine for me, both command line utilities and python bindings. The gohlke utilities can be found in your python install dir/lib/site-packages/osgeo. – user2856 Jun 14 '16 at 10:27

1 Answers1

2

@Luke's comment led me to the Python\Lib\site-packages\osgeo folder, and I noticed immediately that it had a directory structure that looked familiar.

Two levels further in (in C:\Python27\Lib\site-packages\osgeo\data\gdal) I was looking at all the csv files that GDAL looks for in GDAL_DATA.

So, I amended the PATH to include C:\Python27\Lib\site-packages\osgeo and changed the GDAL_DATA environment var to C:\Python27\Lib\site-packages\osgeo\data\gdal\.

Opened a conEMU box, typed gdalinfo --version, and got two error messages about a missing DLL (which is there, but who cares), and then successful execution.

> gdalinfo --version
ERROR 1: Can't load requested DLL: C:\Python27\Lib\site-packages\osgeo\gdalplugins\ogr_FileGDB.dll
126: The specified module could not be found.

ERROR 1: Can't load requested DLL: C:\Python27\Lib\site-packages\osgeo\gdalplugins\ogr_FileGDB.dll
126: The specified module could not be found.

GDAL 2.0.2, released 2016/01/26

The DLL in question is unambiguously there - here's pics ... Pic showing 'missing' DLL< existing right where GDAL thinks it oughtta be

Then I ogrinfo -so -al'd a nearby TAB file. ogrinfo prefaced a correct answer with the same 'cannot be found' error message, three times instead of 2.

It's never good to trust an installation that throws an error like that, so I set GDAL_DRIVER_PATH to C:\Python27\Lib\site-packages\osgeo\gdalplugins. When that didn't work I dug a bit more.

It's resolved by moving the DLL out of \gdalplugins: see this question and this answer, both of which I upvoted.

Copying the DLL out of \plugins and into \osgeo (leaving GDAL_DRIVER_PATH at C:\Python27\Lib\site-packages\osgeo\gdalplugins) worked.

Community
  • 1
GT.
  • 858
  • 9
  • 19
  • 9
    No, the error message is not caused by gdal/ogr being unable to find ogr_FileGDB.dll. It is caused by the ogr_FileGDB.dll not being able to find the Esri FileGDBAPI.dll. What you've done is move ogr_FileGDB.dll to a folder where gdal/ogr won't try to load it. You could have also deleted it or moved it to a folder called gdalplugins.disabled (or anything else really). I wouldn't leave it hanging around in your osgeo folder though. – user2856 Jun 15 '16 at 00:03