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

Sean Gillies sgillies at frii.com
Mon Mar 12 16:34:49 EDT 2007

N.J. Hardebol wrote:
> 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.

Hi Nico,

The objects are not interchangeable, but OGR links in GEOS, and many 
methods of OGR geometries wrap corresponding GEOS functions. See the OGR 
geometry API docs:


and compare to the GEOS geometry API:


ogr.py geometries have get_Area(), get_Length(), and more. I hope that I 
am not stating the obvious to you.

> 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.

What specifically does OGR lack?

> 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

Windows? I won't be much use to you. I've never personally compiled GEOS 
or the Python bindings on windows.


Sean Gillies

More information about the geos-devel mailing list