Opened 20 years ago

Closed 11 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 dmorissette)

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:1 by dmorissette, 20 years ago

Severity: normalenhancement
I think this, or something along those lines would make lots of sense. 
I have filed this in bugzilla so that we can discuss and decide on the
exact way that this should be implemented. 

comment:2 by dmorissette, 19 years ago

Version: 4.04.1
Not in 4.0 ... maybe in 4.1?

comment:3 by dmorissette, 19 years ago

Cc: havard.tveite@… added

comment:4 by dmorissette, 19 years ago

*** Bug 142 has been marked as a duplicate of this bug. ***

comment:5 by dmorissette, 19 years ago

See also bug 142 that proposed a slightly different approach to solve the same 

comment:6 by dmorissette, 19 years ago

Cc: assefa@… added

comment:7 by sdlime, 19 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 

  - 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 dmorissette, 19 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 dmorissette, 19 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 pspencer@…, 19 years ago

Cc: spencer@… 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

comment:11 by doug@…, 19 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:

  ITEMS "field1,field2..."

... where ITEMS can contain fields, or keywords like ALL or NO_GEOMETRY.

I think that they should both default to ALL.

comment:12 by doug@…, 19 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:


or something that uses the items, like DUMP FALSE does now:


comment:13 by dmorissette, 19 years ago

Cc: doug@… 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 dmorissette, 18 years ago

Milestone: FUTURE
Status: newassigned
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 hobu, 16 years ago

Milestone: FUTURE5.0 release

comment:16 by dmorissette, 15 years ago

Description: modified (diff)
Milestone: 5.0 release5.2 release

comment:17 by dmorissette, 14 years ago

Milestone: 5.2 release5.4 release

comment:18 by dmorissette, 14 years ago

Milestone: 5.4 release6.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 dmorissette, 11 years ago

Resolution: fixed
Status: assignedclosed

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.