[gdal-dev] Possible to test for a layer capability before creating a layer?

[Even Rouault]

Le vendredi 19 février 2016 07:23:42, Ari Jolma a écrit :
> 19.02.2016, 02:23, Even Rouault kirjoitti:
> > Le vendredi 19 février 2016 00:55:21, Nyall Dawson a écrit :
> >> Hi all,
> >> 
> >> I'm aware that for drivers I can use OGR_Dr_TestCapability to
> >> determine whether a particular driver as a specific capability. But is
> >> there anyway to test whether a specific driver also has support for a
> >> layer capability?
> >> 
> >> The situation is that I'd like to populate a list with all available
> >> OGR drivers for which a created layer would then be able to support
> >> SequentialWrite, DeleteFeature, RandomWrite and CreateField.
> >> 
> >> What would be the best way to go about this?
> > 
> > There seems to be growing interests for such topic (see yesterday similar
> > thread :
> > https://lists.osgeo.org/pipermail/gdal-dev/2016-February/043782.html )
> > 
> > The way to go is to add such capability flags at the driver metadata
> > level. This is now possible since GDAL 2.0 since OGR drivers can expose
> > arbitrary metadata items.
> > What has to be done :
> > - define which capabilities must be exposed
> > - enhance drivers to advertize them
> 
> In this case the question is about existing layer capabilities. One
> obstacle to testing them is that there is usually no way to create
> "blank" or minimal layer objects. For example Shapefile layer
> constructor requires all kinds of information and it represents an
> actual file (which can be in memory, though).
> 
> Blank or minimal layer objects could be useful as they can answer
> capability questions - the TestCapability method usually requires no or
> only minimal property information (is the layer read only or not, is
> filtering on).
> 
> Hm. Since the property information plays a part, the capability is not
> always a simple on/off issue, but the answer to a question whether a
> layer has a specific capability can also be "it depends" if you only
> know the driver.

I agree that in theory the capabilities depend on a context : read-only vs 
update mode being the most common one, but there are more subtle ones 
depending on drivers ( some drivers only support CreateField if no feature has 
already been written for example, FastSpatialFilter generally depends on the 
actual presence of an index, FastFeatureCount conditionalized by the absence 
of an attribute filter, etc.. ). But I guess there are use cases where you 
would want to know the maximum theoretical capabilities of a driver, and be 
prepared that they are not all available at runtime.

The blank layer approach might be an approach, but I guess it could be non 
trivial in some drivers to instanciate such a layer. At the very least such a 
layer should be only an implementation detail not visible of the external 
user. The issue is also true for datasets since a few dataset capabilities 
require a dataset instance.
That's why my intuition would be to have simple properties attached to the 
driver, the drawback being some code duplication with the runtime mechanism.

> 
> Ari
> 
> >> Nyall
> >> _______________________________________________
> >> 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

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com