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

[Rahkonen Jukka (MML)]

Even wrote:
> > 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 have discarded vendor parameter and mainly thinking about what WFS 3.0 standard could say about counting hits.

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

Was a non-relevant comment which arise from too much thinking and not enough coffee. I was awake until now, though.

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

Quoting "Was a non-relevant comment which arise from too much thinking and not enough coffee. I was awake until now, though."
> 
> > 
> > I found one ArcGIS server and that does not support resultType at all:
> > 
> > http://gtkdata.gtk.fi/arcgis/services/GTKWFS/MapServer/WFSServer?servi
> > ce=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-