[gdal-dev] Re: Are these WFS issues worth filing tickets?

[Even Rouault]

Selon Jukka Rahkonen <jukka.rahkonen at mmmtike.fi>:

> Even Rouault <even.rouault <at> mines-paris.org> writes:
>
> > > How about having an option -TRUST_GETCAPABILITIES=TRUE and use it as
> > > a default value? So number of feature could be examined with
> > > resulttype=hits and extents could be taken as they are in the
> > > getCapabilities. Or perhaps they could be reported as unknown if
> > > reprojecting the lat/lon bounding box feels bad or is
> > > inaccurate/impossible? Extents are not always so interesting.
> > >
> >
> > I also somehow imagined that. Perhaps you could file a ticket about that,
>  so it
> > can be eventually considered later.
>
> After all, such option would not make sense with ogrinfo tool and therefore I
> will not make a ticket about it. GetCapabilities is sending fixed information
> about the whole layer and that is unusable if user is making selections with
> -where, -sql or -spat parameters. In that case the only possibility to get
> the
> desired information is to read the features.

Well, the GetExtent() API has not a well defined semantics regarding to whether
it should take the filters into account or not ( see
http://gdal.org/ogr/ogr__api_8h.html#a6c495581900c8301dff91d8cd3ee12f ) and
indeed, there is a lot of variations between drivers. So I still believe that
the configuration option could make sense.

... but while looking at GetExtent() API more closely, I see that there is a
bForce parameter that could be used : """ If bForce is FALSE, and it would be
expensive to establish the extent then OGRERR_FAILURE will be returned
indicating that the extent isn't know. If bForce is TRUE then some
implementations will actually scan the entire layer once to compute the MBR of
all the features in the layer """ . AFAIR, very few drivers actually check the
value of the bForce driver (I cannot quote a single one from my memory which
would use it. I should do extensive searching). ogrinfo currently sets bForce =
TRUE. An option would be to change the default to FALSE, and add an option to
ogrinfo "-compute_extent" to explicitely set bForce to TRUE if needed.

So for the WFS driver, GetExtent(bForce = FALSE) would return a OGRERR_FAILURE,
whereas GetExtent(bForce = TRUE) would do the current behaviour.

What do you think ?

>
> My next bid is to try to teach the users to avoid unintentionally heavy
> requests by adding a new paragraph into the WFS driver document page
> http://gdal.org/ogr/drv_wfs.html
>
> Using ogrinfo
> =============
> Ogrinfo tool tries to apply the spatial and attribute filters from the
> command
> line and fetches then data from the WFS service. If no fiters are given this
> will lead to reading all features from a WFS data source with a GetFeature
> request. This can be a slow operation. Particularly when ogrinfo is used with
> the 'all layers' parameter (ogrinfo -al) it will make sequential request for
> fetching the contents of each feature type from the whole WFS service. When
> exhaustive layer info is not needed the use of special layers
> WFSLayerMetadata
> and WFSGetCapabilities offer a much faster access to WFS service metadata.

Thanks. Makes sense to document the behaviour of current releases.

>
> My last suggestion is to make third special layer or actually set of special
> layers. It could be named as WFSLayerSchema and it would return the schema
> that
> is captured by making a DescribeFeatureType query. Usage might be like
> "ogrinfo
> WFS:server.com/wfs WFSLayerSchema:[featureType]. Now the only way see the
> shema
> is to use the heavy request.

I don't know if it would still be usefull if the slowness of GetExtent() is
solved. In addition, there are some caveats :
* For example, Deegree WFS servers (at least the demo ones) generally return a
DescribeFeatureType with a lot of xs:include, but not interesting content. For
that you need to downloaded the referenced xsd in the includes. The OGR WFS
driver gives up at that point and just tries to establish the layer definition
by requesting just one feature.
* Sometimes the GML driver isn't smart enough to understand the schema (because
it contains nested attributes, or of non-primitive types), so it will also
establish the layer definition by requesting just one feature. So the actual
layer definition returned by the driver can be a bit (or a lot) different from
the one advertized in DescribeFeatureType. (In which case attribute or spatial
filtering won't work due to the mismatch ...). WFS administrators : you'd better
stick to the GML SF-0 implementation profile ...