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