On Wed, Nov 10, 2010 at 12:22 AM, Even Rouault
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
> http://trac.osgeo.org/gda
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, assign
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 a
> 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 o
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 he
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, th
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 li
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 18:13,
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 me
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 thi
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
libtiff-devel-3.
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
libgeotiff-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: tiff_wr
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 ... ER
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: ZIPDecode:tmp/mask_4
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:
gdal-autotest/gcore/d
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
creat
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
http://lists.osge
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 wrote
Subject: [gdal-dev] GDAL/OGR 1.7.3 Release Candidate
Date: 07.11.2010 03:49
>Folks,
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 wrote:
> All,
>
> I think I found
20 matches
Mail list logo
