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 la
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 -I.
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 data
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 t
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!
--
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 o
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 file
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 ha scritto:
> > Is there a document anywhere specifying the best practices for
> > parallel writes to a GDAL raster? I have an embarrasingly parallel
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 to
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, f
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 th
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
m
CCing the ms4w list.
There is currently a bug on that [1].
I believe these type of request get addressed for upcoming releases.
You can also get in touch with the MS4W maintainers to find ways to get
this done earlier.
[1]: http://bugzilla.maptools.org/show_bug.cgi?id=2294
best regards,
On
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 name
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 'c
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 su
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
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
Ce courrier électronique et toutes les pièces éventuellement jointes qu’il
contient sont CONFIDENTIELS et destiné
>
> 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 = linelyr.GetNext
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 the
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
geo
Hi Francis,
Il giorno Wed, 9 Feb 2011 09:38:49 +1100
Francis Markham 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 sure
> what I a
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 Optimizatio
23 matches
Mail list logo
