[gdal-dev] Open source vector geoprocessing libraries?

[Frank Warmerdam]

Jan Hartmann wrote:
> 
> 
> On 13-1-2010 21:19, Mateusz Loskot wrote:
>>
>> IMHO, it's misunderstanding to consider OGR fully featured data model
>> and I/O engine to read, write, process and analyse spatial vector data,
>> especially if performance is a critical factor. IMHO, there are too many
>> compromises in OGR.
>>
>>    
> OK, that is a very clear statement. I must say that I always thought of 
> OGR as an independant GIS data model, the most encompassing of all, and 
> that it could (in principle anyway) be used in some sort of stand-alone 
> fashion.. I certainly can imagine, however, that for real applications 
> it is not as optimal as more specialized formats.

Folks,

My position would be that OGR attempts to address the simple features
data model well, but it is very lacking when you take a small step beyond
that.  For instance, there is no way to recognise relations between layers,
no standard way to understand non-simple features geometry models like
topological layers, and no metadata beyond the coordinate system.

Also, as I think Mateusz is suggesting, the performance characteristics
of different OGR drivers varies greatly.  That said, I think for many
applications OGR does a pretty good job of exposing the underlying
file formats / repositories in as efficient a means as is practical.
For instance, it is possible to pass SQL queries through to underlying
database where available for efficient evaluation, and there is a
mechanism to do fast (simple) spatial queries where the data store
supports it.

There is of course some non-trivial overhead converting underlying features
into OGRFeatures, and as was noted there is some performance impedance
between OGR and GEOS due to the need to translate geometries frequently.

I do still think it would be better to treat a geoprocessing library as
something built on top of OGR and GEOS rather than baked-in to OGR
but in part I think that because I'm not very comfortable that the
approaches are well enough understood to bake them in safely.

As I've mentioned before, I might make lots of mistakes with GDAL/OGR
but at least I don't fix them.  By that I mean once something is
baked into the API and the data model I try not to alter them in a
disruptive fashion.  That means, among other things, that some caution
is necessary before adding a lot of new functionality or extending the
model in a big way.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent