[WFS] Set max features to 0

Brock Anderson banders at REFRACTIONS.NET
Thu Feb 16 12:00:17 EST 2006


Good point. 

I don't believe the WFS spec. allows servers to disable getFeature 
requests completely, so clients would have no notice that getFeature 
requests are set to return nothing.  That could be slightly confusing to 
WFS clients who see that getFeature is enabled in the capabilities document.

Allowing wfs_maxfeatures=0 wouldn't be a perfect solution, but it might 
be the best we can do given limitations of the specs. 

Brock

Yewondwossen Assefa wrote:

>
>  I don't see any obvious side effect for setting the 
> wfs_maxfeatures=0.  The only thing that needed to be documented is 
> that when you do a wfs query and use the MAXFEATURES parameter 
> (allowed values start with 1), It might end up retruning nothing if 
> the wfs_maxfeatures is set to 0.
>
>
> Brock Anderson wrote:
>
>> I think wfs_maxfeatures would work if it allowed a value of 0, but it 
>> appears that 0 is essentially the same as not setting 
>> wfs_maxfeatures.  wfs_maxfeatures > 0 works as expected (limiting the 
>> number of features returned by getFeature).
>> Is there a reason we don't allow wfs_maxfeatures = 0?  Would making 
>> that option available have other side effects?
>>
>> Brock
>>
>> Bart van den Eijnden wrote:
>>
>>> There is already a wfs_maxfeatures METADATA which could serve this
>>> purpose, and which can be used to limit the features returned by a WFS
>>> server-side.
>>>
>>> Are you guys trying MAXFEATURES or wfs_maxfeatures?
>>>
>>> Best regards,
>>> Bart
>>>
>>>  
>>>
>>>> Maxfeatures was introduced as a rendering parameter (works great 
>>>> when data
>>>> are sorted by area for interest), but has taken on special meaning in
>>>> other circumstances. We'd probably have to introduce another DUMP 
>>>> state...
>>>> DUMP FALSE would exclude the DescribeFeatureType output I imagine.
>>>>
>>>> If you guys file a bug we can hack something together in 4.9 for 
>>>> you to
>>>> test...
>>>>
>>>> Steve
>>>>
>>>>  
>>>>
>>>>>>> Paul Ramsey <pramsey at refractions.net> 02/15/06 11:09 PM >>>
>>>>>>>         
>>>>>>
>>>>
>>>> Perhaps... the intent is to have access to DescribeFeatureType (in
>>>> order to compose valid SLD) while not allowing GetFeatures to return
>>>> any features (to protect the actual feature sources).  All hail the
>>>> WMS/SLD combination, neutered without partial WFS access!
>>>>
>>>> P
>>>>
>>>> On 15-Feb-06, at 8:55 PM, Steve Lime wrote:
>>>>
>>>>  
>>>>
>>>>> Clint: Perhaps I don't understand the question, but doesn't setting
>>>>> DUMP FALSE for a given layer get you this? That should keep WMS
>>>>> GetFeature and any WFS request from returning feature information,
>>>>> yet allow maps to be made.
>>>>>
>>>>> Steve
>>>>>
>>>>>    
>>>>>
>>>>>>>> Clint Johnson <cjohnson at REFRACTIONS.NET> 02/15/06 7:00 PM >>>
>>>>>>>>           
>>>>>>>
>>>>>
>>>>> Hi guys,
>>>>>
>>>>> Is it possible to disable a layer's contents from appearing in a
>>>>> GetFeature WFS request in terms of a mapping file setting?  If not,
>>>>> then
>>>>> can you give any advice reguaring where I can add such functionality
>>>>> into the mapserver source code?
>>>>>
>>>>> I essentially want to have a mechanism where I "protect my data"; 
>>>>> that
>>>>> is, where a complete graphical representation of my data (aka map) 
>>>>> can
>>>>> be viewed via a GetMap WMS request, yet be private/encapsulated by
>>>>> means
>>>>> of hidden to WFS request (in terms of not returning any features 
>>>>> for a
>>>>> WFS request).  And selective in the sense that this functionality
>>>>> can be
>>>>> applied on a per layer basis without having to completely disable WFS
>>>>> altogether.
>>>>>
>>>>> I've looked at the mapserver source code (all occurrences of
>>>>> MAXFEATURES/maxfeatures) and I see a lot of checks for >0 -- which
>>>>> reaffirms my observation that "MAXFEATURES 0" is the same as not
>>>>> specifying MAXFEATURES at all.  My guess is that anything less than 1
>>>>> (and by default -1) is being used denote MAXFEATURES as being not 
>>>>> set.
>>>>>
>>>>> Thanks,
>>>>> Clint
>>>>>     
>>>>
>>>>
>>>>   
>>>
>
>



More information about the mapserver-dev mailing list