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 _______________________________________________ geos-devel mailing list geos-devel@geos.refractions.net http://geos.refractions.net/mailman/listinfo/geos-devel
