[geos-devel] how to construct geos geometry instances using
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.
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
> 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
> 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.
Windows? I won't be much use to you. I've never personally compiled GEOS
or the Python bindings on windows.
More information about the geos-devel