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<l...@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<l...@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"<l...@rdewit.net
<mailto:l...@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"<l...@rdewit.net
<mailto:l...@rdewit.net> <mailto:l...@rdewit.net
<mailto:l...@rdewit.net>>> wrote:
>>
>> H...
d...@lists.osgeo.org<mailto:d...@lists.osgeo.org>
<mailto:d...@lists.osgeo.org<mailto:d...@lists.osgeo.org>>
>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
_______________________________________________
Dev mailing list
d...@lists.osgeo.org<mailto:d...@lists.osgeo.org>
http://lists.o...
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
