Would the concept be a useful thing to develop? Good question. If processing spatial data is your core business and you want to innovate and compete, you'd profit from "owning" your means of production. Not depending on ArcGIS or FME, in other words. Did Google license its search engine from someone else? Did Facebook license Cassandra from someone else? No.
One development since last year's thread on this topic (http://groups.google.com/group/python-gis-sig/browse_frm/thread/0d0fc156360bda78#) is the ZOO project (http://zoo-project.org/). I'm always a little skeptical of projects that tout architectures based on W*S, but over time I've come to realize that WPS in ZOO is partly a marketing hook and partly a pragmatic message format choice. If they didn't use the WPS request format, they'd have to invent something like WSGI that would be more or less equivalent. You should definitely take a look at that project. I can imagine using something like the ZOO kernel, but implemented in Python and in a functional style. Processing objects that take a bundle of instructions (like WPS parameters, but as a mapping instead of XML) and an iterator over source features and that yield new features. Objects that would play well with itertools (http://docs.python.org/library/itertools.html). Not black boxes at all, but transparently interoperable and reusable code. Shapely has some iterator operations, but I don't feel like they really belong in that package. Martin Davis's JEQL (http://tsusiatsoftware.net/jeql/main.html) is an example of yet another approach: a DSL for geoprocessing. Cheers, On Thu, Apr 29, 2010 at 11:40 PM, Eric Wolf <[email protected]> wrote: > Ivan, > What you point out, the lack of an open source "geoprocessing" library has, > to some degree, become a sort of religious concept. > On the one side, you have the geographers and typical user demographics that > ESRI targets. On the other side, you have programmers and computer science > types. These sides are completely drawn down these lines, but I think you > get the gist. > The general question is really, "how much should geoprocessing be turned > into black-boxes"? Most people who are adept at programming are not > intimidated by having to implement basic geospatial algorithms themselves. > Further, many such people abhor the inefficiencies inherent in chaining > together a series of black boxes. For instance, in your example, I'm sure > the end result isn't a buffer - it's some operation using that buffer as > input. Why does that buffer ever need to exist as a shapefile? The black box > method that ESRI encourages means a temporary shapefile has to be written > out and read back in. If you implement the algorithms yourself, you just > build the buffer into the data structures passed around. > On the other hand, the academic GIS community (and ESRI) have put a great > deal of effort into encapsulating some really complex geospatial operations > into these well-defined black boxes. Once upon a time, Arc/Info Workstation > implemented the black boxes as Unix commands and then Avenue and AML > commands. Now they are COM objects that are used uniformly by the ArcGIS > Toolbox, ModelBuilder, ArcServer and the arcgisscripting Python module. By > leaving the inefficiencies to Moore's Law, people can work with geospatial > information at a higher level of abstraction. You never really need to know > how to represent a buffer in code. You just have to know how to use it. > But to answer your question, there isn't such a library (that I know of). I > know GRASS implements many functions as does QGIS. So you can probably do > some of it in the QGIS Python console. But it's still a different approach. > -Eric > -=--=---=----=----=---=--=-=--=---=----=---=--=-=- > Eric B. Wolf New! 720-334-7734 > USGS Geographer > Center of Excellence in GIScience > PhD Student > CU-Boulder - Geography > > GPG Public Key: http://www.h4h.net/ebwolf.public.key.txt > > > On Thu, Apr 29, 2010 at 3:05 PM, Ivan Willig <[email protected]> wrote: >> >> Hi list, >> I have been looking for an easy to use open source analytical library for >> processing GIS data. I thought I would ask here first. I often work with >> data and want a clean high level data api for doing spatial analysis. I am >> looking for something similar ArcPy but not in the ESRI world. Correct if I >> am wrong, but projects like Shapely are focused on processing and analyzing >> geometries. On the other hand projects like Ogr/Gdal allow me to create and >> manipulate Shapefiles and PostGIS tables but lack analytical capabilities. >> Same thing with geoscript. >> >> For example, I would like to buffer the features of a shapefile and save >> the results of another shapfile. Something like >> >> from something import ops >> ops.buffer(“input_shapfile.shp”, “output_shapefile”,10) >> Thats taken right from the ESRI's documentation. With ogr or geoscript, I >> could do this but I would have to load the Shapefile into memory, iterate >> through the features, call the buffer method on each geometry objects and >> then save the results to a new file. This is rather complicated for mere >> mortals. >> Is there a open source library that does this? Would this be a useful >> thing to develop for the open source community? Or am I totally bat s**t >> crazy and this is not really useful? >> >> Thanks guys. >> Ivan Willig >> 818-212-4554 >> > > -- Sean Gillies Programmer Institute for the Study of the Ancient World New York University
