From sdlime at gmail.com  Thu Oct  1 15:09:41 2026
From: sdlime at gmail.com (Steve Lime)
Date: Thu, 1 Oct 2026 17:09:41 -0500
Subject: [MapServer-dev] Adding a STYLES parameter to GetStyles requests
In-Reply-To: <c085aeba-f9c5-496d-96a0-ca45fddecb72@app.fastmail.com>
References: <ae2b58cb-4dcc-4125-a276-97a797d3cd3f@app.fastmail.com>
 <CAMrKZ99cALwkd5zwseEk4X-ikaVLWU-RwwLX1_2Oz83+6=mR3g@mail.gmail.com>
 <c085aeba-f9c5-496d-96a0-ca45fddecb72@app.fastmail.com>
Message-ID: <CAMrKZ98Onw_-GPG7TUE_1k5BWQ_nq42Y4XctCKTn6BOwP-52ng@mail.gmail.com>

+1, makes total sense. Go for it.


On Wed, Sep 30, 2026 at 1:32?PM Seth G <sethg at geographika.co.uk> wrote:

> Hi Steve,
>
> It would work in the exact same way as WMS GetMap and GetLegendGrap:hic
> e.g. use &STYLES=other to select all classes in the GROUP "other"
>
>
> mapserver-workshop-k8hvw.ondigitalocean.app/?map=/etc/mapserver/polygons.map&REQUEST=GetStyles&SERVICE=WMS&VERSION=1.3.0&LAYERS=buildings&STYLES=other
>
> Similar to:
>
>
> https://mapserver-workshop-k8hvw.ondigitalocean.app/?map=/etc/mapserver/polygons.map&REQUEST=GetLegendGraphic&SERVICE=WMS&VERSION=1.3.0&FORMAT=png&SLD_VERSION=1.1.0&LAYER=buildings&STYLES=other
>
> Seth
>
> --
> web:https://geographika.net & https://mapserverstudio.net
> mastodon: @geographika at mastodon.social
>
> On Wed, Sep 30, 2026, at 6:58 PM, Steve Lime wrote:
>
> Would style ids be just index values (e.g. 0 for the first style
> associated) or names? I have no issues conceptually with the addition -
> good idea!
>
> On Mon, Sep 28, 2026 at 12:06?PM Seth G via MapServer-dev <
> mapserver-dev at lists.osgeo.org> wrote:
>
> Hi all,
>
> I've been working on the MapServer SLD functionality recently, and making
> use of GetStyles WMS requests to return SLD for client-side styling in
> OpenLayers (thanks to the newly graduated OSGeo project GeoStyler [1]).
>
> Currently all styles for a layer are returned for a GetStyles request. For
> example:
>
>
> https://mapserver-workshop-k8hvw.ondigitalocean.app/?map=/etc/mapserver/polygons.map&REQUEST=GetStyles&SERVICE=WMS&VERSION=1.3.0&LAYERS=buildings
>
> Has 2 different styles (defined by the GROUP of the CLASSes in a LAYER in
> the Mapfile):
>
> <UserStyle>
> <se:Name>university</se:Name>
> ...
> <UserStyle>
> <se:Name>other</se:Name>
> ...
>
> It would be nice to be able to pick just one of these by supplying a
> STYLES= parameter, in the same way GetMap, GetFeatureInfo and
> GetLegendGraphic work. Reusing it for GetStyles keeps the same meaning and
> the same comma-separated, one style per layer format.
>
> In terms of other software, GeoServer seems to support GetStyles [2], but
> I see no mention of it in their docs [3].
> QGIS also supports GetStyles [4], but has no STYLES= parameter.
>
> GetStyles is hard to track down in terms of where it fits with WMS version
> numbers, WMS 1.1.1 has no GetStyles, but the SLD 1.0.0 specification
> extends WMS 1.1.x with it. WMS 1.3.0 uses SLD 1.1.0, which seems to have
> dropped GetStyles completely. However MapServer still supports it for all
> WMS versions. It is documented in
> https://docs.ogc.org/is/02-070/02-070/pdf in section 13.1
>
> Adding a "vendor" parameter of STYLES would be a handy addition to
> MapServer, and may also help with implementing OGC API Styles which has a
> URL per style (/collections/{id}/styles/{styleId}. If the parameter is
> missing or empty all styles would be returned as in the current case.
>
> Anyone with thoughts/comments on the above?
>
> Seth
>
>
>
> [1] https://www.osgeo.org/projects/geostyler/
> [2]
> https://discourse.osgeo.org/t/geoserver-devel-does-getstyles-work-in-geoserver-2-12/104946
> [3] https://docs.geoserver.org/main/
> [4]
> https://docs.qgis.org/3.44/en/docs/server_manual/services/wms.html#wms-getstyle
> _______________________________________________
> MapServer-dev mailing list
> MapServer-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20261001/72beee1d/attachment.htm>