JSON Styling as an alternative to JS/TS Rules

[bdon]

[nf-s]

Hi @bdon

Just wondering, how close/compatible to the mapbox style-spec do you want to be?

Would it be worth using the get lookup for feature properties (eg ["get", someFeatureProp]) - https://docs.mapbox.com/mapbox-gl-js/style-spec/expressions/#get
and then supporting some of the base properties (eg ["zoom"], ["geometry-type"], etc...)

I'd be happy to write a PR to add get lookup support 😄

[bdon]

If you'd like to expand the completeness of JSON style, that would be great! My thoughts on it:

1. As far as I know, there is no formal style specification: There was an attempt to separate this out in the past https://github.com/mapbox/mapbox-gl-style-spec but it was probably difficult to maintain and merged into the mapbox-gl repo. That mean that different renderers like mapbox-gl 2.0 might have diverging implementations.
2. I would use https://maplibre.org/maplibre-gl-js-docs/style-spec/layers/ as a first reference, it should be a snapshot of what styling features were available in 1.13. Secondly, OpenLayers has an implementation called ol-mapbox-style https://github.com/openlayers/ol-mapbox-style that we should be able to borrow from.
3. There are some styling features that won't be possible at all because of different underlying technology, such as fonts and the fill-extrusion layer type.

I think better support for expressions and lookups such as what you describe are fair game. The end goal should be reasonable support for JSON styles as a prototyping, compatibility or fallback use case; using underlying Symbolizers will always be the preferred design workflow. One overarching concern is that the s-expressions can be arbitrarily complex, so I would:

• be sure to add unit tests for JSON style, these are all here: https://github.com/protomaps/protomaps.js/blob/master/test/json_style.test.ts
• be cognizant of code size. One of the goals of protomaps.js is small bundle size overall, and since the style transforming code is all dynamic it can't be partially tree-shaken once the json_style module is imported. If full expression support ends up being too heavy, maybe we should break it out into a separate protomaps-json-style library.

[bdon]

@nf-s I've converted this issue to a Discussion - the first one! Hopefully others can chip in on what the optimal level of JSON Styling support is. Also, I've bumped the major version to 1.0.0 with backwards-incompatible changes, and started a CHANGELOG.md file. If you're using the json_style features any feedback would be helpful.