[geos-devel] how to construct geos geometry instances using python bindings

[N.J. Hardebol]

thanks for your response.

I 'm not sure though, if I've understood you well with 'OGR geometries
acquire the operations of GEOS geometries'. Does this mean that GEOS
geometry class or subclass methods like getArea() or getLength() functions
can be referenced from OGR-geometry objects? I think I've not well
understood as OGR-geometry and GEOS-geometry objects are not simply
interchangeable in PYTHON.
So it's not just for creating new geometry instances, we also want to
perform geometric and spatial-stat operations that generate some new
geometry instances as well. We considered that it requires the GEOS python
wrapper to perform geometry topology operations on scripting level as the
functionality within OGR is limited in this regard.

It might be helpful to explain some more what we are in to. I've just
posted another email getting also back to your comment that GEOS python
bindings are not being maintained and outlining briefly what we are aiming
for with our routine. For future of our develop-track, the prospectives of
python bindings are indeed crucial.
For now, as I think i certainly need GEOS, i have a working code with some
workarounds. It includes some untidy usage of OGR mixed with GEOS (i.e.
geometry instances conversion via OGRs. It's working for reading wkt
strings from PostgreSQL+Postgis database, but reading from shapefiles with
the OGR library give some problems.
My question in my first email on how to best create a new geometry - e.g.
GEOS LINESTRING remains. I've it working by defining a WKT-string and
using geos geometryfactory reader function. I guess there must be better
way.
My other problem with GeometryPtr might not be whre I initially thought it
was. An GEometryPtr instance of type LINESTRING with a getLength()
function is working well. However there is a series of function also
wrapped by the python swig, that give problems. Among them are
getPointN(), getStartPoint()
>From the python error message I can't tell where the problem exactly is,
seams in the underlying geos library called.
Could this possibly be due to bugs reported causing memory access violation
http://lists.refractions.net/pipermail/geos-devel/2006-March/001962.html
The windows geos python binding compilation, as not actively maintained
could possibly have been compiled around this time.
If so then further code cleaning get's here to end and need to stay with
my workaround.

thanks,

Nico