[gdal-dev] Open source vector geoprocessing libraries?

[Peter J Halls]

Dear All,

Mateusz Loskot wrote:
%< Snip
> 
> Yes. Also, most applications I've seen using OGR do define their own
> data models and translate OGRFeature to features of their own types.
> Perhaps it would be interesting to know why they don't use OGRFeature
> as a part of their data model, what's missing...

Thinking about this in terms of my own programs, I think that it is not 
necessarily that OGRFeature is missing anything but rather that my program data 
structures (objects) are designed for some specific task.  So, for example, I 
have a program that reads from a GPS and creates OGRFeatures for storage 
somewhere using OGR; another uses OGR to read data of some format and then 
builds a Green & Sibson neighbourhood structure from the OGRFeatures in order to 
measure neighbourhood characteristics and writes or updates attribute tables; 
and so on.  These simple OGC-type features are, for me, ideal input into or 
output from what are primarily research models.  Indeed, were the data structure 
more complex, I should probably have to unpick it into a more simple structure, 
like OGRFeature, in order to build appropriate data structures for whatever it 
was I was doing.

Note: I am not using OGR as a component of a GIS, rather my programs are either 
extensions to GIS methodology (eg neighbours and cluster detection) or are 
designed to model the behaviour of some phenomenon.  I use OGR for format 
independent spatial object IO because it is easy to map OGR objects to my 
objects.  This means that I use my own object methods for tasks like 
intersection detection, etc, when needed.

Having said that, do I want more?  There are times when geometric topology is, 
or could be, very useful.  Currently, if I really want that, I create an ESRI 
'coverage' dataset and use that as input via infolib: its not necessarily ideal 
and I have no idea how long that format will persist, but it serves my needs 
well.  I do not think I would expect OGR to offer topology functions, though: I 
think I would expect to use a separate but related library to build topology 
from OGRFeatures.

> 
>> 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.
> 
> There usually is yet another step (cost), it is translation from
> OGRFeature to feature of application's data model.

This is very true and is probably inevitable, unless one is inventing the wheel 
yet again.  Of course, the overhead can be minimised by the use of appropriate 
structures and avoiding repetition.

Dunno how useful that is to anyone else, but if it is, then great.

Best wishes,

Peter

--------------------------------------------------------------------------------
Peter J Halls, GIS Advisor, University of York
Telephone: 01904 433806     Fax: 01904 433740
Snail mail: Computing Service, University of York, Heslington, York YO10 5DD
This message has the status of a private and personal communication
--------------------------------------------------------------------------------