Hi,
It appears that my calls to RasterIO are about 10 times slower on
Windows than Linux when reading from the same dataset. I wouldn't
think that there would be a noticeable difference. Has anyone else
seen this? Is it possible that the overviews aren't being used on
Windows? Is there anyway
So, just like you immediately find something you've lost right after you
buy its replacement, about 15 minutes after posting this question I
discovered the solution. I didn't realize it but my fresh OS install
had the rpm versions of libdap on it. So even though the linker knew
about the vers
I'm having the same problem described in this posting to the mailing
list: http://lists.osgeo.org/pipermail/gdal-dev/2009-July/021247.html.
I've tried a variety of versions of gdal and libdap but I get the same
result each time. My OS is a fresh install of Centos 5.4 and my most
recent compil
>Folks,
>I would note that large -wm values can be very counter productive when
>used in combination with SKIP_NOSOURCE. The problem is that the larger
>the chunk size, you run into the chance that a large window will intersect
>a small amount of data and the whole window ends up being processed
Folks,
I have prepared a new OSGeo4W "gdal-dev" package capturing the state
of GDAL as of lunchtime today. This is a windows package as part of
OSGeo4W. To use it install OSGeo4W and in the advanced install add
the "gdal-dev" package. Then in the OSGeo4W command shell type "gdaldev"
to switch
Hi Alan,
This doesn't fix you problem specifically, but may help.
We usually use the packages from the OpenSuse Geo repository, which has SLES
specific builds available. (We are using SLES for most Linux servers in our
organisation)
See: http://download.opensuse.org/repositories/Application:
Alans wrote:
>
>
>
> Frank Warmerdam wrote:
>>
>>
>> This is very odd - I've never seen something quite like it.
>>
>> One work around would likely be to configure GDAL --without-libtool. I
>> wonder if 1.6.3 got released with an unstable libtool version. Could you
>> try 1.6.2 on this s
Frank Warmerdam wrote:
>
>
> This is very odd - I've never seen something quite like it.
>
> One work around would likely be to configure GDAL --without-libtool. I
> wonder if 1.6.3 got released with an unstable libtool version. Could you
> try 1.6.2 on this system and see if that works?
>
Alans wrote:
I am trying to build gdal on SUSE LINUX Enterprise Server 10 and I get the
following error. I have tried 1.6.3 and the latest daily build. Both give
the same error.
a...@stratford:~/gdal/gdal-1.6.3 47% gmake
(cd port; gmake)
gmake[1]: Entering directory `/nashome/alan/gdal/gdal-1.6.
I am trying to build gdal on SUSE LINUX Enterprise Server 10 and I get the
following error. I have tried 1.6.3 and the latest daily build. Both give
the same error.
a...@stratford:~/gdal/gdal-1.6.3 47% gmake
(cd port; gmake)
gmake[1]: Entering directory `/nashome/alan/gdal/gdal-1.6.3/port'
/bin/s
On Thu, 10 Dec 2009, Roger Bivand wrote:
On Thu, 10 Dec 2009, Even Rouault wrote:
Roger,
this is weird indeed as I use daily MSYS on trunk... I'd bet that you have
an
installed version of cpl_string.h in /usr/local/include that corresponds to
the
1.6.3 version that didn't have the CPLIsUTF8
On Thu, 10 Dec 2009, Even Rouault wrote:
Roger,
this is weird indeed as I use daily MSYS on trunk... I'd bet that you have an
installed version of cpl_string.h in /usr/local/include that corresponds to the
1.6.3 version that didn't have the CPLIsUTF8 and CPLForceToASCII symbols. If
you've done
Roger,
this is weird indeed as I use daily MSYS on trunk... I'd bet that you have an
installed version of cpl_string.h in /usr/local/include that corresponds to the
1.6.3 version that didn't have the CPLIsUTF8 and CPLForceToASCII symbols. If
you've done a make install when building 1.6.3 before,
Hi,
I've probably missed something, but while 1.6.3 builds OK with EXPAT for
GPX on MSYS, 1.7.0 revision 18238 doesn't. The problem is in:
libtool: compile: g++ -O2 -Wall -I.. -I../.. -I/usr/local/include
-I/home/s1155 /gdal_svn/gdal/port -I/home/s1155/gdal_svn/gdal/gcore
-I/home/s1155/gdal
14 matches
Mail list logo