Serving layer styling

[baffioso]

This might be out of scope of pg_tileserv functionality, but still want to share my thoughts about providing layer styling of vector tiles.

We want to store our mapbox layer styles (and legend configuration etc.) in PostgreSQL and serve them alongside vector tiles metadata. At the moment we use PostgreSQL COMMENT to store layer styling and other metadata as JSON, which are getting parsed in the web app, since it comes out as a string in the description from the /index.json endpoint. This enables to make a single HTTP call to fetch both vector tiles url, layer styling and configuration for building a legend etc.

Would be convenient if you could add some kind of custom metadata/configuration as JSON which got served through the API. Below is an example where i added an extra metadata property to the /index.json endpoint.

{
    "my_schema.my_table": {
        "type": "table",
        "id": "my_schema.my_table",
        "name": "my_table",
        "schma": "my_schema",
        "description": "This is my layer",
        "metadata": {
            "styling": [
                {...styling1},
                {...styling2}
            ],
            "layerAlias": "My Alias",
            "legend": [...] 
        },
        "detailurl": "https://tileserv.kkpuma.dk/public.tb.json"
    }
}

This might also apply for pg_featureserv.

(Fully understand if it is up to the individual app developers to create a style/metadata service or hardcode styling into the web app)

[pramsey]

This is something @dr-jts and I have discussed. Because it's a shared feature that probably both tileserv and featureserv would like to have, we should coordinate on it. My initial take is that a table in the 'postgisftw' schema could be used to hold styling information, and then the servs could just have an 'if the table is there and matches expected structure, pull styling info from it' test.

The one thing that stands out for me in that is: format!

Like, there's a million styling formats. You might be planning to push mapbox json styles. But there might also be a desire for openlayer styles. Or SLD. Or...

The issue if whether and if to keep the style table directly tied to things like relclass oid numbers is also outstanding. Using relclass oid means that the link between style and table transcends table renames. But it also makes the style table harder for humans to read, and maybe breaks the contract of "easy to use". It's not hard to grok that "style must have reference that matches table/view/function name" is a hard and fast rule.

[baffioso]

Yep, might be hard to deal with all styling formats. Maybe a start could be to support JSON based styling formats, which aligns with the pg_tileserv API? (sorry for styling-format-discrimination)

An other issue i stumbled into working with Mapbox GL JS (MB), is that it's seldom one MB layer per database table/layer. Often you want represent a tileserv table layer with multiple MB layers on the map (e.g. one MB layer for geometries and one for labels or different layers depending on zoom level). Further, you might want to store other layer dependent data which can be used for building the UI (e.g. legend color and names for categorized styling, layer alias for layer control etc.).

In order to make this dynamic as possible you could give the pg_tileserv admin full control over the JSON object you want to provide in the API.

[pramsey]

In the limit, the presence of a postgis_ftw_style(text table_fun_name) => json function could indicate, "run this function and stick the answer into the style slot?"

[dr-jts]

OGC is working on a spec for a Styles service API, so might be worth looking at that. It seems fairly heavyweight for the functionality it provides, though.

[HardRock4Life]

@pramsey, what are the current thoughts on layer styling?

[HardRock4Life]

@pramsey What should be done to try styling with SLD ?