Emilio, Thanks for the suggestion of pysal. It does look interesting, but as you speculated, it seems to not aim to include the traditional spatial operators. Instead it looks like a collection of various interesting algorithms, implemented in Python on top of SciPy, NumPy, spatialindex, and Rtree. This might be useful for specific problems, but I need a more comprehensive library of the traditional stuff.
> BTW, I'd love to see your marine spatial ecology tools moved to an > open source, platform neutral code base! Yes, we would love that too. At the moment, I am evaluating whether we should develop our next batch of tools under our existing framework which depends heavily on ArcGIS, or take a time-out to rework the framework to eliminate that dependency. I have already done pieces of it, here and there, but this vector geoprocessing functionality is a key blocker that remains unresolved. Best, Jason -----Original Message----- From: Emilio Mayorga [mailto:[email protected]] Sent: Tuesday, January 12, 2010 1:26 PM To: Jason Roberts Cc: gdal-dev Subject: Re: [gdal-dev] Open source vector geoprocessing libraries? Hi Jason, This may not be quite what you have in mind, but check out the PySAL (Open Source Python Library for Spatial Analytical Functions) project: http://geodacenter.asu.edu/pysal I've never used it, and have only looked at a recent presentation (http://conference.scipy.org/static/wiki/rey_pysal.pdf). It's not clear that it includes or even aims to include the traditional spatial operators provided by GEOS. I also have no idea if it uses OGR for its vector data access. But the developers have done some terrific work in spatial analysis tools in the past. BTW, I'd love to see your marine spatial ecology tools moved to an open source, platform neutral code base! Cheers, -Emilio Mayorga Applied Physics Laboratory University of Washington Box 355640 Seattle, WA 98105-6698 USA On Mon, Jan 11, 2010 at 2:32 PM, Jason Roberts <[email protected]> wrote: > Dear geospatial software experts, > > > > By integrating with GEOS, OGR can perform various spatial operations on > individual geometries, such as buffer, intersection, union, and so on. Is > there a library that efficiently performs these kinds of operations on > entire OGRLayers? For example, this library would have functions that would > buffer all of the features in a layer, or intersect all of the features in > one layer with all of those in another. Basically, I am looking for an open > source technology that replicates the "geoprocessing tools" found in ArcGIS > and other GIS packages. These tools traditionally operate on one or more > layers as input and produce one or more layers as output. > > > > If such a library does not exist, does the OGR team envision that they might > add such capabilities to OGR in the future? From software design and > performance points of view, would it be appropriate to extend OGR to include > functions for spatial operations on entire layers, or is this best left to > other libraries? I can see rudimentary ways to implement such tools (e.g. > for intersecting layers: loop over all features in both layers, calling > OGRGeometry::Touches on all combinations, or something similar). But I am > not a geometry expert and do not know if OGRLayer's cursor-based design is > compatible with such capabilities; I do not know about spatial indexing, for > example. > > > > I develop open source geoprocessing tools that help with spatial ecology > problems. At the moment, my tools depend on heavily on ArcGIS for these > operations with vector layers. I would like to remove this dependency, and, > if possible, develop a toolbox that exposes the same ecology tools to > several GIS packages. Many GIS packages, such as ArcGIS, QGIS, MapWindow, > and OpenJump, support plugin extensions. I am wondering whether how > difficult it would be to develop a package of tools that does not depend on > a specific GIS package but exposes them to several packages via the > package-specific plugin mechanisms. For this to work, I'd have to find a > library that can do the kind of geoprocessing with layers that ArcGIS can > do, or write my own. Writing it myself sounds daunting and am hoping that > there are existing projects to draw from. > > > > Thank you very much for any comments you can provide. > > > > Jason > > > > > > > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
