Excessive abstraction: base vs overlay layers - just have one abstraction: layer

[prushforth]

This issue is for discussion.

I recommend removing the definition of "base layer" and renaming the section entitled "Rendering base layers", because I believe that "base" vs "overlay" is an abstraction that doesn't add value but does add complexity.

I haven't come across too much discussion of base vs overlay (perhaps I've missed it), so maybe it's not too late to avoid this mistake.

In Leaflet (and other libraries where > 1 layer is permitted), there's the notion of base vs overlay, and the way they are represented in the layer control is via a option group vs checkbox. I believe that the real distinction is that base layers are "on the bottom" of the visual stack.

So instead of adding this base / overlay abstraction, which would have to be reflected in markup and / or WebIDL, I suggest simply allowing authors to control what is base vs overlay by relative position of the node that represents the layer. This is what I've specified (or avoided specifying, more like) in the current proposal for <layer>, FWIW.

[cmhodgson]

It is more than just being the bottom of the rendering stack. The select one vs. select many distinction is important, because you can only have at most one base layer being displayed, and you likely always want to have exactly one base layer being displayed. You need a way to communicate this to the browser so that it can show the appropriate UI - assuming there is a browser-provided UI for layer management.

I suppose a different approach might be to implement some kind of "layer restrictions" which would allow you to define layers that either must be or must not be displayed at the same time... this would be way more complicated but much more flexible.

As an example I have a Leaflet-based web map that I work with daily that allows me to switch between Google, Bing, ESRI, and MapBox versions of street and aerial imagery as the basemap, and also has a dozen overlay layers. Being able to switch the base map layer with one click is really a usability requirement for such a map. There are also overlay layers which I would like to be able to turn on and off together with one click; I'm not sure if layer groups have been discussed before but they are essentially mutually inclusive compared to base map layers being mutually exclusive.

Furthermore, the idea of layer groups, which one would assume would be managed using the DOM hierarchy, might conflict with the idea of using the relative position of layers in the DOM to define the rendiering order, for example if you want to allow layers from the same group to be at different levels in the rendering stack. In general I think for interoperability with other web components, the layer rendering level is best managed using z-index. The relative order might provide an initial, default z-index? If you force the entire composed map into single z-index on the page, as would be the case with a video or image, you would lose the ability to do some fun things within the map... pop-ups or animations within the layer stack?

[dmorissette]

I agree with @cmhodgson that the base map layer is more than just the one at the bottom. This idea of having an easy way to toggle between base map layers and having only one active at a time is very common and very important (street map vs imagery, day vs night, or switch from one provider to another).

He also brings up good points about overlay layer grouping, but that should probably get its own issue if one does not exist already.

[prushforth]

@cmhodgson

The select one vs. select many distinction is important, because you can only have at most one base layer being displayed, and you likely always want to have exactly one base layer being displayed. You need a way to communicate this to the browser so that it can show the appropriate UI

I'm not saying that this UI isn't useful - sometimes. But it's an abstraction that I don't quite see how it fits neatly into a markup design, though. In the <layer> proposal, we've got a checked boolean attribute, which can be used to initialize whether the layer is visible on the map or not. Using that 'primitive', I think you could write a simple GUI in HTML elements that could manage the logic of basemaps and overlays, in much the same way that Leaflet currently does. That's called progressive enhancement, and is highly desirable, in my view.

It remains to be specified how you can write your own UI for the map viewer, but that's what we're here for, right?

Regarding layer groups, I think any layer should be able to be a layer group, sort of. Although I haven't provided on/off controls for it, if you look at the markup for this layer, you can see it's composed of two <link rel=tile> elements, which could have checkbox controls provided for each in the layer control, I think (but don't yet).

[prushforth]

@dmorissette Regarding the ability to toggle between imagery and street map, for instance, in MapML, we have implemented named styles, where the document can link to an alternate style of itself. This is presented to the user as a radio group in the current polyfill. The only example I can link to for this is pretty lame, but it's implemented in GeoServer. http://geogratis.gc.ca/api/beta/mapml/static/cubewerx_cgdi_proxy_wmts.html

The upper right map of coastlines has a style section of the layer control entry for the layer, and the style options are labelled 'Cubewerx' or 'Red style'. This was developed to support different styles for the same layer, such as you have in WMS etc, and in Google Maps with street vs imagery.

I agree we do need another issue to discuss layer groups!

[cmhodgson]

@prushforth Imagery and street map are not different styles of the same layer, by any rational definition. Even if we ignore the terminology, this is not really a solution, because it requires the provider of layer to define the alternative layer, whereas we want this control to be in the definition of the map itself. Google isn't going to point at Bing as an alternate style.

If you like the form controls style of input, why can't we just add some attributes to the layers like type="base" or displaygroup="base" and displaygrouptype="exclusive"? You would need some attributes like these to make any kind of UI that supported base layers vs overlays, why would we not define these?

[cmhodgson]

You could also think about it like <thead> and <tbody>, with separate and sections in the layer list?

[prushforth]

@cmhodgson

Imagery and street map are not different styles of the same layer, by any rational definition. Even if we ignore the terminology, this is not really a solution, because it requires the provider of layer to define the alternative layer, whereas we want this control to be in the definition of the map itself.

The alternate styles mechanism is not really part of this issue; I mention it because it was raised. However I think what is an alternate style is really up to the map author: they are responsible to put the link in their map document. Google Maps does seem to treat satellite and map as alternate map styles, and while their custom control for switching isn't an option group, it amounts to the same thing.

If you like the form controls style of input

I think the control appearance should be up to the UA.

why can't we just add some attributes to the layers like type="base" or displaygroup="base" and displaygrouptype="exclusive"? You would need some attributes like these to make any kind of UI that supported base layers vs overlays, why would we not define these?

I go back to progressive enhancement. We need to decide what is a primitive, and what could be composed from the primitives. I think <layer checked> is the primitive and you could build <layer data-type="base | overlay"> could be built up from that by the HTML or library author. YMMV. I will add an issue to MapML to see if there's interest in the future for specifying and polyfilling this.

[cmhodgson]

@prushforth Sorry, by "form controls style" I mean, treat the base layers as an option group /radio button, from the markup side. Display (of a default layer control) is of course up to the UA.

I think the most basic concept of a layer should still include the notion of a base layer. If you have a map with more than one layer, at least one of them is a base layer. If you don't have more than one layer, you don't need the layer concept at all. To me it's like saying, you have check boxes, so you don't need radio buttons, that can be a future enhancement, that you can polyfill for now. Yes it's true, but is that really where have to draw the line? If the idea of a base layer isn't part of the core/primitives, then the default/system layer control would not support it, and so everyone who needs it would have to write their own. This is already a cowpath - every map library that I'm familiar with separates base layers from overlays in some way.

[prushforth]

If the idea of a base layer isn't part of the core/primitives, then the default/system layer control would not support it, and so everyone who needs it would have to write their own. This is already a cowpath - every map library that I'm familiar with separates base layers from overlays in some way.

That is a very good argument, and normally one I would be more receptive to, because in this project in general, what we're doing is saying "Look at all these mapping libraries - they're a cow path!". So +1 on the idea that base/overlay are indeed a cow path.

OTOH base/overlay is an abstraction that forces the implementer into other internal abstractions, I believe, to manage the layering. Instead of just having layers stacked in document order, possibly managed by CSS z-index, we have to maintain containers in which the base/overlays are stacked. In Leaflet this is called a "pane", and it's an internal data structure, as far as I can recall, with little external impact. But it makes managing layer order more complex. I'm pretty sure the browser would be forced into maintaining a similar abstraction. I could be wrong.

Which is I think pretty much where they'll draw the line. This is exactly why it would be ideal to have a browser developer or two listening in on the discussion and adjudicating. We'll have to rely on our Web standards developer colleagues, @AmeliaBR and @Malvoz to help us make this decision, one that our browser developer colleagues will hopefully agree with.

It certainly won't be the last similar decision point, and we're going to have to internalize the point of view of browser developers in order to succeed.

[Malvoz]

https://github.com/Maps4HTML/HTML-Map-Element-UseCases-Requirements/issues/179#issuecomment-535220455:

the idea of layer groups, which one would assume would be managed using the DOM hierarchy, might conflict with the idea of using the relative position of layers in the DOM to define the rendiering order, for example if you want to allow layers from the same group to be at different levels in the rendering stack.

https://github.com/Maps4HTML/HTML-Map-Element-UseCases-Requirements/issues/179#issuecomment-535558636

Imagery and street map are not different styles of the same layer, by any rational definition. Even if we ignore the terminology, this is not really a solution, because it requires the provider of layer to define the alternative layer, whereas we want this control to be in the definition of the map itself. Google isn't going to point at Bing as an alternate style.

why can't we just add some attributes to the layers like type="base" or displaygroup="base" and displaygrouptype="exclusive"? You would need some attributes like these to make any kind of UI that supported base layers vs overlays, why would we not define these?

The notion of grouping resources by predefined types is already a thing in HTML; the <track> media element has a kind attribute. (I also mentioned this in https://github.com/Maps4HTML/MapML/issues/130#issuecomment-720621451.)

In MapML it could allow grouping of layers (to some extent), like so:

<map ...>
  <layer kind="base" ...></layer>
  <layer kind="overlay" ...></layer>
  ...
  <layer kind="base" ...></layer>
</map>

I believe the limitation would then be to (optionally) assign "overlay" layers to "base" layers, such that they're only displayed when the appropriate base layer is displayed. Maybe layers could have something like a group attribute, it'd work similarly to the name attribute for defining radio groups.

Presumably, overlay layers always render on top of the base layers, and overlay layers in DOM order (further managed by e.g. CSS z-index).

As such, managing the DOM order of layers would allow arranging the order in the exposed UI, z-index can then be used to modify the order in the rendering stack:

I'm of course speculating, maybe I'm missing something crucial, maybe this doesn't give granular enough control? After all, I had never worked with maps before joining the Maps4HTML CG. I'd appreciate your thoughts. 👍🏼