[gdal-dev] Open source vector geoprocessing libraries?

[Jason Roberts]

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:emiliomayorga at gmail.com] 
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 <jason.roberts at duke.edu>
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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>