Hi Tamas,
I don't know how to apply the same principle onto OGR drivers (not GDAL).
I'm trying to create GML structure in memory using OGR driver, then handle
resulting XML string further. Don't want to write dataset to a file, then
read the file back to a string.
Regards,
Maksim Sestic
Selon Maksim Sestic :
> Hi Tamas,
>
>
>
> I don't know how to apply the same principle onto OGR drivers (not GDAL).
> I'm trying to create GML structure in memory using OGR driver, then handle
> resulting XML string further. Don't want to write dataset to a file, then
> read the file back to a str
t;
> Regards,
>
> Maksim Sestic
>
>
>
> __ Information from ESET NOD32 Antivirus, version of virus
signature
> database 6338 (20110731) __
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
Hi,
There is a well-know "problem": reading really large rasters or bands
into memory with DataSource.ReadAsArray() method impossible due
memory limitations. For example, when I try to read one band with
size 53109x29049 I get error:
File "C:\OSGeo4W\apps\Python25\lib\site-packages\osgeo\gdal.py"
Hi Alexander,
Il 03/08/2011 15:35, Alexander Bruy ha scritto:
> Hi,
>
> There is a well-know "problem": reading really large rasters or bands
> into memory with DataSource.ReadAsArray() method impossible due
> memory limitations. For example, when I try to read one band with
> size 53109x29049 I
I have been working on this problem as well. Initially, the attempt was to
ReadAsArray small chunks. Unfortunately this is quite inefficient. Someone
more knowledgeable will know why, but I suspect it has to do with either
thrashing or the fact that full blocks are not being read in (as is the c
Hi Jay,
Il 03/08/2011 16:53, Jay L. ha scritto:
> I have been working on this problem as well. Initially, the attempt was to
> ReadAsArray small chunks. Unfortunately this is quite inefficient. Someone
> more knowledgeable will know why, but I suspect it has to do with either
> thrashing or the
Hi everybody
I am trying to get python reading some hdf scenes from the fengyun
satellites. I hope gdal can do this task, but so far I never worked with
gdal nor ever compiled a library on my own.
Maybe there is someone to whom it would be not much of an afford to post (or
point me to) a step by s
You probably want to install FWTOOLS, which include gdal and support for python
and hdf4 - no need to compile anything.
http://fwtools.maptools.org/
http://fwtools.maptools.org/windows-package-notes.html
From: firetry
To: gdal-dev@lists.osgeo.org
Sent: Wedne
Le mercredi 03 août 2011 15:35:22, Alexander Bruy a écrit :
> Hi,
>
> There is a well-know "problem": reading really large rasters or bands
> into memory with DataSource.ReadAsArray() method impossible due
> memory limitations. For example, when I try to read one band with
> size 53109x29049 I get
Hi
2011/8/3 Antonio Valentino :
> In my experience using too large chunks of memory can cause,
> paradoxically, slowdowns.
> My suggestion is to define a reasonable maximum size for arrays in your
> application/library and switch to the "fallback algorithm for large
> rasters" every time that MAX_
Le mercredi 03 août 2011 17:32:53, Antonio Valentino a écrit :
> Hi Jay,
>
> Il 03/08/2011 16:53, Jay L. ha scritto:
> > I have been working on this problem as well. Initially, the attempt was
> > to ReadAsArray small chunks. Unfortunately this is quite inefficient.
> > Someone more knowledgeab
Evan,
To ensure that i understand here is an example:
If I have a GTiff, where the block size is one row by all of the columns (a
single scanline), I should try to read in either one scanline at a time, or
multiple entire scanlines. It is inefficient to take say 10 rows and only
half of the col
I tried to configure / make / make install libecwj for the iPhone OS using a
mac with gcc 4.2. Carbon.h came up as one of the missing files. I could go find
carbon and install it but I think it would be better to migrate the libecwj sdk
to components that exist on iOS. If I were to build a usefu
Le mercredi 03 août 2011 20:28:35, Jay L. a écrit :
> Evan,
>
> To ensure that i understand here is an example:
>
> If I have a GTiff, where the block size is one row by all of the columns
> (a single scanline), I should try to read in either one scanline at a
> time, or multiple entire scanline
In order to support the GDAL (1.8.1) jpipkak driver on Android, I also
need to include libcurl (7.21.7) support.
The inclusion of the curl library into the GDAL build is my current
stumbling block.
That is, I'm able to build and execute an Android app that can load my
driver and will run to
Le mercredi 03 août 2011 21:45:47, Jim Pendleton a écrit :
> I don't fully understand the checking that's being performed in the
> configure utility of GDAL for the -with-curl switch. This apperas to be
> responsible for overriding the curl_global_init function in a header
> file and including lib
try istead of:
LIBS=”-lcurl $LIBS”
LIBS="/absolute/path/libcurl.a $LIBS"
be aware that even the order on how you define static libraries may confused
the
compile process.
--Nikos Hatzopoulos
On Wed, Aug 3, 2011 at 12:45 PM, Jim Pendleton wrote:
> In order to support the GDAL (1.8.1) jpipkak
18 matches
Mail list logo
