Hello list,
I have written a Python program to create ECW files. It is working fine under
Linux, but not under Windows XP.
I have installed :
- Python 2.6.6 (the official version)
- gdal-18-1500-core.msi
- gdal-18-1500-ecw.msi
- GDAL-1.8.0.win32-py2.6.exe
I downloaded the last three files at
Alain,
Do you have the GDAL_DRIVER_PATH environment variable set on your Windows
system?
C:\echo %GDAL_DRIVER_PATH%
C:\Apps\GDAL\bin\gdalplugins
That is what going to make the GDAL dll inside the Python process to find the
plugins. GDAL command line tools doesn't need that because they get it
--- On Tue, 1/25/11, Ivan Lucena ivan.luc...@pmldnet.com wrote:
Do you have the GDAL_DRIVER_PATH environment variable set
on your Windows system?
C:\echo %GDAL_DRIVER_PATH%
C:\Apps\GDAL\bin\gdalplugins
Ivan,
You are right, I forgot to set that variable. Now it is working. Thank you very
Alain
I think the solution that Tamas proposed for that problem is not to
automatically set the environment variables, but instead to modify the GDAL
core installer to store the installation location in the registry and then
have the Python bindings read it and initialize GDAL by calling
2011/1/25 Jason Roberts jason.robe...@duke.edu
Tamas,
Could you improve the Windows GDAL installer, so that it automatically sets
the environment variables (GDAL_DATA and GDAL_DRIVER_PATH), and adds the
GDAL binaries path to the PATH environment variable ?
I will do some improvements in
Tamas,
Are you still planning to implement the registry-based approach? I ask because
you seemed in favor of avoiding modifying PATH, if at all possible (a position
I agree with), and the registry approach would eliminate that need while still
making GDAL + bindings “just work”.
Thanks,
Hello,
I have a geotiff image which, according to its accompaning htm, uses the
WGS_1984 Datum.
However, when I call GDALGetProjectionRef() it fails, returning
GCS tag not found, plus
ENR_L01.tif (from ENR_L01.zip)
Failed to setup Geographic Coordinate System
FAILED with error: 2
gdalinfo
2011/1/25 Jason Roberts jason.robe...@duke.edu
Tamas,
Are you still planning to implement the registry-based approach? I ask
because you seemed in favor of avoiding modifying PATH, if at all possible
(a position I agree with), and the registry approach would eliminate that
need while
Rather than introduce a DLL into the system directory, why not statically link
the code into the bindings themselves, when possible? Or document the
appropriate logic for doing it with win32 functions (registry functions,
LoadLibrary, GetProcAddress) and allow the bindings to make those calls
Dear all,
I am puzzled how this function works in the current gdalinfo.py from here:
http://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/gdalinfo.py
because I can't see any 'import' that would make this function known?
Could somebody lift the veil for me? ;)
Best regards,
Michael
On 1/25/11 3:00 PM, K.-Michael Aye wrote:
Dear all,
I am puzzled how this function works in the current gdalinfo.py from here:
http://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/gdalinfo.py
because I can't see any 'import' that would make this function known?
Could somebody lift the
Hi list
I am using the python bindings to handle some HDF5 data.
Up until now I had been using another python module (pytables) to
access the file's metadata and then GDAL to do some further
processing, but I am trying to depend only on GDAL for this issue, as
it seems it might be enough for the
On 1/25/11 2:57 PM, Jason Roberts wrote:
Rather than introduce a DLL into the system directory, why not
statically link the code into the bindings themselves, when possible?
we did go through that, and it's one option, but for those of us that
use gdal with C programs, python, with the
13 matches
Mail list logo
