Decide on supporting interaction

[pnorman]

Allowing interaction allows for new techniques like showing a dot + name for a POI then when you click on it, you get more information on what type of POI something is. This cartographic space is not well explored, and I'm not sure if it should be in scope or not.

Doing this would mean excluding applications where you can't interact with the map from the scope of the project. This could be situations where the map is static, but also situations where there's other interaction going on that interferes with clicking the map (e.g. an overlay where you can click stuff). It also adds significant technical complexity, because the produced map is no longer just a Maplibre GL style, but adds an interaction layer.

Points in favour

• Print and applications with complex data overlayed are already excluded from the scope, which are the biggest use-cases where interaction doesn't work
• It's a new cartographic space that can allow displaying much more complex information than would be otherwise possible. E.g. food POIs could show name, restaurant, vegetarian support, cuisine, and other key facts without interfering with the cartography of other features

Points against

• It restricts proper useage of the style to environments where the interaction is possible. There are applications where you can use a Maplibre style, but any interaction code wouldn't carry over (e.g. QGIS, Fresco, Maputnik)
• It could add significant technical complexity
• It's not obvious how to implement this in a portable way that would still allow others to use the map. Right now the goal is to produce a style JSON that a website could add as a source

Regardless, there's no immediate plans for interaction.

cc @systemed who has some experience here for his thoughts.

[systemed]

Essentially the crux of this is tile size. You can of course stuff as much non-displayed metadata into the tiles as you like, but it will inflate the size. For common key/value combinations the impact will be small, as these will typically be repeated several times within a tile, and the MVT dictionary encoding means that you just store the strings once then the dictionary index for each feature. But where values vary more (e.g. opening hours) then you'd expect a bigger tile size hit.

One option is to (optionally?) include an unique ID with each feature. Then the client can do a server-side lookup for that ID (assuming connectivity) and present the results, without having to encode everything in the tile. I do this for hotel/campsite lookups in cycle.travel's tiles. It does, of course, also impact tile size.

(I also find it useful to include the value of the url/website tag for some features, particularly ferries, so that users can look up opening times and fees direct from the operator.)

I suspect there isn't a one-size-fits-all answer here, but my suggestion would be to optionally allow IDs to be encoded in the tiles; to document a hook in the Lua code which users can customise to add extra attributes; and to leave everything else up to the user.