[geos-devel] question on prospectives of python bindings to opensource geospatial libraries

[N.J. Hardebol]

Hello,

In the email of Feb. 28 I posed some questions on python GEOS
implementations to which Sean Gillies replied saying also that Python
wrappers for GEOS are not actively maintained.
http://geos.refractions.net/pipermail/geos-devel/2007-February/002848.html
http://geos.refractions.net/pipermail/geos-devel/2007-March/002851.html

We ( = group of structural geologist - working on some academic coding -
see below) were expecting that with the advances in spatial open source
community, spatial statistics on scripting level (i.e. using python) would
be a feasible development path. Although also ESRI has made certain steps
allowing its topology functions to be called from within python we rather
prefer to rely on open source libraries.
For this we indeed require that GEOS and OGR developments would get better
supported to higher scripting languages. Although not well documented use
of swig python bindings appeared feasible to us. Further we noticed some
new initiatives like PCL - cartography.
You denoted that 'Python module in GEOS is not actively maintained' which
is indeed a warning.
Could you may give some more reflection and perspective on this?
Are there any alternatives in which GEOS is somehow embedded and extended
to python scripting level. e.g. initiatives like PCL?

It might be helpful to explain some more what we are in to. We're a
research-group of structural geologists working on new field acquisition
and post field data processing procedures. We try to characterize the
fracture patterns in rocks on cms to 100s of meters scale. For this we
acquire fractures digitized as polylines using a tablet pc and a
customized arcpad application. In the post-field processing we prefer to
remain independent of esri solutions and we've developed a small fracture
statistics routine. This routine is written with python and reads fracture
data from shapefiles
using the ogr-library and then some basic spatial statistics (fracture
spacing etc...) is being calculated using GEOS-functionality. In a pilot
project, using linux and with shapefiles as data-repository this worked
well.  Further improving coding and aiming for advanced processing my
migrating data to postgresql+postgis and adding user friendliness by
porting code to windows environment we can still obtain a working code.
However have run in some problems and also when cleaning up of code we've
noticed some untidy, mixed and inconsistent use of OGR and GEOS libraries.

Any suggestions on devolopers track or getting connected with devolpers
pursuing comparable goals would help us.

thanks,

Nico