[fdo-dev] Classes and properties in SHP providers
Jason.Birch at nanaimo.ca
Wed Nov 1 11:28:28 EST 2006
I think this makes a lot of sense. If you could provide a default (and
slow) implementation of many of the capabilities (such as ordering
results, maybe using GEOS for some spatial filters after an initial
envelope query, etc) and then overriding these default capabilities with
faster native methods when they exist, less code would have to be
written overall and client apps would have less difficulty accounting
for differences. Same goes with "safe" type casts, etc. Anything that
can be done to make writing providers and client apps easier will help
to spread the use of FDO.
From: Frank Warmerdam
Sent: Wednesday, November 01, 2006 07:18
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] Classes and properties in SHP providers
In the case of GDAL and OGR this has generally meant a "thicker"
layer between the provider and the application. So that missing
capabilities can be filled in.
More information about the Fdo-internals