Layer support in MapML?

[tidoust]

I'm not entirely clear about the split between the HTML <map> Element proposal and MapML, so I thought I'd raise an issue.

My understanding is that MapML is intended to be a standalone format to encode a map. That map could be rendered by some user agent. Now, the <map> element proposal describes a solution to embed maps in HTML, essentially representing maps as a stack of layers. In this model, MapML would typically be the format used to describe a given layer.

What bugs me is that the layering logic seems to be missing from MapML. In other words, MapML seems to be a standalone format to encode a map layer, and an HTML page seems required to render an interactive map with layers that can be switched on and off. Why aren't layers an integral part of MapML? (or are they already?)

[prushforth]

Yes this is a good point, and something to consider.

In a MapML document, there is really no prior constraint on what content you can put, so you could/ can put tiles that overlap into the same document, and the composite result is the map. This is the case, for example in this service. That service is a bit hard to look at the source document unless you request it as Accept: text/mapml and edit the response as xml. If you do that you'll see that there are two <tile> elements for each row/col unique combination in the extent. So that is one way that a MapML document supports layers.

Another way which we developed during Testbed 13 was to include <template> elements for image or tile sources. This service is a bit easier to view the source in a browser (will eventually get deployed to the first url, right now its still in development).

So that's the second way (really just another way of accomplishing the first scenario) where there are multiple overlapping content sources for the same area.

I believe we should be able to combine tiles, images and vectors in a similar way ( in a single document) but haven't done too much experimentation in that direction yet.

Finally, something that we haven't experimented with but which I believe made it into the engineering report was actually allowing the <layer> element in a MapML document, such that it would dereference the @ src attribute. I'm not sure yet if there are any 'gotchas' in that scenario, but it might be useful for, for example, animating layers using CSS. We built a little application that could have used such animation had it existed, here.

At the end of the day, it's true that any MapML client must have the concept of a map already, whether it be a GIS program or a browser with the <map> client element. The client can then use MapML documents as layers in the map.

[prushforth]

To follow up a bit on this, the conceptual model of MapML is based on the concept of a document. The notion is that the document represents a map. The content layout for a map document follows the painter's model. If the client application has the idea of a "map", then it should be natural to manipulate layers in the user interface.

In a GIS user interface, the "map" is the basis of the user interface, and map "furniture" is supplied to aid in manipulating the layers. Although the primary client of MapML is designed to be the Web browser, there's no reason that I can see that MapML shouldn't be usable by GIS programs as well.

MapML document could also be the target of the URL bar in a browser, in a similar way that an SVG document can. In such a case, the map document is the browsing context. At that point, what is the difference between the browser and a GIS program? The program needs to provide the map infrastructure. Maybe for a browser that would be a synthesized HTML document with a <map> element with a <layer> element referring to the MapML document, similar to how the browser treats a URL for an image. But maybe one day we could have a model in which such a MapML document could load script? I think that has a lot of potential.

A few more thoughts...

The DOM model doesn't seem to prescribe a user interface, just an object-oriented API. As far as I know, in HTML there doesn't seem to exist a way to specify scroll bars, for example, yet scrolling is an inherent user interface paradigm that is essential to representing a standard HTML document. Similarly in MapML, the idea of panning and zooming is almost inherent / driven by content.

Finally, there's the idea of a map/layer API. I think a minimalist API is essential, and should be based on the DOM / events. Leaflet and OpenLayers APIs are instructive, but we need to adapt to what is a sustainable basis for the browsers to provide. I also think the map needs to supply a drawing context in which what gets drawn gets geocoded, and can be serialized by script in a straightforward way, especially as JSON.

[tidoust]

Some follow-up comments to clarify how I approach this (and keep in mind I don't claim any expertise there):

To follow up a bit on this, the conceptual model of MapML is based on the concept of a document. The notion is that the document represents a map. The content layout for a map document follows the painter's model. If the client application has the idea of a "map", then it should be natural to manipulate layers in the user interface.

It should be natural to manipulate layers in the user interface, provided there is a way to identify layers. A MapML document, which represents a map, does not seem to define a way to identify layers that compose the map. The painter's model merely states that things get drawn in order. It does not help with grouping things together into a layer.

Let's imagine a traffic map, composed of two layers: the bottom layer would represent the roads, the upper layer would represent the traffic (green, orange, and red blocks). Users may want to enable/disable the traffic layer. I don't know how to represent these two layers in MapML so that a client tool can offer that functionality. It seems that, to do that, I need to prepare 2 MapML documents, one for each layer, and combine them using <layer> tags in an HTML document. That seems convoluted for a feature that is core to the definition of a map (but maybe layers are not that core to the notion of map).

In a GIS user interface, the "map" is the basis of the user interface, and map "furniture" is supplied to aid in manipulating the layers. Although the primary client of MapML is designed to be the Web browser, there's no reason that I can see that MapML shouldn't be usable by GIS programs as well.

MapML document could also be the target of the URL bar in a browser, in a similar way that an SVG document can. In such a case, the map document is the browsing context. At that point, what is the difference between the browser and a GIS program? The program needs to provide the map infrastructure. Maybe for a browser that would be a synthesized HTML document with a

If browsers support MapML, why imagine that they would wrap the MapML document into an HTML document with a <map> element and a <layer> element? They would have to create a browsing context and a DOM tree for the MapML document in any case.

Essentially, I'm wondering why there are two specs and not only one that would both define a document format and a set of elements that extend HTML to provide map support. That is essentially what happened in the end with SVG and MathML: SVG and MathML exist as separate document formats but all the elements that these specs define have been imported into HTML, see SVG and MathML.

In turn, that would mean merging the two specs into one MapML spec that defines the <map> element. Spec-wise, it may be hard to do that and still re-use the existing <map> element that HTML defines. But then, although a good idea in theory, extending the <map> element does not seem like a must in practice, and I doubt that the element is being used much nowadays in any case.

[prushforth]

My access to github from work has been temporarily broken, so I'm responding by email. I hope this works. UPDATE: it did not work. SLIGHTLY edited for clarity.

Some follow-up comments to clarify how I approach this (and keep in mind I don't claim any expertise there):

I really appreciate your thinking about this, as of course I can't look at it with fresh eyes.

To follow up a bit on this, the conceptual model of MapML is based on the concept of a document. The notion is that the document represents a map. The content layout for a map document follows the painter's model. If the client application has the idea of a "map", then it should be natural to manipulate layers in the user interface. It should be natural to manipulate layers in the user interface, provided there is a way to identify layers. A MapML document, which represents a map, does not seem to define a way to identify layers that compose the map.

Many maps get by with a single layer, as optional layers complicate the user experience. The foremost objective of MapML is to represent a map at a URL. In other words, what is found at a URL for a MapML document can be interpreted as a map (based on media type semantics) and painted on a device area. I derived the model for the <map> element in part based on <img> and also <video> and <audio>. With regard to the latter two newer tags, they can have either a @ src attribute or a set of child <source> elements, from which the browser picks the one that it prefers based on the media type. The media type is the actual video, the <video> is the client application. This is similar to how I see <map> working, except that instead of being a choice of source-s the map is composed of all of the <layer>s. There's no real contract as to what a map looks like, we can only say how it should be processed. So, we define a media type with DOM-based semantics -> MapML.

The painter's model merely states that things get drawn in order. It does not help with grouping things together into a layer.

True.

Let's imagine a traffic map, composed of two layers: the bottom layer would represent the roads, the upper layer would represent the traffic (green, orange, and red blocks). Users may want to enable/disable the traffic layer. I don't know how to represent these two layers in MapML so that a client tool can offer that functionality. It seems that, to do that, I need to prepare 2 MapML documents, one for each layer, and combine them using tags in an HTML document.

This is the preferred way such that the controls of the map have a thing to enable/disable. Taking a quick peek at google shows me they take a similar approach.

That seems convoluted for a feature that is core to the definition of a map (but maybe layers are not that core to the notion of map).

Layers are fundamental to GIS and Web mapping. This is why they are the target of URLs in MapML.

In a GIS user interface, the "map" is the basis of the user interface, and map "furniture" is supplied to aid in manipulating the layers. Although the primary client of MapML is designed to be the Web browser, there's no reason that I can see that MapML shouldn't be usable by GIS programs as well. MapML document could also be the target of the URL bar in a browser, in a similar way that an SVG document can. In such a case, the map document is the browsing context. At that point, what is the difference between the browser and a GIS program? The program needs to provide the map infrastructure. Maybe for a browser that would be a synthesized HTML document with a element with a element referring to the MapML document, similar to how the browser treats a URL for an image. But maybe one day we could have a model in which such a MapML document could load script? I think that has a lot of potential.

If browsers support MapML, why imagine that they would wrap the MapML document into an HTML document with a

When the URL bar points to a MapML document, I think you're correct ( I was trying to convey that situation with my hoped-for future in which a MapML document as the browsing context could load script, but I probably didn't expend enough ink to properly describe that). Today when you point the URL bar at a png, for example, they browser does in fact synthesize an HTML document and wrap the png in it, so that's probably something simple that could be done pretty easily. I imagine getting to the point where we have our MapML semantics standardized enough to build an interoperable, scriptable DOM will take more time and effort, but I would love to get there.

Essentially, I'm wondering why there are two specs and not only one that would both define a document format and a set of elements that extend HTML to provide map support. That is essentially what happened in the end with SVG and MathML: SVG and MathML exist as separate document formats but all the elements that these specs define have been imported into HTML, see https://www.w3.org/TR/html53/semantics-embedded-content.html#svg and https://www.w3.org/TR/html53/semantics-embedded-content.html#mathml.

I agree and foresee this is the desired end state, but I didn't want to try to "take over" HTML with map semantics quite yet. In getting to that state it may be necessary to first convince the (possibly non-Web) map developer community to use MapML in their software products. As such, MapML should become an independently useful thing along the road to being a Web standard. In fact I think many browser developers would say that in order to become a Web standard it should have to prove itself by being an independently useful thing first. As such, a <map> and <layer> element would be very useful, I agree.

That being said, almost all HTML elements could be useful on a map, as part of the document infrastructure. Our first step in this direction will be to try to open the door to HTML markup within the properties of the MapML <feature><properties> element, to enable appropriate format, style and small-s semantics.

In turn, that would mean merging the two specs into one MapML spec that defines the

See above I agree this is likely to be desirable. And of course then we would have the <map> and <layer> elements in MapML :-) which we could use to define overview / key maps, controllable layers-in-layers etc.

Spec-wise, it may be hard to do that and still re-use the existing

I agree but a) the existing <map> element has almost perfect primitive semantics to allow the introduction of more 'advanced' semantics like we're talking about. It can be used as a fallback for browser that haven't implemented the MapML spec (the web platform players don't all move in unison, as I've discovered), which is important for HTML authors. b) we shouldn't pollute HTML with elements which do variations on a theme, as we make it more difficult for people to become HTML authors (cognitive loading). For example, we would not introduce a new <table> element, should we want to enhance it, now that people should no longer use it for layout since so much effort has gone into developing CSS for layout over the years. We would see that as confusing for HTML authors, I think. Same for map, as I see it. It works for one use case, let's keep it working for that while using it as the basis for more modern ways of doing things.

I tried to convey how the future Web platform could use the existing semantics of <map> and <area> in the form of a blog post which uses the image map semantics as a fallback for when JavaScript is disabled, and the custom built-in <map> , <area> and autonomous <layer-> element when JavaScript is enabled. This is analogous to two different "future" web platform browsers (e.g. Safari and Chrome), one of which has not implemented MapML (simulated by disabling JavaScript today) and the other of which has implemented MapML (simulated enabling JavaScript today): https://maps4html.github.io/Web-Map-Custom-Element/blog/progressive-web-maps.html

I think that we can't just say "this element is already taken". We need to make such a decision based on the priority of constituencies and the HTML design principles. https://www.w3.org/TR/html-design-principles/

[tidoust]

Thanks for the reply. I believe we're mostly in agreement, although we may not be looking at things from the same perspective. Some further comments.

About layers support in MapML

You seem to suggest that layer support is not a must:

Many maps get by with a single layer, as optional layers complicate the user experience. The foremost objective of MapML is to represent a map at a URL.

But then you add:

Layers are fundamental to GIS and Web mapping. This is why they are the target of URLs in MapML

... which seems to say the opposite. Also, right now, layers are not the target or URLs in MapML, they are the target of URLs in the <layer> element, child of the proposed extension to the <map> element in HTML. There is no way to target (or embed inline) a layer from within a MapML document, that is what I'm wondering about.

About the approach

I believe it is more useful to draw a parallel with SVG than with image and video media types, because:

1. The goal is to produce an ML format, not a binary format. When you point your browser at a PNG image, internally it creates an HTML wrapper because the notion of browsing context does not exist for binary media types (at least for now), so that's the easiest thing that browsers can do to get back on their feet.
2. Since it is an ML format, people will both want a way to target MapML documents (using a URL) as done for images and videos, and do embed them directly inline in HTML documents, as possible for SVG and MathML. So it seems important to think about it early on and not to imagine MapML as a completely separate format.

With that in mind, when you say:

I agree and foresee this is the desired end state, but I didn't want to try to "take over" HTML with map semantics quite yet.

... I actually mean the opposite. The idea is rather to use extension points offered by HTML, namely custom elements, to specify MapML. Native support in browsers may never happen, or it may take a long period of time (for SVG, it took about 10 years I think). The polyfill approach should work in the meantime, so that is not a big deal. I would merely focus more on embedding maps inline in HTML documents than on specifying a separate format. The nuance is thin, the latter comes naturally when you have the former. In other words, you can ignore this, it does not change much compared to what you're already doing.

About reusing the

I believe this is orthogonal to the other points raised here. My feeling is that:

1. Most developers hardly ever deal with <map>. It is neither common nor well understood on the Web. That said, looking at usage statistics for the map tag from Microsoft, I'm actually surprised to see it used in 4.2% of scanned pages. I'd be curious to understand how it gets used on sites such as Youtube, Baidu and Amazon.
2. The <map> element is meant to provide an overlay of interaction to an image, not to add more visual layers to it. That is, it does not "draw" anything. For me, the <layer> extension changes the semantics of the <map> element, as it then becomes a visual element.
3. The <map> element is meant to be associated with an <img> element. In your case, you only need the <img> element as a fallback mechanism, and will happily not render the image if you can render the layers directly. That is not the same thing. Also, we could envision scenarios where there are no useful images to render as a fallback, e.g. if we wanted some way to say "using whatever map provider you support, render a map that shows directions from the user's current location to this address", one of the scenarios suggested in Terence's mapping in HTML proposal.
4. The <area> element expects coordinates in CSS pixels, that seems counter-intuitive to me as I would imagine that people would prefer to use lat/lon coordinates for maps in most cases.

In other words, I would argue that the cognitive load is the other way round. But then I don't really think that is important for now.

[prushforth]

You seem to suggest that layer support is not a must:

Many maps get by with a single layer, as optional layers complicate the user experience. The foremost objective of MapML is to represent a map at a URL.

But then you add:

Layers are fundamental to GIS and Web mapping. This is why they are the target of URLs in MapML

... which seems to say the opposite.

Not the opposite. A single-layer map does have a layer, which is obviously very important to the map. Every map has at least one layer, in other words. What constitutes a "map"?? Obviously it is a kind of a document, so we need to think about how to not re-invent / re-specify in an incompatible way HTML's document semantics, but to leverage them to the greatest extent possible, and potentially suggesting extensions or additions where this is not possible or reasonable.

Also, right now, layers are not the target or URLs in MapML, they are the target of URLs in the element, child of the proposed extension to the

As I mentioned in the above comment:

Finally, something that we haven't experimented with but which I believe made it into the engineering report was actually allowing the element in a MapML document, such that it would dereference the @ src attribute.

although I wasn't very clear about it, that we have considered adding the <layer> element to MapML. I think the approach is clearly worth considering and experimenting with, so that its value can be established.

I think you also have been questioning why there is no <map> element in "Map"ML, which seems to focus on putting the emphasis on layers. I guess that it is a bit like asking why there is no <document> element in HTML: because of a recursive definition, perhaps?

I can see there might be value in adding the <map> element directly into the MapML specification, instead of having a separate proposal for HTML's map element, because for example a map document which is indeed a browsing context would be able to show a location map, which is a common piece of map furniture AND we would not be offending established sensibilities of HTML maintainers with respect to HTML "image maps".

... I actually mean the opposite. The idea is rather to use extension points offered by HTML, namely custom elements, to specify MapML.

I assume you're aware that we've created a custom element and I maintain the definition and working examples of MapML being used by the custom element here. Each of the URLs in the table on that page is actually a MapML document url, which is content-negotiated by the browser initially to HTML and subsequently by the embedded custom element client as text/mapml, allowing a 'preview' experience that doesn't leave the user looking at a useless text file download.

Native support in browsers may never happen, or it may take a long period of time (for SVG, it took about 10 years I think). The polyfill approach should work in the meantime, so that is not a big deal.

I first presented the idea as a power point presentation to OGC Mass Market Working Group at Google HQ in 2009. So 10 more years doesn't sound unlikely. However, I think the Web may not ever be improved upon, or superseded as a medium, so I believe it's worthwhile to spend the time and effort required to improve the Web by extending it with spatial information.

About reusing the

I believe this is orthogonal to the other points raised here.

Yes and no. It can seem like "bikeshedding", but when you look at MapML, many elements are "borrowed" from HTML, The semantics of all the borrowed elements are slightly different from those they're borrowed from in HTML. For example, we've added several <input> type values and other attributes. Other current examples include: <head> <body> <meta> <link> for starters. We plan to 'borrow' other elements for marking up feature properties, so that they may be appropriately presented to humans while maintaining machine compatibility. In fact we would like to borrow the <form> element, too. The borrowing should come with ideally NO change of implied semantics for existing markup, but some extensions are inevitable, I think.

These are all good reasons to keep the vocabulary in a separate media type. But the fact remains that adding a new element to HTML means what you suggest, an eventual addition of vocabulary into HTML per what happened with SVG and MathML.

When the day comes to extend HTML with maps, instead of adding every MapML element as a new element to HTML, why not extend some, if their existing markup semantics can be maintained, <map> included. The technique of adding new attributes to existing elements implying new semantics while preserving old semantics seems to be an established practice.

This is going to be a big discussion, I think, which is why the semantics of MapML need to be carefully shepherded, and not allowed to become grossly overbearing of homologous elements in HTML.

That said, a little more on the topic of <map>.

1. Most developers hardly ever deal with <map>. It is neither common nor well understood on the Web.

The HTML documentation about it is very misleading, for one thing. It is represented as being for site navigation, or as a way to reduce duplicate markup in a page.

In fact, the <map> element was added to HTML partly as a successor to the img@ismap technique, which was created early in the history of the Web to support maps!

2. The <map> element is meant to provide an overlay of interaction to an image, not to add more visual layers to it. That is, it does not "draw" anything. For me, the <layer> extension changes the semantics of the <map> element, as it then becomes a visual element.

While it's true that the <map> has a 'transparent' content model, the img which is associated to the map is a visual element, which indeed has a @src attribute like the proposed <layer> element. The fact that the img does not have to be a child of map is incidental; they are just as linked, and the img is a visual element, and the area elements refer to the img's coordinate space, and are thus 'visual' elements, if only by changing the cursor when hovered over.

Furthermore, there (was) (I believe) no need to draw the area links or enable them to be styled with CSS, because the HTML author could use an image editor to draw the areas of interest in the image.

Back in the day when <map> was invented, CSS was primitive and there was little or no JavaScript so it was easy enough to make it a multipurpose element by specifying the association through the @name / @usemap . So they used markup to manage layout of the document in that case, not CSS and/or script. The same was true of tables, and I believe other now-deprecated HTML elements.

But while it may be an obsolete technique to manage document layout (seemingly encouraged by HTML documentation!), a) there are lots of sites which continue to use it for layout as you suggest, but there are also, probably, lots of sites which use it for mapping.

I'm actually surprised to see it used in 4.2% of scanned pages. I'd be curious to understand how it gets used on sites such as Youtube, Baidu and Amazon.

I would someday like to try to analyze the percentage breakdown of sites which use it for site navigation vs. the geographic mapping case. I think this would have to be done by manual site inspection / sampling!

3. The <map> element is meant to be associated with an <img> element. In your case, you only need the <img> element as a fallback mechanism, and will happily not render the image if you can render the layers directly. That is not the same thing.

It's progressive enhancement. I'm taking the processing semantics of the element, and extending them with script (our custom built-in <map> element). I think the same technique used by future HTML authors, which could be implemented by browsers' native <map> / <area>code to provide (without script):

1. ) fallback for future non-MapML-compliant browsers
2. ) not breaking existing Web sites like those linked above which use the existing <map> element semantics and
3. ) new MapML / layer functionality for sites that target future MapML-compliant browsers.

if we wanted some way to say "using whatever map provider you support, render a map that shows directions from the user's current location to this address", one of the scenarios suggested in Terence's mapping in HTML proposal.

I am not keen on the idea of my browser accessing a site automatically, I think it is a security consideration, and I would hesitate to add it to HTML for sure. In any case I would like to hear what the browser developers think of the idea. OTOH if Terence or his organization would like to join the Maps for HTML Community Group (they've been invited) to argue for and prototype this, I would welcome that.

4. The <area> element expects coordinates in CSS pixels, that seems counter-intuitive to me as I would imagine that people would prefer to use lat/lon coordinates for maps in most cases.

Yes. Pixel coordinates can be georeferenced by a defined CRS association, however, so we should think about that use case a bit. In fact the units in the Tiled Coordinate Reference Systems (TCRS) defined by MapML have georeferenced pixel units at all zoom levels ( with the exception of "WGS84", which is adopted as a "TCRS" because everybody uses it already, as you suggest above).

Coordinate systems are at the heart of interoperability, or more accurately lack of interoperability in geographic information, and this is a core value of MapML.

Anyway, I accept your suggestion to add <layer> to MapML, although it requires prototyping and experimentation to determine if it's workable. I would like to suggest that we also add the <map> element to MapML, although it seemed simpler to make it a 'proposal to HTML', it seems the whole vocabulary is such a proposal. If you think adding <map> to MapML would not be confusing, please indicate in your reply; I'll add an issue related to both <map> and link it here (which I take to be a request to add <layer>).

Thanks for the good discussion!

[tidoust]

I would like to suggest that we also add the

The request here was indeed more a request to add <layer> to MapML.

Since I find the current reuse of HTML tags confusing, I believe adding <map> to MapML would be confusing too. That said, by adding <layer> to MapML, what I hope is that extending (and reusing) <map> would no longer be needed in the end. That is, I believe that, to reference a MapML content from an HTML document, one would either:

1. use an <img> or <iframe> element that points to a MapML document. I realize that this solution is less ideal from an interaction perspective as map interaction would de facto happen in a separate browsing context
2. insert a <mapml> element directly within the HTML document. And I believe this point should be given some thoughts early on, as it probably impacts how HTML elements are reused. For instance, SVG does not have elements in common with HTML which makes inline embedding easier. It used to define elements taken from HTML in its own namespace such as the <video> element, which proved problematic, precisely because the elements had slightly different semantics from those in HTML. These elements were dropped.

[prushforth]

use an or