Skip to content

WMS GetFeatureInfo: add options to precisely identify points through their symbols#7318

Merged
rouault merged 2 commits intoMapServer:mainfrom
rouault:point_symbol_identification
Sep 23, 2025
Merged

WMS GetFeatureInfo: add options to precisely identify points through their symbols#7318
rouault merged 2 commits intoMapServer:mainfrom
rouault:point_symbol_identification

Conversation

@rouault
Copy link
Copy Markdown
Contributor

@rouault rouault commented Aug 8, 2025 •
edited
Loading

Currently, when MapServer receives a WMS GetFeatureInfo request on a point layer, it queries the
vector data source on a square centered on the value of the X and Y parameters of the query
(converted from image pixels to the layer coordinate reference system), with a radius expressed in
the LAYER.TOLERANCE MapFile parameter (or its default values if not specified). This behavior
works fine as long as symbols used to represent the point are of square shape, and with the symbol
being centered on the point. When the symbol is of rectangular shape and/or with a anchor point far
from its center, users may get unexpected results (false positives and false negatives) when clicking
on features on the map.

This PR adds a new IDENTIFY block under LAYER that can be set to

  IDENTIFY
      CLASSAUTO
  END

to use the symbols from the style classes of the incoming WMS GFI request

or

  IDENTIFY
      CLASSGROUP "name_of_class_group"
  END

to use a precise style group when identifying point symbols.

Identification takes into account potential transparency in the symbol.

The existing TOLERANCE and TOLERANCEUNITS are taken into account. Note
that for clarity of the mapfile, it is possible to move them under the IDENTIFY
block.

This also works with mode=query requests:

e.g:

mapserv -conf ../etc/mapserv.conf QUERY_STRING="MAP=point_symbol_identification.map&mode=query&layer=test_classgroup&qlayer=test_classgroup&imgxy=73+62&imgext=1000+2000+1400+2300&imgsize=200+150"

Note: this enhancement is currently restricted to POINT layers.

@rouault rouault force-pushed the point_symbol_identification branch from 0dbfa60 to fe73abe Compare August 8, 2025 17:10
@jratike80
Copy link
Copy Markdown

jratike80 commented Aug 11, 2025 •
edited
Loading

Feels like a good improvement.
Do you check STYLE-MIN/MAXSCALEDENOM and make sure that the symbol shows in the corresponding GetMap result?

@rouault rouault force-pushed the point_symbol_identification branch from fe73abe to 3654302 Compare August 11, 2025 13:20
@rouault
Copy link
Copy Markdown
Contributor Author

rouault commented Aug 11, 2025

Do you check STYLE-MIN/MAXSCALEDENOM

yes, I've added tests for that. That was already checked by the original msQueryByPoint() function

and make sure that the symbol shows in the corresponding GetMap result?

Hard to answer 100% positive to that given identification and rendering are two different code paths. Checking further I saw that the identification code could potentially return non-drawn feature because of expression evaluation, when using a non-template code path. I've improved that.

@rouault
Copy link
Copy Markdown
Contributor Author

rouault commented Sep 2, 2025

@sdlime @geographika Any thought on the proposed mapfile syntax ?

@geographika
Copy link
Copy Markdown
Member

geographika commented Sep 2, 2025

Very nice improvement!

Are there any other settings planned for an IDENTIFICATION block? Otherwise, would a PROCESSING option make more sense to set this for a layer? A whole new block for a single keyword seems a little excessive.

Question on the CLASSGROUP "name_of_class_group" - is there a use-case for using a different CLASSGROUP from the active one (set in the Mapfile or WMS STYLES=myclassgroup)?

@rouault
Copy link
Copy Markdown
Contributor Author

rouault commented Sep 2, 2025

Are there any other settings planned for an IDENTIFICATION block?

not yet, but for example I can imagine we could tweak identification to accept transparent pixels inside the symbol. Having a new block seemed cleaner to me than a processing option

Question on the CLASSGROUP "name_of_class_group" - is there a use-case for using a different CLASSGROUP from the active one

I can imagine someone could create a symbol that is larger than the displayed one for the purpose of easier clicking

@geographika
Copy link
Copy Markdown
Member

geographika commented Sep 5, 2025

As I understand it, OGC Maps API has no equivalent for GetFeatureInfo and requests should be through the OGC API – Features API. If this is the case, then maybe this functionality would be better exposed using METADATA and wms_ keywords?
Possibly worth taking to the dev mailing list for other views?

The disadvantage of a new IDENTIFICATION block would be there no inbuilt MapScript support (although should be fine to add if required). It also would need a writeIdentification function to dump the block back out to a file like the other keywords.

@rouault
Copy link
Copy Markdown
Contributor Author

rouault commented Sep 8, 2025

As I understand it, OGC Maps API has no equivalent for GetFeatureInfo and requests should be through the OGC API – Features API. If this is the case, then maybe this functionality would be better exposed using METADATA and wms_ keywords?

I'm not sure to follow you. This identification is really tied to map rendering and styling. That cannot be cleanly emulated using OGC API Features (or WFS). What would be the advantage of moving under METADATA wms_ keywords ? That isn't really metadata.

Possibly worth taking to the dev mailing list for other views?

will do

It also would need a writeIdentification function to dump the block back out to a file like the other keywords.

ah yes, will do

@geographika
Copy link
Copy Markdown
Member

geographika commented Sep 8, 2025

As I understand it, OGC Maps API has no equivalent for GetFeatureInfo and requests should be through the OGC API – Features API. If this is the case, then maybe this functionality would be better exposed using METADATA and wms_ keywords?

I'm not sure to follow you. This identification is really tied to map rendering and styling. That cannot be cleanly emulated using OGC API Features (or WFS). What would be the advantage of moving under METADATA wms_ keywords ? That isn't really metadata.

As I understand it, the functionality in this PR can only ever be used as part of a WMS GetFeatureInfo request. It can't be used through the MapServer CGI functionality, nor any (as yet not implemented) MapServer OGC Maps API. So could it make sense to have it as a WMS layer config option, handled similar to the other WMS layer specific settings in https://mapserver.org/ogc/wms_server.html#layer-object-metadata

@rouault
Copy link
Copy Markdown
Contributor Author

rouault commented Sep 8, 2025

So could it make sense to have it as a WMS layer config option,

I see your point. Obviously it could. That said maybe some day there will some kind of GetFeatureInfo for OGC API maps. Anyway I'm going to bring that to the mailing list

@rouault rouault force-pushed the point_symbol_identification branch 2 times, most recently from 24520b6 to fb4a478 Compare September 9, 2025 20:49
@rouault
Copy link
Copy Markdown
Contributor Author

rouault commented Sep 9, 2025

PR updated to:

  • rename IDENTIFICATION to IDENTIFY
  • added writeIdentify
  • tested successfully a mode=query request

rouault added a commit to rouault/docs that referenced this pull request Sep 9, 2025
@rouault
Document the new LAYER.IDENTIFY block
09bb1d5 
added per MapServer/MapServer#7318
@rouault rouault mentioned this pull request Sep 9, 2025
Merged
@rouault
Copy link
Copy Markdown
Contributor Author

rouault commented Sep 9, 2025

documentation added in MapServer/MapServer-documentation#1035

@jmckenna jmckenna added this to the 8.6.0 Release milestone Sep 10, 2025
@rouault rouault force-pushed the point_symbol_identification branch from fb4a478 to 3412e66 Compare September 12, 2025 08:44
@rouault
msShapeGetNextClass(): use msScaleInBounds()
d9ef84c
@rouault
WMS GetFeatureInfo: add options to precisely identify points through …
b8f298d 
…their symbols

Currently, when MapServer receives a WMS GetFeatureInfo request on a point layer, it queries the
vector data source on a square centered on the value of the X and Y parameters of the query
(converted from image pixels to the layer coordinate reference system), with a radius expressed in
the LAYER.TOLERANCE MapFile parameter (or its default values if not specified). This behavior
works fine as long as symbols used to represent the point are of square shape, and with the symbol
being centered on the point. When the symbol is of rectangular shape and/or with a anchor point far
from its center, users may get unexpected results (false positives and false negatives) when clicking
on features on the map.

This PR adds a new IDENTIFY block under LAYER that can be set to

```
  IDENTIFY
      CLASSAUTO
  END
```

to use the symbols from the style classes of the incoming WMS GFI request

or

```
  IDENTIFY
      CLASSGROUP "name_of_class_group"
  END
```

to use a precise style group when identifying point symbols.

Identification takes into account potential transparency in the symbol.

The existing TOLERANCE and TOLERANCEUNITS are taken into account. Note
that for clarity of the mapfile, it is possible to move them under the IDENTIFY
block.

This also works with mode=query requests:

e.g:
```
mapserv -conf ../etc/mapserv.conf QUERY_STRING="MAP=point_symbol_identification.map&mode=query&layer=test_classgroup&qlayer=test_classgroup&imgxy=73+62&imgext=1000+2000+1400+2300&imgsize=200+150"
```

Note: this enhancement is currently restricted to POINT layers.
@rouault rouault force-pushed the point_symbol_identification branch from 3412e66 to b8f298d Compare September 23, 2025 09:58
@rouault rouault merged commit 4c675f5 into MapServer:main Sep 23, 2025
16 of 17 checks passed
@geographika geographika mentioned this pull request Oct 17, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@geographika geographika geographika approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

8.6.0 Release

Development

Successfully merging this pull request may close these issues.

4 participants

@rouault @jratike80 @geographika @jmckenna