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

[Andreas Hocevar]

Hi Roald,

On Mon, Jul 18, 2011 at 2:36 AM, Roald de Wit <list at rdewit.net> wrote:
> 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?

Yes, the WFS 1.0 spec demands a PropertyName in the BBOX filter. On a
side note, MapSever should never have worked with your default
Protocol.WFS configuration, unless you had set gml_geometries in your
mapfile metadata to "the_geom". Looks like MapServer requires the
PropertyName, but doesn't respect the value you provide there.

> In other words:
> could you reproduce the error yourself using MapServer?

Yes. See this GET request:
http://demo.mapserver.org/cgi-bin/wfs?SERVICE=WFS&VERSION=1.0.0&REQUEST=getfeature&TYPENAME=continents&FILTER=%3CFilter%3E%3CBBOX%3E%3Cgml:PropertyName%3Ethe_geom%3C/gml:PropertyName%3E%3Cgml:Box%3E%3Cgml:coordinates%3E16.0,47.0%2016.1,47.1%3C/gml:coordinates%3E%3C/gml:Box%3E%3C/BBOX%3E%3C/Filter%3E

The PropertyName is set to the_geom. But MapServer still returns
Austria correctly, although the geometryName is msGeometry and not
the_geom. But only looking at it from an XML schema validation
perspective, MapServer is right to complain about an invalid filter in
this request:
http://demo.mapserver.org/cgi-bin/wfs?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=continents&FILTER=%3CFilter%3E%3CBBOX%3E%3Cgml:Box%3E%3Cgml:coordinates%3E16.0,47.0%2016.1,47.1%3C/gml:coordinates%3E%3C/gml:Box%3E%3C/BBOX%3E%3C/Filter%3E

On the other hand, MapServer should not complain about this request:
http://demo.mapserver.org/cgi-bin/wfs?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=continents&SRSNAME=CRS:84&FILTER=%3CFilter%3E%3CBBOX%3E%3Cgml:Box%3E%3Cgml:coordinates%3E16.0,47.0%2016.1,47.1%3C/gml:coordinates%3E%3C/gml:Box%3E%3C/BBOX%3E%3C/Filter%3E

It is WMS 1.1, the PropertyName is not mandatory.

Andreas.

> 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
>>>
>>
>>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>



-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.