python - Does Gohlke GDAL break Command-Line GDAL/OGR in Windoiws?

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]

   
   

Answer

@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 ...

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.