I guess GeoDjango is using the C++ API ?
Ahi ahi ahi ...
(yes, it changed, see NEWS file)
--strk;
On Mon, Aug 22, 2011 at 11:58:44AM -0700, Christopher DeMars wrote:
I'm thinking that there must be some sort of conflict between the GEOS
and geodjango. Has the API changed significantly lately?
I'm thinking that there must be some sort of conflict between the GEOS
and geodjango. Has the API changed significantly lately?
After installing the latest SVN release (3.4.0dev-CAPI-1.8.0), things
got worse, not better. Now no geometry will buffer, even super simple
example geometries from
Please upload the smallest geometry with which you can
reproduce the issue to the bug item you opened already.
The error reveals a bogus use of the library.
Since all code is internal to the library, this should never happen.
I can think of two possibilities:
1) memory corruption (valgrind could
Thank you Mr. Davis for your attention,
I tried your suggestion of buffering elements individually then
merging the buffers. I buffered several elements without issue, then
got the same program stopping error message as before. On the plus
side, I did isolate a polygon that was crashing things.
Good to have the problem narrowed down.
There's nothing obviously wrong with the polygon, at least from the JTS
perspective. Perhaps Sandro can shed some light on the issue...
On 8/19/2011 7:03 AM, Christopher DeMars wrote:
Thank you Mr. Davis for your attention,
I tried your suggestion of
I initially wasn't sure if the failure was caused by a particular
geometry formation or due to the size of the dataset. I have since
tried other county layers from the same source (California Department
of Water Resources) and got the same error after processing a small
number of polygons, so
I have tested this in JTS 1.12, and can confirm that both isValid and
buffer work correctly. The buffer operation does take quite a while and
requires a significant amount of memory.
So the geometry is fine. There may be some issues with GEOS.
On 8/18/2011 3:44 PM, Christopher DeMars wrote:
Incidentally, this is one of those cases where buffering by unioning the
buffers of the components far outperforms the straight buffer (for
distance = 100, 10 s vs 70 s).
This is something you might be able to try, if your data model permits
it. Split the geometry into its components, and
