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 http:
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 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
much !
Tamas,
Coul
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 appropria
2011/1/25 Jason Roberts
> 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 the installers to
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
> 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 +
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
t
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 vei
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 ta
On 2011-01-26 00:19:52 +0100, Christopher Barker said:
I only see that in commented out code -- so that may be from when gdal
was imported differently.
Uff, sorry for the noise. It's late here, need to go to bed.
But thanks for the help!
Michael
_
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 utiliti
I didn't think we were discussing platform-independent solution for linking
bindings with the GDAL libs, as different operating systems have radically
different installation locations. The existing platform-independent way to do
it is to put GDAL's binary directory in the PATH. That is what I th
15 matches
Mail list logo