On Fri, Nov 20, 2009 at 11:17:51AM +0800, Emmanuel Christophe wrote:
> Hi,
> I took a bit more time to investigate this and came out with a minimal
> test case to reproduce that (using only gdal). The context is a
> project using gdal AND some specific geotiff methods thus requiring
> both for link
On Fri, Nov 20, 2009 at 2:24 PM, Francesco P. Lovergine
wrote:
> On Fri, Nov 20, 2009 at 11:17:51AM +0800, Emmanuel Christophe wrote:
>> Hi,
>> I took a bit more time to investigate this and came out with a minimal
>> test case to reproduce that (using only gdal). The context is a
>> project using
All,
The GDAL team is pleased to announce the release of GDAL 1.6.3 RC1.
http://download.osgeo.org/gdal/gdal-1.6.3-RC1.tar.gz
http://download.osgeo.org/gdal/gdal163-RC1.zip
The following issues were addressed in this release:
General:
* r13533 (ogr postgis plugin) have been added to the stable
Hi,
I took a bit more time to investigate this and came out with a minimal
test case to reproduce that (using only gdal). The context is a
project using gdal AND some specific geotiff methods thus requiring
both for linking.
Since gdal 1.6 on Debian, the option with-hide-internal-symbols is
used w
I'm sure this subject has come up before, but these terrain files get quite
large and in some cases it would be nice to be able to compress them and read
them on the fly, such as, gzipped files. Is there a standard accepted method
to uncompress and read files on the fly. I guess something li
Frank,
Can you expand of what you mean by a "gross issue" (non-optimised/user
ignorance/rtfm ???) ? Are there compounding issues in the process ?
Is there a "magic combination of switches" on a 32bit system (3Gb RAM,
Dual Xeons) that I should be using (does it depend muchly on the
source/destinati
Even,
As I said before, the new API is great but I need to report a correction on my
performance analysis.
I found that an unnecessary float-to-string conversion was taking much of the
processing time on my code.
After I remove that from the code the performance of the Frank's proximity
algo
I would suggest you try out gdal2tiles.py which does something similar
to regionator but with many more options.
http://www.gdal.org/gdal2tiles.html
Frank recommended that I try gdal2tiles. I (think) I now have a working
version of it, and I've looked at the man page to find this usage:
tasmi...@rockwellcollins.com a écrit :
In fact, you don't need to know if the TIFF file is interleaved or not.
It is abstracted by GDAL. The interleaving parameters of the RasterIO()
call determine the interleaving parameters of the result buffer you
wish. So they can be completely unrelated t
TIFF is one type of data that I need to read in. Some of the RGB images
are pixel interleaved while others are planar (non-interleaved). I was
intending to use the GDALDataset::RasterIO function to read in my data, as
I only need a buffer containing the entire image exactly as it exists on
di
>> Shaun Kolomeitz wrote:
>> > could push beyond 1GB/s. Currently to process (mosaic) an 80GB image
it
>> > takes several days to complete. This is also on 32bit hardware, and I
>>
>> Shaun,
>
>> I suspect that there is a gross issue with how the warping is being
done,
>> and that it could be spe
Hi,
I am trying to use VRT files and gdalwarp to mosaic and tile
multiresolution images. I use two images at different resolutions which
overlap and compute the mosaic using gdalbuildvrt.
The vrt produced has wrong "y resolution and y size", so I first edit
the y coordinates of the vrt (tick
Arnaud,
You should use Layer.SetFeature(feat) to trigger the update in your shape
file.
Nicolas
-Message d'origine-
De : gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org]de la part de Arnaud Vandecasteele
Envoyé : jeudi 19 novembre 2009 10:21
À : gd
Hi all,
I'm trying to set a value on an existing field and existing Shapefile with
python-ogr but it doesn't seems to work.
Here is my works :
-
import ogr
import math
import os
layerNameF = os.path.join("myShape.shp")
driver = ogr.GetDriverByName("ESRI Shapefile")
Laye
Frank Warmerdam pobox.com> writes:
> Shaun Kolomeitz wrote:
> > could push beyond 1GB/s. Currently to process (mosaic) an 80GB image it
> > takes several days to complete. This is also on 32bit hardware, and I
>
> Shaun,
>
> I suspect that there is a gross issue with how the warping is being d
15 matches
Mail list logo
