[gdal-dev] Open source vector geoprocessing libraries?

Tue Jan 12 17:45:13 EST 2010

Jason Roberts wrote:
> 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.

I have used SQLite in a bunch of tools. It is easy and straight forward. 
You can do any config stuff in your code so it is config-less from the 
users point of view.

I also use PostGIS for a lot of stuff, but you are right that you need 
to setup a server and have your tools connect to it. Once the server is 
setup and running the client applications just need to have valid login 
to the server to do whatever they want.

For Perl I tend to use PostGIS and for C code I tend to use SQLite. I 
have looked at the SpatiaLite extensions but have not really used them yet.

If you are building a system where you don't want to deal with a 
database server, I would have not qualms using SQLite and SaptiaLite for 
building an embedded solution.

-Steve
  http://imaptools.com/

> Jason
> 
>  
> 
> *From:* Doug_Newcomb at fws.gov [mailto:Doug_Newcomb at fws.gov]
> *Sent:* Tuesday, January 12, 2010 12:29 PM
> *To:* Jason Roberts
> *Cc:* 'gdal-dev'; gdal-dev-bounces at lists.osgeo.org
> *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 doug_newcomb at fws.gov
> ---------------------------------------------------------------------------------------------------------
> 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" <jason.roberts at duke.edu>"Jason 
> Roberts" <jason.roberts at duke.edu>
> 
> *"Jason Roberts" <jason.roberts at duke.edu>*
> Sent by: gdal-dev-bounces at lists.osgeo.org
> 
> 01/11/2010 05:32 PM
> 
> 	
> 
> To
> 
> 	
> 
> 
> "'gdal-dev'" <gdal-dev at lists.osgeo.org>
> 
> 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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev