Thanks for the suggestion but I'm developing a Win32 app.
I will take in consideration your previous answer because the app can read
images from other sources.
Regards,
Stefano
--
Dr.Eng. Stefano Moratto
stefano.mora...@gmail.com
stefano.mora...@csiat.it
http://www.csiat.it - Traffic
Hi Francis,
Il giorno Wed, 9 Feb 2011 09:38:49 +1100
Francis Markham fmark...@gmail.com ha scritto:
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
Hi,
just a quick question: isn't GetNumPoints implemented on a geometry in
ogr python? Neither GetNumPoints() nor getNumPoints() (small g) work.
The passed in geometry is a geometry object from a
geometry = feature.GetGeometryRef()
call and the geometry is of type 'LINESTRING' taken from
On 02/09/2011 04:19 PM, Frank Broniewski wrote:
Hi,
just a quick question: isn't GetNumPoints implemented on a geometry in
ogr python?
There are OGR_G_GetPointCount in ogr_api.h and GetPointCount method in
the Geometry class in Swig bindings.
Hm. It seems that NumPoints is the name of
There are OGR_G_GetPointCount in ogr_api.h and GetPointCount method in the
Geometry class in Swig bindings.
Right, I was also trying to figure out this, this is my test code:
lineshp = driver.Open('/home/pcorti/data/shapefile/line.shp')
linelyr = lineshp.GetLayer(0)
feat =
Yes, thank you. GetPointCount() works. Another thing I noticed:
point = geometry.GetPoint(point_index)
point is of type tuple(x, y, z), not as one would guess an OGRPoint()
geometry. At least for me this was unexpected. And the python GetPoint
method does not take a OGRPoint geometry, like it
On 11-02-09 10:27 AM, sebastien.fa...@infoterra.fr wrote:
Hello,
I have installed ms4w package which involves GDAL/OGR 1.8.
Unfortunately, libKML announced as a new driver is missing.
Do you have any explanation ?
Thank you.
Sébastien,
There is information on how to build GDAL with libkml
Hi all,
I'm getting this error when calling gdal_merge.py command.
Traceback (most recent call last):
File /home/meeo/bin/gdal_merge.py, line 31, in ?
import gdal
File /usr/lib/python2.4/gdal.py, line 7, in ?
import _gdal
ImportError: No module named _gdal
I don't know python
On 11-02-09 11:23 AM, Giacomo Piva wrote:
Hi all,
I'm getting this error when calling gdal_merge.py command.
Traceback (most recent call last):
File /home/meeo/bin/gdal_merge.py, line 31, in ?
import gdal
File /usr/lib/python2.4/gdal.py, line 7, in ?
import _gdal
ImportError: No module named
On 02/09/2011 05:36 PM, Frank Broniewski wrote:
Yes, thank you. GetPointCount() works. Another thing I noticed:
point = geometry.GetPoint(point_index)
point is of type tuple(x, y, z), not as one would guess an OGRPoint()
geometry. At least for me this was unexpected. And the python GetPoint
On 11-02-09 11:27 AM, sebastien.fa...@infoterra.fr wrote:
Hello,
I have installed ms4w package which involves GDAL/OGR 1.8.
Unfortunately, libKML announced as a new driver is missing.
Do you have any explanation ?
Thank you.
Sébastien FAVRE
Thank you to both Assefa and Frank for answering
Le mercredi 09 février 2011 08:47:25, Mike Leahy a écrit :
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
Several points :
1) The implementation of Layer.GetFeature() is only efficient for just a few
drivers (shapefile). Other drivers will need to sequentially read from the
first
feature ... So use GetNextFeature()
2) The real bug is that you don't rewrite the feature to its layer. So you
need
Le mercredi 09 février 2011 09:59:02, Antonio Valentino a écrit :
Hi Francis,
Il giorno Wed, 9 Feb 2011 09:38:49 +1100
Francis Markham fmark...@gmail.com ha scritto:
Is there a document anywhere specifying the best practices for
parallel writes to a GDAL raster? I have an embarrasingly
I am using gdal2tiles under OSGEO4W. I use both gdal16 and gdal17.
When I have a large HFA file I am not able to use gdal2tiles to process this
file. These large .img (HFA) files have a spill file with a .ige
extension. I receive an error similar to:
0ERROR 4: Unable to open external data
Le mercredi 09 février 2011 03:31:34, Frank Warmerdam a écrit :
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
On Mon, Feb 07, 2011 at 11:29:44AM -0500, Frank Warmerdam wrote:
Note that in 1.9 (aka trunk) GDAL now looks in /usr/local/lib/gdalplugins/1.9
before looking in /usr/local/lib/gdalplugins so embedding the version in
the directory name is no longer needed.
Definitively a good news!
--
On 11-02-09 04:10 PM, Roland Duhaime wrote:
I am using gdal2tiles under OSGEO4W. I use both gdal16 and gdal17.
When I have a large HFA file I am not able to use gdal2tiles to process this
file. These large .img (HFA) files have a spill file with a .ige extension. I
receive an error similar
Thanks for the feedback Antonio and Even, it is very helpful.
I probably should have specified that I want to do message passing across a
cluster using MPI, rather than shared memory multithreading. I'll do some
performance testing to see what the relative speeds of having workers send
their
Hi Even,
It looks like adding '-L../../.libs -lgdal' did the trick to ensure that the
libraries are linked. E.g.,:
swig -Wall -I../include -I../include/php -I../include/php/docs \
-I/scratch2/gdal/gdal-1.8.0 -c++ -php -o osr_wrap.cpp ../include/osr.i
g++ -L../../.libs -lgdal -I../../port
Frank,
Thanks for your reply, I solved my problem by recompiling GDAL with
--with-python option.
Thanks.
On 02/09/2011 05:40 PM, Frank Warmerdam wrote:
On 11-02-09 11:23 AM, Giacomo Piva wrote:
Hi all,
I'm getting this error when calling gdal_merge.py command.
Traceback (most recent call
21 matches
Mail list logo
