[OpenLayers-Dev] OL trunk + MapServer 6.0 + BBOX Strategy ->
WFS server error. Invalid or Unsupported FILTER in GetFeature
Roald de Wit
list at rdewit.net
Mon Jul 18 20:12:42 EDT 2011
Hi Andreas,
Thanks for fixing this bug and your example requests below. Now let's
hope that MapServer fixes their WFS 1.1.0 bug soon. :-)
Cheers, Roald
On 18/07/11 19:01, Andreas Hocevar wrote:
> 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
>>
>
>
More information about the Dev
mailing list