Using LAYER CLASS filters for MVT tiles rendering

[SodOnBass]

Hello,

Defining groups in CLASSES LAYER description allows to configure how mapserver renders image based output format (png, ...) through the STYLES WMS parameters. Considering the following CLASS groups definition for a vector data layer called MyLayer :

CLASS
    NAME 'MyName'
    GROUP 'MyStyle'
    EXPRESSION ('[name]'='foo1')
    STYLE
      COLOR 0 0 0
    END
END
CLASS
    NAME 'MyOtherName'
    GROUP 'MyOtherStyle'
    EXPRESSION ('[name]'='foo2')
    STYLE
      COLOR 255 0 0
    END
END

mapserver will render only the foo1 named feature replying to the following WMS request

http://myhost/mapserv?VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&STYLES=MyStyle&BBOX=-626172.135712,5635549.221409,-0.000000,6261721.357122&WIDTH=256&HEIGHT=256&FORMAT=image/png&SRS=EPSG:3857&LAYERS=MyLayer

This behavior is not consistent when changing the request output format for MVT since all features will be blindly included:

http://myhost/mapserv?VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&STYLES=MyStyle&BBOX=-626172.135712,5635549.221409,-0.000000,6261721.357122&WIDTH=256&HEIGHT=256&FORMAT=application/vnd.mapbox-vector-tile&SRS=EPSG:3857&LAYERS=MyLayer

Obviously, there is no style per say since the drawing will happen on the client side. Nevertheless, I am wondering if it would have make sense to filter the features in the rendered MVT. I believe it is Geoserver behavior. Same question could go for other filters that defined through other styling styling inputs (SLD, Vendor specific OGC filters, ...). I guess it should be achievable to define a FILTER in the LAYER definition and use string substitution, but CLASS filtering capabilities seems an interesting shortcut.

I understand this is a controversial one, so it might have already been discussed and discarded. Looking at the msMVTWriteTile code, it calls, arguably on purpose, msShapeGetClass() without any consideration for CLASSGROUP.

shape.classindex = msShapeGetClass(layer, map, &shape, NULL, -1);

Using layer classgroup and numclasses instead of NULL and -1 produces my expected behavior, but again, not sure it is the generally expected one.

Operating system

Oracle Linux 8.9

MapServer version and installation method

Mapserver 8.0.1

[geographika]

Interesting. As the tiles are requested through the WMS "facade" it makes sense to me to allow a STYLES parameter to be used to select a GROUP in a layer. Does passing a FILTER= via the querystring have an effect?

If you have the code ready it would be good to open a pull request to see the changes you made, and see if all tests pass. Then it could be brought up to discuss on the https://lists.osgeo.org/mailman/listinfo/mapserver-dev mailing list.

[SodOnBass]

FILTER= is ignored as well. There is a if/else statement in msWMSGetMap() that discard any layer->resultcache processing for MVT tiles. I updated my modifications so that it works for FILTER=, and probably SLD, as well. I will provide the pull request. Clearly not convinced I did this the proper way, but should be enough for a discussion.

[geographika]

@SodOnBass for some background MVT support was added through https://mapserver.org/development/rfc/ms-rfc-119.html and the pull request is at #5376.
An alternative may be to implement the new OGC Tiles API - https://ogcapi.ogc.org/tiles/overview.html

[SodOnBass]

Thank you for your reply. I understand the controversy is in the RFC overview statement.

This allows for rich application development where geospatial data can be filtered and symbolized on the client without the need for extra server interactions.

But I think having some flexibility on server side in the way MapServer provides the tiles without reorganizing the source data is not necessary a bad thing.

The pull request is there: #7011

I hope I did not mess out while submitting. Sorry if it is the case.

[jratike80]

If I understand right, the change might mean that a user who has downloaded tiles with &STYLE=MyStyle could not render them on the client side with the &STYLE=MyOtherStyle because some data could have been filtered out. That could confuse users.

What if filtering would require user to ask for it for example by using a keyword &MVT_FILTERED=YES?

[geographika]

If I understand right, the change might mean that a user who has downloaded tiles with &STYLE=MyStyle could not render them on the client side with the &STYLE=MyOtherStyle because some data could have been filtered out. That could confuse users.

What if filtering would require user to ask for it for example by using a keyword &MVT_FILTERED=YES?

If a user has explicitly added &STYLE=MyStyle then only returning data which matches this style matches the logic used with a WMS request, so it could be argued it is more confusing to return all data?

I've only used MapServer and MVT through WMS with OpenLayers so not sure how other clients work with this approach. See https://github.com/geographika/mapserver-mvt for a demo.

The WMS interface to MVT is a bit of a hack - longer term it would be great to implement the OGC Tiles API.