Use Case: Control which layers are currently visible & which can be hidden by the user

[NickFitz]

This issue is for discussion of the use case “Control which layers are currently visible & which can be hidden by the user”, its examples & list of required capabilities.

[prushforth]

This needs to be explained a bit more.

[NickFitz]

This needs to be rethought, as the concept of a "layer" has various meanings within the different reference APIs, and even within the same API. For example, a layer in the sense of a representation of an area using tiles, or a layer in the sense of a collection of markers to be displayed above such a layer.

My original notion was related to the National Library of Scotland's site for viewing old Ordnance Survey maps overlaid on a modern map, so that one can for example select OS maps from the late 19th century, or the mid-20th century, overlaid on an OSM map.

This also relates to the idea of choosing the style of a map in Issue #81 as that idea, originally thought of in the context of, for example, a user with impaired vision using a high-contrast map, really amounts to selecting a mapping layer.

[prushforth]

National Library of Scotland's site for viewing old Ordnance Survey maps overlaid on a modern map

I used this tool to great effect when I went on holiday to Scotland to visit the ancestral homeland. The farm that my Dad grew up on outside Edinburgh is now cut by a super highway and has been turned into a Rotweiler breeding kennel, but it was findable on the historical maps. What a great tool!

the concept of a "layer" has various meanings within the different reference APIs, and even within the same API. For example, a layer in the sense of a representation of an area using tiles, or a layer in the sense of a collection of markers to be displayed above such a layer.

Anyway, yes the concept of layer has to be quite a flexible abstraction, which is pretty much why I created MapML so as to fit a bunch of stuff into it without requiring APIs other than the uniform interface.

[cmhodgson]

In my quick perusal of the "Use Cases and Requirements for Standardizing Web Maps" doc, it seems to be lacking in the definition department. To me, there should be a section near the beginning that defines terms like Map, layer, feature, image, tile, etc. so that they are clear when we use them. To me, a Map layer is a logical collection of map features or map images/tiles which are grouped together for the purposes of combined control over styling and/or display. Typically there is one "background" layer, and zero to many overlay layers. Overlay layers are either images/tiles with transparent areas to allow the background to show through, or vector feature layers that are rendered on the client.

With vector layers, the styling is separate from the data, so switching styles or color themes (eg. dark vs light) is clearly separate from switching data layers. However, with raster based layers, some systems would allow you to change the style of a layer (WMS uses &style=) but only if so configured; more commonly, the different styles are implemented as different layers. For example, changing from dark to light street maps is done using the same parameter as changing from street maps to satellite view in every mapping system I'm familiar with, Google, Bing, MapBox, etc. So I think we need to talk separately about "styleable layers" and "non-styleable layers" in some cases.

Perhaps we have some definitions in another doc? I think these terms need to be clearly defined, we can't write a meaningful spec without well defined semantics.

[AmeliaBR]

@cmhodgson Yes, I definitely agree that we need to define our terms. I've got an issue (#31) for that, but need to follow up with that.

[AmeliaBR]

For client-side styling of vector layers, let's keep that separate, and focus on swapping tile sources.

For this use case, there are a few ways to look at it:

• On the widget/declarative level, can the author specify a set of alternatives for a map layer, and let the user swap between them? E.g., to swap between street map and satellite imagery as the base tile layer.

• On an API level, I'm not sure whether this needs to be a separate use case. If the website author is creating a custom widget to select the options, this really becomes comes down to being able to dynamically set a layer.

• However, if there is a built-in style switcher, then at the API level the script might need to respond to a switch, e.g., to change the styles of the vector layers.

[AmeliaBR]

We now have a few related use cases:

• 81 covers swappable alternative layers that the user can choose from

• a new issue, #115, for the use case from the perspective of the end user
• This issue is now tied to the app-developer use case, "Control which layers are currently visible & which can be hidden by the user"