[gdal-dev] Open source vector geoprocessing libraries?
jason.roberts at duke.edu
Wed Jan 13 10:44:00 EST 2010
Thanks for the suggestions.
I took a look at GeoKettle. Here are some relevant excerpts from a document:
It looks interesting, but oriented to server applications. We are building a set of desktop GIS analysis tools. It would probably not be practical to try to embed GeoKettle in our application.
GearScape also looks interesting, with SQL-oriented geoprocessing, but it is more of an extensible GIS program than a geospatial library. Again, probably not practical to embed it in our app.
From: Duarte Carreira [mailto:DCarreira at edia.pt]
Sent: Wednesday, January 13, 2010 4:54 AM
To: Jason Roberts
Subject: RE: [gdal-dev] Open source vector geoprocessing libraries?
Have you looked at GeoKettle ? And recently I found GearScape , which seemed very interesting to me. Though neither is based on python...
 - http://sourceforge.net/projects/geokettle/
 - http://www.fergonco.es/gearscape/index.php
De: Emilio Mayorga [emiliomayorga at gmail.com]
Enviado: terça-feira, 12 de Janeiro de 2010 18:25
Para: Jason Roberts
Assunto: Re: [gdal-dev] Open source vector geoprocessing libraries?
This may not be quite what you have in mind, but check out the PySAL
(Open Source Python Library for Spatial Analytical Functions) project:
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!
Applied Physics Laboratory
University of Washington
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
> 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.
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev