Hi Yosuke,
If you use MultiPolygon geometries (with your polygons as the parts), geos
(via ogr or shapely) should be able to do the job in one go, which should
speed things up considerably...
Cheers,
Simon
On Sat, Nov 6, 2010 at 5:04 AM, yosuke kimura yosukesa...@gmail.com wrote:
All,
Since this one affected me, I would like to ask if the fix for
http://trac.osgeo.org/gdal/ticket/3411 is included?
Regards,
Peter
R3 GIS Srl - GmbH
http://www.r3-gis.com
Frank Warmerdam warmer...@pobox.com wrote
Subject: [gdal-dev] GDAL/OGR 1.7.3 Release Candidate
Date:
Frank Warmerdam wrote:
Motion: Promote GDAL/OGR 1.7.3RC2 to final release
+1 (Tested with FGS and MapServer without problems)
Daniel
--
Daniel Morissette
http://www.mapgears.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Peter Hopfgartner wrote:
Since this one affected me, I would like to ask if the fix for
http://trac.osgeo.org/gdal/ticket/3411 is included?
Peter,
The comments in the ticket seem to indicate the fix was only in trunk,
not the 1.7 stable branch. My review of changes in the branch used to
Hello,
I'm trying to download the autotest source code from the SVN repository,
but I have a problem with a file name encoded in UTF-8 :
$ svn checkout https://svn.osgeo.org/gdal/trunk/autotest gdal-autotest
svn: Can't convert string from 'UTF-8' to native encoding:
svn:
Peter Hopfgartner wrote:
I wrapped a quick rpm package, installed the rpms and tried to run autotest.
The tests comes to this point:
Running tests from gcore/mask.py
TEST: mask_1 ... success
TEST: mask_2 ... success
TEST: mask_3 ... success
TEST: mask_4 ... success
TEST: mask_5 ...
I wrapped a quick rpm package, installed the rpms and tried to run autotest.
The tests comes to this point:
Running tests from gcore/mask.py
TEST: mask_1 ... success
TEST: mask_2 ... success
TEST: mask_3 ... success
TEST: mask_4 ... success
TEST: mask_5 ... ERROR 1:
Hi Frank,
I had to disable mask_5 to mask_10 and ecw_6, which threw another Exception.
Now the result looks like:
Failures
Script: ogr/ogr_s57.py
TEST: ogr_s57_2 ... fail
Expected 2 layer type in layer COALNE, but got 0.
Script: gcore/tiff_write.py
TEST:
Peter Hopfgartner wrote:
Hi Frank,
gdal was configured with:
--with-geotiff=external \
--with-tiff=external \
--with-libtiff=external \
and libtiff is the one that comes with CentOS 5.5:
[rpmbu...@rpm-devel gdalautotest-1.7.0]$ rpm -qa | grep tiff
Hi Frank,
gdal was configured with:
--with-geotiff=external \
--with-tiff=external \
--with-libtiff=external \
and libtiff is the one that comes with CentOS 5.5:
[rpmbu...@rpm-devel gdalautotest-1.7.0]$ rpm -qa | grep tiff
libgeotiff-1.2.4-3.el5
Hi,
I'm trying to use the ogr2ogr.exe compiled with VC++ .
running ogr2ogr it give me this message:
ERROR 4: Unable to open EPSG support file gcs.csv
so I retrieve a gcs.csv file from FWTools2.4.7 and copy it in the same
folder of ogr2ogr.
after this copy.
The new message from ogr2ogr is
Andrea Peri 2007 wrote:
Hi,
I'm trying to use the ogr2ogr.exe compiled with VC++ .
running ogr2ogr it give me this message:
ERROR 4: Unable to open EPSG support file gcs.csv
so I retrieve a gcs.csv file from FWTools2.4.7 and copy it in the same
folder of ogr2ogr.
after this copy.
The new
Frank,
thx for link.
I take the last gcs.csv and pcs.csv.
I verify that in the new pcs.csv there is EPSG:3003 (it is projected)
but even now ogr2ogr.exe still report me
the epsg pcs/gcs code 3003 not found.
seem that ogr2ogr is not using the pcs.csv file .
Thx,
Andrea.
Il 09/11/2010
Hi all,
An easy question and apologies if it's been asked before.
Is there a way to get the owning gdal.Dataset from a gdal.Band within Python?
I'm not seeing GetDataset() as in C/C++ within the Python bindings.
thanks, matt
___
gdal-dev mailing
Le mardi 09 novembre 2010 23:34:35, Gregory, Matthew a écrit :
Hi all,
An easy question and apologies if it's been asked before.
Is there a way to get the owning gdal.Dataset from a gdal.Band within
Python? I'm not seeing GetDataset() as in C/C++ within the Python
bindings.
No, there's
Even Rouault wrote:
No, there's no direct way of doing it with an API call. But as you can
only get a Band from a Dataset, you can easily do something like :
band = ds.GetRasterBand(xxx)
band.ds = ds
and then use band.ds to get access to the dataset...
Ah, of course. Thanks for helping
No, there's no direct way of doing it with an API call. But as you can only
get a Band from a Dataset, you can easily do something like :
band = ds.GetRasterBand(xxx)
band.ds = ds
Do we really need this? As far as I remember band must be in the same
context of dataset (dataset can't go out
Le mercredi 10 novembre 2010 00:10:08, Paolo Corti a écrit :
No, there's no direct way of doing it with an API call. But as you can
only get a Band from a Dataset, you can easily do something like :
band = ds.GetRasterBand(xxx)
band.ds = ds
Do we really need this? As far as I
Even Rouault wrote:
Le mercredi 10 novembre 2010 00:10:08, Paolo Corti a écrit :
Do we really need this? As far as I remember band must be in the same
context of dataset (dataset can't go out of scope), so why would we
need a reference to it?
You're 100% right. By the way, assigning the
On Wed, Nov 10, 2010 at 12:22 AM, Even Rouault
even.roua...@mines-paris.org wrote
You're 100% right. By the way, assigning the dataset as a member of the band
is an excellent means of making sure that we keep a reference to the dataset.
That's indeed the gist of the patch attached to ticket
20 matches
Mail list logo
