On Apr 24, 2009, at 6:40 PM, Chris Garrard wrote:
I've compiled GDAL 1.6.0 on Solaris 10, and most everything seems to
work fine. However, I need Python support, but I get the following
error when I try to import the gdal module:
>>> from osgeo import gdal
Traceback (most recent call last
I've compiled GDAL 1.6.0 on Solaris 10, and most everything seems to work
fine. However, I need Python support, but I get the following error when I
try to import the gdal module:
>>> from osgeo import gdal
Traceback (most recent call last):
File "", line 1, in
File "/opt/csw/lib/python2.5/s
hi list,
OS: Windows, Python binding: old generation, Compiler: MSVS 2005 (MSVC
8)
I have built Gdal-1.6.0 using older MSVC++ 6 (python 2.4) and ran it for
2 months without problem.
Now I am building Gdal-1.6.0 using MSVC 8 and python 2.5. Everything
else stayed the same. Build went fine.
But
All,
I would like to step forward as release manager for the 1.6.1 release,
and I would like to produce the 1.6.1RC1 on May 8th. Consider this
your notice to complete any bugs or backports for the 1.6 branch.
http://trac.osgeo.org/gdal/milestone/1.6.1
Howard
__
Hi everybody
does anybody know if the tools like gdal_translate have a config
parameter that allows to specify the directory used for the tmp files
when creating ECW files? I made some tests on Linux and no environment
vars like TMP, TEMP or TMPDIR were taken into account when creating the
EC
Hi Frank,
I think the problem we're having is with this, "It does imply a single
row/column of overlap with adjacent grid squares but I believe that is
typical of distributed SRTM data." I guess we were expecting there to
be zero overlap and for the tiles to line up edge-to-edge.
Thanks,
Roger
Roger André wrote:
Morning,
I have a bit of a conundrum which I'm trying to find an answer for,
and which is prompting a certain amount of contentious debate at work.
I've downloaded a 1-deg x 1-deg SRTM tile from the GLCF site,
SRTM_f03_n007e000.tif. Now from its name, this tile should have i
How about gdaldem2image for a name? A little long, but less confusion over
what it actually does...
Matt Wilkie wrote:
Upon reflection, I think we should congregate these utilities into a
single utility -- gdaldem (I'm totally flexible on the name -- and
have each be a separate operation withi
Matt Wilkie wrote:
Upon reflection, I think we should congregate these utilities into a
single utility -- gdaldem (I'm totally flexible on the name -- and
have each be a separate operation within that rather than
proliferating five more GDAL utilities.
-- http://trac.osgeo.org/gdal/ticket/2640
It sounds to me like Matt Perry wants to hand over maintenance to
someone else (though I wouldn't be surprised if he put in a hand now and
again if he had commit access).
matt wilkie
Geomatics Analyst
Information Management and Technology
Yukon Depar
Upon reflection, I think we should congregate these utilities into a
single utility -- gdaldem (I'm totally flexible on the name -- and
have each be a separate operation within that rather than
proliferating five more GDAL utilities.
-- http://trac.osgeo.org/gdal/ticket/2640
I like the idea of
Morning,
I have a bit of a conundrum which I'm trying to find an answer for,
and which is prompting a certain amount of contentious debate at work.
I've downloaded a 1-deg x 1-deg SRTM tile from the GLCF site,
SRTM_f03_n007e000.tif. Now from its name, this tile should have its
origin at N 7, E 0
Motion: Grant Matthew Perry GDAL commit access to maintain his
excellent GDAL DEM tools in GDAL as utilities.
As described in http://trac.osgeo.org/gdal/ticket/2640 , I have begun
porting Matthew's utilities to the GDAL C API and including them in
GDAL. Matthew should be able to maintain t
On Wednesday 22 April 2009 22:24:02 Gong, Shawn (Contractor) wrote:
> hi list,
>
> I'd appreciate suggestions on Linux OS. We'd like to build newest gdal,
> as well as OpenEV2 using GTK2.
> Have tried CentOS. But it libraries seem too conservative.
>
> Is Fedora 9 a better choice?
>
> thanks,
> Sha
You should also add the directories of /bin and /gdal/csharp to your PATH
environment, or copy all the dll-s into your executing directory to make it
available to load by the application.
The gdalinfo csharp example is not equal to the C++ command line tool you
have to use the simple form:
gdalinf
Thanks for your reply.
I set the GDAL_DRIVER_PATH environment variable.
And I can execute gdalinfo.exe of C++ version.
In gdalinfo.exe of C# version, I cannot still execute it.
So, I tried to execute this command using other format (ex. GTIFF, HFA), it
was failed.
"ERROR 4: 'gtiff' does not
Sunny,
The HDF5 driver is compiled as a plugin. You have to put the corresponding
dll (gdal_HDF5.dll, gdal_HDF5Image.dll) from the /bin/gdal/plugins
directory to the /gdalplugins subdirectory from where your application is
running.
Alternatively you can set the GDAL_DRIVER_PATH environment variabl
17 matches
Mail list logo
