Opened 20 years ago
Closed 19 years ago
#824 closed defect (fixed)
behaviour of DUMP TRUE in WFS interface
Reported by: | Owned by: | mapserverbugs | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | WFS Server | Version: | 4.3 |
Severity: | normal | Keywords: | |
Cc: |
Description
If I have a layer in my MAP file which does not have DUMP TRUE, the layer ends up in the WFS capabilities. When a GetFeature request is performed, the following result is retrieved: <?xml version='1.0' encoding="ISO-8859-1" ?> <wfs:FeatureCollection xmlns="http://www.ttt.org/myns" xmlns:myns="http://www.ttt.org/myns" xmlns:wfs="http://www.opengis.net/wfs" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs /1.0.0/WFS-basic.xsd http://www.ttt.org/myns http://barte/cgi-bin/mapserv.exe? map=/ms4w/apps/general/map/basispakket.map&SERVICE=WFS&VERSION=1.0.0& ;REQUEST=DescribeFeatureType&TYPENAME=bodemkaart250"> <gml:boundedBy> <gml:null>inapplicable</gml:null> </gml:boundedBy> </wfs:FeatureCollection> Maybe this behaviour chould be changed into the following to make it more user-friendly, I propose 2 options: 1. do not add layers which don't have DUMP TRUE to the WFS capabilities at all (maybe produce a warning in the capabilities). This also has implications for DescribeLayer on the SLD WMS interface. 2. generate an exception instead of an empty null GML response stating that no features are available because DUMP TRUE has not been set on the layer. I would be in favour of option 1.
Change History (6)
comment:2 by , 20 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Are you sure that the TYPENAME that you used in your request was listed in Capabilities? I had a look in the code, and we were already including only the layers with DUMP TRUE in the WFS Capabilities (in 4.2 and 4.3). However, it would have been possible to get the empty GML that you got if you specified an invalid TYPENAME, either because that layer name doesn't exist, or because it cannot be served as a WFS. I have modified mapwfs.c so that it produces an exception if you request a TYPENAME that was not listed in Capabilities. Marking fixed. This was done in 4.3 CVS only.
comment:3 by , 20 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Hi Daniel, I checked, you're right they don't end up in the capabilities, sorry for that mistake. But they do end up in the SLD WMS DescribeLayer response. This should not happen I think, as then clients will ask the WFS for the data on that typename and get the strange empty response. <?xml version='1.0' encoding="ISO-8859-1"?> <!DOCTYPE WMS_DescribeLayerResponse> <WMS_DescribeLayerResponse version="1.1.0" > <LayerDescription name="top250namen" wfs="http://barte/cgi-bin/mapserv.exe?map=/ms4w/apps/general/map/basispakket.map&"> <Query typeName="top250namen" /> </LayerDescription> </WMS_DescribeLayerResponse>
comment:4 by , 19 years ago
To get the layer listed in DescribeLayerResponse with a wfs link, you have to set up wfs_onlineresource metadata on the layer. If you do not set it up It won't show. If you set it up, you should make sure that it is queryable. Do you see any other way of testing for this ? (dump in my opinion is not an option, since we are dealing with wms layers)
comment:5 by , 19 years ago
The DTD part of the SLD spec says the following: If the namedlayer is not feature based, then the LayerDescription has no further contents. If DUMP TRUE has not been set, the layer has no features on its WFS, so you could think of it as not a feature based layer. An empty LayerDescription would be a better response in my opinion. What do you guys think?
comment:6 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Closing this bug as the original issue has been resolved. The question whether or not it would be better to return an empty LayerDescription on a WMS DescribeLayer request if DUMP TRUE has not been set is a different issue and should be discussed in a new bug. But I don't rate this highly enough for opening a new bug.
Note:
See TracTickets
for help on using tickets.