[mapserver-dev] Call for discussion on MS RFC 114: Faster retrieval of shape count

[Even Rouault]

Le mercredi 10 février 2016 15:51:47, Rahkonen Jukka (MML) a écrit :
> Even Rouault wrote:
> > Le mercredi 10 février 2016 14:10:56, Rahkonen Jukka (MML) a écrit :
> > > Even Rouault wrote:
> > > > But I agree with you that the text of the standard could make think
> > > > that the server side limit should be taken into account by
> > > > resultType=hits, although it is not explicit at all...
> > > 
> > > What is most standard in all WFS standard versions is that they are
> > > not explicit.
> > 
> > Agreed...
> > 
> > > For me it is OK to ignore server side maxFeatures limit with
> > > resultType=hits through the metadata configuration option. At least we
> > > have considered the case.
> > 
> > Yes the metadata config option lets the possibility for the administrator
> > to select the desired behaviour.
> 
> The drawback is that users can't know what the administrator has decided to
> do and one service sends different results than some other. I think that
> there would be an obvious benefit if WFS had support for both query types.

The WFS specifications being not clear, servers having different behaviours, I'm 
not sure there's an ideal solution. This is a spec issue, that this proposed 
implementation tries to cope with.

I'm not sure adding a new vendor parameter is something that is going to 
improve interoperability, and that goes a bit beyond my intended scope of 
work. Anyway if we wanted to add that later, that would be something that 
could be added on top of the proposed RFC implementation. This would override 
the "wfs_maxfeatures_ignore_for_resulttype_hits" value (possibly only allowing 
it to transition from "true" to "false", and not the reverse : if the 
administrator wants to limit the count to maxFeatures, the user shouldn't be 
able to go against this )

> I am pretty sure that every SQL user does sometime
> a) select count(*) from table;
> but also
> b) select count(*) from table where attribute=...;

Hum, why do you mention this ? resultType=hits DOES takes into account the 
potential BBOX or FILTER, with and without this RFC.
The discussion about whether to limit the returned count to the 
wfs_maxfeatures limit or not is completely unrelated.

> 
> > I'm now wondering if defaulting wfs_ignore_server_maxfeatures_for_hits to
> > true is appropriate in the PostGIS case. Before you pointed out that
> > issue, I thought initially that ignoring the server maxfeatures limit
> > for hits was the compliant way, but it is not so clear. On the other
> > side, even if we are not compliant with the RFC implemented, we'll
> > behave the same as other WFS server implementations...
> 
> I fear it is rather "behave the same as SOME other WFS server
> implementations..." . At least deegree is sending the same count than
> resultType=results from http://demo.deegree.org/utah-workspace/
> 
> I tested by selecting the wfs service URL and changing BBOX in request:
> <GetFeature xmlns="http://www.opengis.net/wfs"
> xmlns:app="http://www.deegree.org/app"
> xmlns:gml="http://www.opengis.net/gml"
> xmlns:ogc="http://www.opengis.net/ogc"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1.0"
> xsi:schemaLocation="http://www.opengis.net/wfs
> http://schemas.opengis.net/wfs/1.1.0/wfs.xsd" resultType="hits">
> 
>   <Query typeName="app:DominantVegetation">
> 
>   <PropertyName>app:objectid</PropertyName>
>   <PropertyName>app:code</PropertyName>
> 
>   <ogc:Filter>
>     <ogc:BBOX>
>       <ogc:PropertyName>app:geom</ogc:PropertyName>
>       <gml:Envelope srsName="urn:ogc:def:crs:EPSG::26912">
>         <gml:lowerCorner>414055.0 4404348.0</gml:lowerCorner>
>         <gml:upperCorner>452132.0 4426933.0</gml:upperCorner>
>       </gml:Envelope>
>     </ogc:BBOX>
>   </ogc:Filter>
> 
>   </Query>
> </GetFeature>

This returns 24 features, so I don't see how that tests server-side limit. 
Especially since the GetCapabilities doesn't return any CountDefault value.

> 
> I found one ArcGIS server and that does not support resultType at all:
> 
> http://gtkdata.gtk.fi/arcgis/services/GTKWFS/MapServer/WFSServer?service=wf
> s&version=1.1.0&request=getfeature&typename=GTKWFS:kallioperahavainnot&resu
> ltType=hits&maxfeatures=1

Yes, completely different issue though. I thought this was because of the 
maxFeatures, but when removing it, you get the whole features. So it really 
looks like it doesn't support resultType at all indeed, even if it advertizes 
it in GetCapabilities.

> 
> -Jukka-

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