Doug,
Thanks for these suggestions. It looks like PostGIS and SpatialLite both provide a SQL-based approach for accomplishing what I need. Both look promising and I will dig into them in more detail. It might be less than optimal to load data into one of these, execute the desired spatial query, and export data back out. But there is probably no suitable alternative that provides a complete set of spatial operators that is any faster. I'm sure a big part of executing efficient spatial queries is having a spatial index. Even OGR does not appear to expose spatial indexes that may be maintained by the underlying data sources. Thus any geoprocessing library that sits on OGR or a similar API must already retrieve all records, build a spatial index, then execute the spatial query. This is basically the same thing as loading data into PostGIS or SpatialLite and then executing the query. I have tons of questions but will resist asking all but one: do you know how well these systems can be embedded in other software? In my collection of tools, I want the infrastructure that supports them to be hidden and config-less. Although I have not used SQLite, I know it is designed explicitly for easy embedding, so it seems promising. What about Postgres? In my past experience, it appeared to be much more of a full-blown enterprise database system, designed to run as a service or daemon, listen for connections, etc. If it can be easily embedded, I might prefer to use it, as PostGIS appears to provide a richer set of spatial operators. Jason From: [email protected] [mailto:[email protected]] Sent: Tuesday, January 12, 2010 12:29 PM To: Jason Roberts Cc: 'gdal-dev'; [email protected] Subject: Re: [gdal-dev] Open source vector geoprocessing libraries? Jason, If you're working with vector data, why not throw the data into Postgresql/Postgis, http://postgis.refractions.net, and use the spatial operators there to select/buffer/intersect the vector geometries as you describe. http://postgis.refractions.net/documentation/manual-1.4/ch07.html for geoprocessing operations. Your application can pass SQL commands to the database. You can use ogr to load data /export your finished product to/from postgresql/postgis . You might be able to similar things in spatialite, http://www.gaia-gis.it/spatialite/spatialite-tutorial-2.3.1.html#t4. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 [email protected] ---------------------------------------------------------------------------- ----------------------------- The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Inactive hide details for "Jason Roberts" <[email protected]>"Jason Roberts" <[email protected]> "Jason Roberts" <[email protected]> Sent by: [email protected] 01/11/2010 05:32 PM To "'gdal-dev'" <[email protected]> cc Subject [gdal-dev] Open source vector geoprocessing libraries? 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
<<image001.gif>>
<<image003.png>>
<<image004.png>>
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
