Ivan,
in my experience it is often enough to keep a ref to the dataset to
avoid these segfaults. However, my experience is more with gdal (raster)
than with ogr (vector), so ymmv, and some experimenting might be
required. Just start with keeping a ds reference, if that doesn't work,
go furthe
gdal-dev-boun...@lists.osgeo.org [mailto:
> gdal-dev-boun...@lists.osgeo.org] *On Behalf Of *Ivan Willig
> *Sent:* Tuesday, October 26, 2010 10:54 AM
> *To:* Frank Warmerdam
> *Cc:* gdal-dev@lists.osgeo.org
> *Subject:* Re: [gdal-dev] Issue with python bindings.
>
>
>
> Thanks Fra
you wish to add, it
would be greatly appreciated.
Best,
Jason
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ivan Willig
Sent: Tuesday, October 26, 2010 10:54 AM
To: Frank Warmerdam
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Issue with
Thanks Frank. That seems to be the issue. Whats the rule about this how long
you should keep a reference. For example this causes the same issue.
ds.GetLayer().GetFeature(0).GetGeometryRef().GetEnvelope()
Which I am going to guess is because I should keep a reference to the
geometry. Correct?
Iv
Ivan Willig wrote:
Hi list,
I am having an issues with using the python swig based bindings. I am on
Fedora 13 using the default gdal rpm, which is at version 1.6.2. My
issue is when i stack method calls. For example when I do the following:
ogr.Open("/home/ivan/dev/bigapps/data/nyco.shp").
Hi list,
I am having an issues with using the python swig based bindings. I am on
Fedora 13 using the default gdal rpm, which is at version 1.6.2. My issue is
when i stack method calls. For example when I do the following:
ogr.Open("/home/ivan/dev/bigapps/data/nyco.shp").GetLayer().GetFeature(0)
