Opened 21 years ago
Closed 13 years ago
#300 closed enhancement (fixed)
[WMS] Extend behavior of DUMP mapfile parameter for GML output
Reported by: | dmorissette | Owned by: | dmorissette |
---|---|---|---|
Priority: | high | Milestone: | 6.0 release |
Component: | WMS Server | Version: | 4.1 |
Severity: | minor | Keywords: | |
Cc: | pspencer@…, havard.tveite@…, doug@… |
Description (last modified by )
Doug Cates wrote: > > I'm using MapServer 3.6.4 as a WMS server, and it is working very well. For > the GetFeatureInfo request, I'm asking for the info in format > "application/vnd.ogc.gml", which works fine if "DUMP true" is added to the > map file for each queryable layer. The result returns attribute values and > geometry. > > I'm asking for it this way so I can process the XML response, move the > values into a recordset, and use the results in my application in a number > of ways. Most of the time, I don't need the geometry. Since the geometry can > be quite large, it wastes a lot of bandwidth and time when I don't need it. > I'd like some way of turning the geometry off when it isn't required, or > when I don't care to expose the geometry to other users of my services. > > I propose that the DUMP directive be extended, with more options than true > or false. Something like: > > DUMP true > Outputs all attribute fields and geometry. > > DUMP false > Disable GML output. > > DUMP attributes > Outputs attribute fields only (no geometry). > > DUMP "field1,field2,...." > Outputs specified fields only. Output geometry only if geometry/shape field > name included. >
Change History (19)
comment:3 by , 21 years ago
Cc: | added |
---|
comment:5 by , 21 years ago
See also bug 142 that proposed a slightly different approach to solve the same issue.
comment:6 by , 21 years ago
Cc: | added |
---|
comment:7 by , 21 years ago
It's not that critical and we could plan for a 4.1 release in the fall. With the MapText support comming I think that will be a necessity. I go back and forth on the implementation anyway. Me thinks it can be as simple as SERVICES WMS|WFS|NONE where: - WFS is essentially the same as DUMP TRUE - WMS is essentially the same as DUMP FALSE - NONE turns it all off The only drawback to this is that you get geometry by default with WFS and I don't know if that's ok. Seems to me that if it's a feature service then you should get the features. As a workaround we could support WMSGML and WFSGML. If it were that simple then we could bang it out quickly. I not sure this is an exact duplicate of bug 142 or vice versa. I think we need a generic way of limiting the availablity of attributes via queries and that could be leveraged by WFS/WMS as well. Something as simple as ITEMS "item1,item2,item3".
comment:8 by , 21 years ago
Maybe we're mixing bugs 337 and bug 300 here. bug 142 and bug 300 are about defining wich items to dump in GML, so 142 is really a duplicate of 300, and Steve's suggestion of using ITEMS "item1,item2,item3" should work great for that. bug 337 is the one about enabling layers for WMS, WFS or other services independently, and in the SERVICES parameter would solve that. I'll copy Steve's comment to bug 337.
comment:9 by , 21 years ago
Note that as part of this we also need to be able to control whether the geometry of the shapes should be published or not... some WFS servers may want to publish only attributes but not geometries. If we go with the ITEMS "item1,item2,item3" idea from comment #5, we could extend it to use a special "GEOMETRY" item name or equivalent to specify the geometry, e.g. ITEMS "GEOMETRY,item1,item2,item3"
comment:10 by , 21 years ago
Cc: | added |
---|
I have a comment to add. This is the result of a WMS GetFeatureInfo, right? I think that this could always return the attribute information in GML and if DUMP is set to TRUE then you would also return the geometry? Or perhaps via WMS, you should never return the geometry ... and if you want the geometry, use WFS and GetFeature?
comment:11 by , 21 years ago
I wrote this request before WFS was considered. I think that it is reasonable to expect that a WFS will always return geometry if requested, but there may still be cases where one may wish to not publish all of the fields in a GetFeature request. I also think that the ability of MapServer to return geometry in WMS GetFeatureInfo is a useful thing, and shouldn't be disabled completely, but it should be controllable in the map file somehow. Perhaps something more finely grained is needed to control the XML output separately for each service, like: SERVICE WMS ITEMS "field1,field2..." END SERVICE WFS ITEMS ALL END ... where ITEMS can contain fields, or keywords like ALL or NO_GEOMETRY. I think that they should both default to ALL.
comment:12 by , 21 years ago
.. also, sort of related to this is that there should be some way to individually turn on and off WFS for a layer, e.g. have a layer support WMS GetFeatureInfo and not WFS GetFeature. I'm not sure whether this is a new item like: SERVICE WMS ENABLE TRUE ITEMS NO_GEOMETRY END SERVICE WFS ENABLE FALSE END or something that uses the items, like DUMP FALSE does now: SERVICE WMS ITEMS NO_GEOMETRY END SERVICE WFS ITEMS NONE END
comment:13 by , 21 years ago
Cc: | added |
---|
Doug, about your comment #10, you're correct that this is indirectly related, this is covered by bug 337 as mentioned in comment #6 above.
comment:14 by , 20 years ago
Milestone: | → FUTURE |
---|---|
Status: | new → assigned |
This is not happening in 4.4 for sure. Setting FUTURE milestone. See comment #6 about what needs to be done in this bug and related bugs.
comment:15 by , 18 years ago
Milestone: | FUTURE → 5.0 release |
---|
comment:16 by , 17 years ago
Description: | modified (diff) |
---|---|
Milestone: | 5.0 release → 5.2 release |
comment:17 by , 16 years ago
Milestone: | 5.2 release → 5.4 release |
---|
comment:18 by , 16 years ago
Milestone: | 5.4 release → 6.0 release |
---|
The page wiki:HidingLayersInOGCWebServices has been created to collect use cases and try to come up with a solution for this ticket and a few related ones.
comment:19 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed. This is addressed by the new machanism to enable/disable OGC requests introduced in RFC-67 (*_enable_Request metadata) combined with the *_include_items and *_exclude_items metadata.
Note:
See TracTickets
for help on using tickets.