WMS GetFeatureInfo should honour STYLES parameter #4660

tomkralidis · 2013-05-22T00:44:46Z

As discussed with @Schpidi in IRC:

Using 6.2.1 with the following patch:

https://github.com/mapserver/mapserver/commit/937dcb6857501835b5489fa4bea321105412a20b.patch

...I have 3 CLASSGROUP directives defined, which are advertised as WMS Layer STYLES parameters in WMS. Their underlying CLASS definitions are mapped accordingly in the mapfile. The CLASS objects contain EXPRESSION directives as a means to filter (I do not / cannot use LAYER level FILTERs, as the layer in WFS mode should be returning everything).

When performing a GetMap request against each of the 3 CLASSGROUPs via the WMS GetMap STYLES parameter, the expected results are returned:

# STYLES=group1, returns map of one point (id=1, title='foo')
http://host/mapserv?map=/path/to/foo.map&service=WMS&version=1.1.1&request=GetMap&layers=foo&srs=EPSG:4326&width=500&height=300&format=image/png&bbox=-80,42,-74,46&styles=group1

# STYLES=group2, returns map of one point (id=2, title='bar')
http://host/mapserv?map=/path/to/foo.map&service=WMS&version=1.1.1&request=GetMap&layers=foo&srs=EPSG:4326&width=500&height=300&format=image/png&bbox=-80,42,-74,46&styles=group2

# STYLES=group3, returns map of all (2) points
http://host/mapserv?map=/path/to/foo.map&service=WMS&version=1.1.1&request=GetMap&layers=foo&srs=EPSG:4326&width=500&height=300&format=image/png&bbox=-80,42,-74,46&styles=group3

When performing a GetFeatureInfo request against each of the 3 CLASSGROUPs via the WMS GetFeatureInfo STYLES parameter, the expected results are not returned:

# STYLES=group1, should return GML of one point (id=1, title='foo'), but instead returns everything
http://host/mapserv?map=/path/to/foo.map&service=WMS&version=1.1.1&request=GetFeatureInfo&layers=foo&srs=EPSG:4326&width=500&height=300&format=image/png&bbox=-80,42,-74,46&query_layers=foo&info_format=GML&radius=bbox&styles=group1

# STYLES=group2, should return GML of one point (id=2, title='bar'), but instead returns everything
http://host/mapserv?map=/path/to/foo.map&service=WMS&version=1.1.1&request=GetFeatureInfo&layers=foo&srs=EPSG:4326&width=500&height=300&format=image/png&bbox=-80,42,-74,46&query_layers=foo&info_format=GML&radius=bbox&styles=group2

# STYLES=group3, returns GML of all (2) points (only because the `CLASS` object does not apply any `EXPRESSION` directives)
http://host/mapserv?map=/path/to/foo.map&service=WMS&version=1.1.1&request=GetFeatureInfo&layers=foo&srs=EPSG:4326&width=500&height=300&format=image/png&bbox=-80,42,-74,46&query_layers=foo&info_format=GML&radius=bbox&styles=group3

In other words, it looks like CLASS objects are ignored for GetFeatureInfo requests. They should be treated exactly how we handle them in GetMap.

Test data (save to foo.csv):

id,title,x,y
1,foo,-75,45
2,bar,-79,43

Test mapfile (save to foo.map and point to foo.csv as absolute path in OGR VRT def):


MAP
 NAME test

 PROJECTION
  "init=epsg:4326"
 END

 SYMBOL
  NAME "circle"
  TYPE ellipse
  FILLED true
  POINTS
    1 1
  END
 END

 WEB
  METADATA
   "ows_enable_request" "*"
   "ows_title" "foo server"
  END
 END

 LAYER
  NAME "foo"
  TEMPLATE "ttt.html"
  CONNECTIONTYPE OGR
  CONNECTION '<OGRVRTDataSource>
    <OGRVRTLayer name="foo">
     <SrcDataSource>/path/to/foo.csv</SrcDataSource>
     <GeometryType>wkbPoint</GeometryType>
     <LayerSRS>WGS84</LayerSRS>
     <GeometryField encoding="PointFromColumns" x="x" y="y"/>
    </OGRVRTLayer>
   </OGRVRTDataSource>'
  DATA foo
  METADATA
    "ows_title" "foo"
    "gml_include_items" "all"
  END
  STATUS ON
  DUMP TRUE
  TYPE POINT
  CLASSGROUP "group1"
  CLASS
   NAME "foo"
   GROUP "group1"
   EXPRESSION ('[TITLE]' = 'foo')
   STYLE
    SYMBOL "circle"
    SIZE 10
    COLOR 255 0 0
   END
  END
  CLASSGROUP "group2"
  CLASS
   NAME "foo"
   GROUP "group2"
   EXPRESSION ('[TITLE]' = 'bar')
   STYLE
    SYMBOL "circle"
    SIZE 10
    COLOR 255 0 0
   END
  END
  CLASSGROUP "group3"
  CLASS
   NAME "foo"
   GROUP "group3"
   STYLE
    SYMBOL "circle"
    SIZE 10
    COLOR 255 0 0
   END
  END
 END
END

The text was updated successfully, but these errors were encountered:

jratike80 · 2013-06-03T22:31:19Z

STYLES does not seem to be listed as GetFeatureInfo request parameter in the WMS standard and therefore this feature would work as supposed only with a non-standard WMS client. As a WMS server admin I would use this feature only if I could control what WMS client is allowed to use my service. It might be usable with some of our own made web applications.

tomkralidis · 2013-06-03T23:11:58Z

@jratike80 STYLES is a supported GetFeatureInfo parameter; see:

WMS 1.1.1, 7.3.3.4
WMS 1.3.0, 7.4.3.3

jratike80 · 2013-06-04T05:11:29Z

Oh sorry, I was totally wrong. I was just reading the Table 9 in WMS 1.3.0 and did not read that actually the map request part says it is even compulsory to copy the whole GetMap despite VERSION and REQUEST. I have never understood it that strictly and I believe we have some applications which are sending GetFeatureInfos for Mapserver without "styles" and "layers" so we are ourselves doing it in a non-standard way.

jratike80 · 2013-06-04T07:39:19Z

I checked how we use GetFeatureInfo and we do copy the STYLES parameter into the request. We do not copy SLD_BODY or SLD parameters but I believe that according to the standard we should and Mapserver should also honour the filters used in SLD or SLD_BODY.

We have intentionally read the following part of the standard so that the layer in QUERY_LAYERS does not need to be found from LAYERS if it is still available from the server and listed in GetCapabilities. It is perhaps not in the spirit of the standard but not explicitly denied either.

"The mandatory QUERY_LAYERS parameter states the map layer(s) from which feature information is desired to
be retrieved. Its value is a comma-separated list of one or more map layers. This parameter shall contain at least
one layer name, but may contain fewer layers than the original GetMap request.
If any layer in the QUERY_LAYERS parameter is not defined in the service metadata of the WMS, the server
shall issue a service exception (code = LayerNotDefined"

How does your patch work with SLD and SDL_BODY and a request like

&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&INFO_FORMAT=text/html&LAYERS=layer_1&FORMAT=image/jpeg&HEIGHT=1019&WIDTH=1400&BBOX=3372226.1053542476,6966830.1615698105,3372720.666976955,6967190.131779482&STYLES=&SRS=EPSG:2393&QUERY_LAYERS=layer_2&Y=628&X=531&FEATURE_COUNT=100?

tomkralidis · 2013-06-04T14:06:35Z

We copy STYLES but do we "apply" them? Not sure what you mean with SLD/SLD_BODY. The use case here is STYLES?

jratike80 · 2013-06-04T14:40:26Z

Here is a live example, I hope that the long URL tolerates copy/paste. Meaning is to show that with SLD_BODY user can do from the client side the same thing that is done mostly on the server side with predefined STYLES in the original example. The filter inside SLD_BODY is selecting only "highway=trunk" ways from the OpenSteetMap data. The layer name in the WMS service is "roadsfar_01". The user who is looking at the map from my server and sends a GetFeatureInfo request probably wants to get more information about the trunk highways and not from the other ways which do exist on the roadsfar_01 layer but which are hidden with SLD_BODY.

I feel that SDL_BODY and SLD are not at all popular and therefore it may be waste of time to think too much about them. Here comes the example anyway.

tomkralidis · 2013-06-04T14:53:22Z

Thanks for the info. I think the point here is applying CLASS/STYLE mechanisms as part of predefined STYLES, without the need for SLD/SLD_BODY (which, IMHO, introduces a barrier to the client who is expecting default behaviour).

mapserver-bot · 2016-02-23T16:08:01Z

This is an automated comment

This issue has been closed due to lack of activity. This doesn't mean the issue is invalid, it simply got no attention within the last year. Please reopen with missing/relevant information if still valid.

Typically, issues fall in this state for one of the following reasons:

Hard, impossible or not enough information to reproduce
Missing test case
Lack of a champion with interest and/or funding to address the issue

mapserver-bot added the No Recent Activity label Feb 23, 2016

mapserver-bot closed this as completed Feb 23, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WMS GetFeatureInfo should honour STYLES parameter #4660

WMS GetFeatureInfo should honour STYLES parameter #4660

tomkralidis commented May 22, 2013

jratike80 commented Jun 3, 2013

tomkralidis commented Jun 3, 2013

jratike80 commented Jun 4, 2013

jratike80 commented Jun 4, 2013

tomkralidis commented Jun 4, 2013

jratike80 commented Jun 4, 2013

tomkralidis commented Jun 4, 2013

mapserver-bot commented Feb 23, 2016

WMS GetFeatureInfo should honour STYLES parameter #4660

WMS GetFeatureInfo should honour STYLES parameter #4660

Comments

tomkralidis commented May 22, 2013

jratike80 commented Jun 3, 2013

tomkralidis commented Jun 3, 2013

jratike80 commented Jun 4, 2013

jratike80 commented Jun 4, 2013

tomkralidis commented Jun 4, 2013

jratike80 commented Jun 4, 2013

tomkralidis commented Jun 4, 2013

mapserver-bot commented Feb 23, 2016

This is an automated comment