Hello,
I have trouble transforming a datasource from one srs to another. I am
using the python bindings and gdal 1.6.0 on Windows. Problem is,
whatever I do to the datasource and the contained feature geometries,
the coordinates just don't get transformed. My code, from what I've
figured out
Hi Tamas,
Thanks for the feedback. I've tried what you suggested, regenerating the swig
bindings, and setting the LD_LIBRARY_PATH...though the outcome seems to be the
same. Here's my output from manually building php_gdal.so, from within the
swig/php source directory:
===
Folks,
I have modified GDALDriverManager::~GDALDriverManager() so that when
it is destroyed it will first close all still-open GDAL datasets. A debug
message will be issued for each dataset force-closed.
This is part of an effort to ensure a clean shutdown and to make it easier
to detect memory
On 11-02-08 08:04 PM, Francis Markham wrote:
Is there any way to disable the block cache altogether?
Francis,
No, there is no way to disable the block cache altogether. For
specific drivers you could skip past the block cache by calling
GDALRasterBand::WriteBlock() but this may not work well
Is there any way to disable the block cache altogether? Does setting the
cache size to zero work? And is there a way to do this from a python
script?
Cheers,
Francis
On 9 February 2011 10:40, Frank Warmerdam wrote:
> So, with some care you could in theory write from multiple threads,
> but y
On 11-02-08 05:58 PM, Francis Markham wrote:
Ouch, I guess I'll be slicing and mosaicing, sending all my data across the
network, or looking for another IO library. Which approach would you
recommend? Are you aware if any of the major non-GDAL libraries for popular
formats (e.g. libgeotiff) su
Ouch, I guess I'll be slicing and mosaicing, sending all my data across the
network, or looking for another IO library. Which approach would you
recommend? Are you aware if any of the major non-GDAL libraries for popular
formats (e.g. libgeotiff) support concurrent writes?
-Francis
On 9 Februar
Le mardi 08 février 2011 23:38:49, Francis Markham a écrit :
> Is there a document anywhere specifying the best practices for parallel
> writes to a GDAL raster? I have an embarrasingly parallel problem that I
> would like to parallelise with MPI, but I'm not sure what I am allowed to
> do in para
Is there a document anywhere specifying the best practices for parallel
writes to a GDAL raster? I have an embarrasingly parallel problem that I
would like to parallelise with MPI, but I'm not sure what I am allowed to do
in parallel. I would like to assign blocks exclusively to worker threads to
Le mardi 08 février 2011 23:33:39, Stefano Moratto a écrit :
> The openstreet data is a virtual image composed by several tiles at a given
> zoom level, each tiles is a 256x256 png, so I think if a thead read a
> 256x256 block i will access only a given png.
Yes of course reading different images
Le mardi 08 février 2011 23:07:36, Stefano Moratto a écrit :
> Thanks for the suggestion,
>
> I have to read png from openstreetmap. I'm trying to render an A4 paper
> size sheet so I have a lot of data to move.
> It may be better to divide the area to be read in blocks and to give to
> each threa
Thanks for the suggestion,
I have to read png from openstreetmap. I'm trying to render an A4 paper size
sheet so I have a lot of data to move.
It may be better to divide the area to be read in blocks and to give to each
thread a block. Foreach block a thread should read all the bands.
Probabilly
Le mardi 08 février 2011 22:41:50, Stefano Moratto a écrit :
> Hello,
> given an opened GDAL dataset, is it possibile to perform
> gdalrasterio calls for each band in a dedicated thread per band in a
> thead-safe way?
> E.g. I have a raster image with 3 band (r,g,b). Since I have 4 core I
Hello,
given an opened GDAL dataset, is it possibile to perform
gdalrasterio calls for each band in a dedicated thread per band in a
thead-safe way?
E.g. I have a raster image with 3 band (r,g,b). Since I have 4 core I would
like to I run a thread for a band r, one for band g and one for
Mike,
Actually the PHP bindings are not maintained at all, so any improvements in
this topic would be welcomed. You might also want to regenerate the bindings
with SWIG since the committed version may be outdated. You should also make
sure the corresponding gdal core is available load (proably by
2011/2/8 Lefman, Jonathan ERDC-TEC-VA :
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Thank you Jorge. That worked. :)
>
>
Good to hear it :-).
Adapted from
http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/python/raster2pgsql.py
>
> -Original Message-
> From: Jorge Aré
Classification: UNCLASSIFIED
Caveats: NONE
Thank you Jorge. That worked. :)
-Original Message-
From: Jorge Arévalo [mailto:jorge.arev...@deimos-space.com]
Sent: Tuesday, February 08, 2011 11:15
To: Lefman, Jonathan ERDC-TEC-VA
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] New
Hi Jonathan,
On Tue, Feb 8, 2011 at 4:46 PM, Lefman, Jonathan ERDC-TEC-VA
wrote:
> Classification: UNCLASSIFIED
>
> Caveats: NONE
>
> Hi all,
>
> I joined this list today. I have a question about using Python bindings
> with GDAL to get info from a geotiff.
>
> What are the functions that I need
Classification: UNCLASSIFIED
Caveats: NONE
Hi all,
I joined this list today. I have a question about using Python bindings with
GDAL to get info from a geotiff.
What are the functions that I need to obtain coordinate extents of raster
data? For example, if I have a rectangular area from Wash
19 matches
Mail list logo
