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

[Rahkonen Jukka]

Even Rouault wrote:

> 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#a6c495581900c8301dff91d8c
d3ee12f ) 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 ?

I think I am going to count on you. About extent computing, it 
might be good to check how bForce behaves with Oracle driver. 
Selecting aggregate MBR from Oracle is very heavy.

> > 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 ...

I agree, I totally forgot both the deegree server behaviour 
and complicated application schemas. But is it ever safe to  
guess the schema by investigating just the first feature? If the
attribute is not compulsory in the schema and the value 
happens to be empty then it is not included at all in the GML of
the first feature. Doesn't this mean that GML driver creates a 
schema without that attribute even the following features may 
have values for it?


-Jukka Rahkonen-