[OpenLayers-Dev] OL trunk + MapServer 6.0 + BBOX Strategy -> WFS server error. Invalid or Unsupported FILTER in GetFeature

[Roald de Wit]

Hi Andreas,

Thanks, that patch solves it for me using protocol version 1.0.0 and MS 
5.6.x (and I assume for 6.0.x too). Specifying version 1.1.0 indeed 
results in the expected behaviour of the PropertyName being absent from 
the request (as expected).

Can I safely assume that my problem could not have been caused by a 
poorly configured WFS service on my side and that the WFS 1.0.0 spec 
really requires the PropertyName to be part of the BBOX filter? In other 
words: could you reproduce the error yourself using MapServer?

Cheers, Roald

On 18/07/11 05:46, Andreas Hocevar wrote:
> Hi Roald,
>
> please let me know http://trac.osgeo.org/openlayers/ticket/3415 looks
> good to you - with that patch applied, you should be able to use your
> old configuration again, unless you set the protocol version to 1.1.0
> (default is 1.0.0), in which case the requirement for a propertyName
> in the BBOX filter would come from the MapServer bug
> http://trac.osgeo.org/mapserver/ticket/3955.
>
> Andreas.
>
> On Sun, Jul 17, 2011 at 12:41 AM, Roald de Wit<list at rdewit.net>  wrote:
>> Hey Andreas,
>>
>> Thanks, it works again when adding a geometryName to the protocol.
>>
>> 2 things:
>> 1) this does change behaviour, so it would be important to document it
>> clearly in the release notes for 2.11 (if this makes it in there)
>> 2) in the comments in ticked #3368, bartvde says:
>>
>>    "Maybe there is a WFS out there that needs PropertyName, but ignores
>>    its value for WFS 1.0. But I think we can safely ignore until
>>    someone files a bug with a case that fails. "
>>
>>
>> This is exactly the case for me with MS 6.0.x and 5.6.x too. MS needs a
>> PropertyName (can be anything so it seems!) and gives an error if it is
>> missing.
>>
>> It's a small change for me to add geometryName (or featureNS) to the
>> protocol options. I'm just slightly concerned that there are more people out
>> there currently only using featurePrefix and featureType that might not
>> understand why their requests suddenly fail when using the new WFS protocol
>> behaviour.
>>
>> Cheers,
>>
>> Roald
>>
>> On 17/07/11 03:24, Andreas Hocevar wrote:
>>> Hey Roald,
>>>
>>> what you describe is exactly the new expected behavior. However, if you
>>> add either a featureNS or a geometryName, things should be working again.
>>>
>>> Let me know if you still have concerns, or if and where you think this
>>> should be better documented. If the former, do you have a suggestion how we
>>> could better solve this? Because the intention of the change you suffer from
>>> was to make dynamic WFS configuration simpler.
>>>
>>> Andreas.
>>>
>>>> On Jul 16, 2011 2:38 PM, "Roald de Wit"<list at rdewit.net
>>>> <mailto:list at rdewit.net>>  wrote:
>>>>
>>>> Hey Andreas,
>>>>
>>>> It's true that I don't set the FeatureNS. However, I *do* set the
>>>> featureType *and* the featurePrefix in my protocol options, which used to be
>>>> sufficient.
>>>> If you take the wfs-protocol.html example from trunk and replace
>>>> featureNS with: featurePrefix: 'topp', you'll see that the PropertyName
>>>> disappears from the WFS request (in the BBOX filter).
>>>>
>>>> Is this expected behaviour, ie: can I not use featurePrefix anymore or is
>>>> it a bug?
>>>>
>>>> Thanks, Roald
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 16/07/11 19:59, Andreas Hocevar wrote:
>>>>
>>>>     >
>>>>     >
>>>>     >  Hey Roald,
>>>>     >
>>>>     >  the PropertyName will still always be set, unless you have a
>>>>     poorly configured ...
>>>>
>>>>         >>  On Jul 16, 2011 8:25 AM, "Roald de Wit"<list at rdewit.net
>>>>         <mailto:list at rdewit.net>  <mailto:list at rdewit.net
>>>>         <mailto:list at rdewit.net>>>  wrote:
>>>>         >>
>>>>         >>  H...
>>>>
>>>>         Dev at lists.osgeo.org<mailto:Dev at lists.osgeo.org>
>>>>         <mailto:Dev at lists.osgeo.org<mailto:Dev at lists.osgeo.org>>
>>>>
>>>>
>>>>         >>  http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> Dev at lists.osgeo.org<mailto:Dev at lists.osgeo.org>
>>>> http://lists.o...
>>>>
>> _______________________________________________
>> Dev mailing list
>> Dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>>
>
>