Skip to toolbar

Community & Business Groups

Maps For HTML Community Group

The Maps in HTML Community Group seeks to establish at least one hypermedia type which can be considered to be consumed by a (new) "map" element for HTML. Follow-on from Bar Camp at #lgd14. The objective will be to define a hypermedia type which can be linked to from a hypothetical (but prototyped in Web Components) "map" or (geo-map for Web Components) element which will provide simple mashup capabilities and user interface.

This group will publish specifications.


Group's public email, repo and wiki activity over time

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

final reports / licensing info

date name commitments
Report on the Joint W3C-OGC Workshop on Maps for the Web Licensing commitments

drafts / licensing info

Use Cases and Requirements for Standardizing Web Maps
The HTML map element proposal
Map Markup Language

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

Publish Reports

Winter 2021 Report

This post is a bit of catch up for several months of activity. I hope it summarizes most of what we’ve worked on since about the beginning of October 2020, just after our successful workshop. If you see that I’ve left anything out, get in touch!

In Web standards, the term polyfill refers to a software package that implements a proposed or existing Web standard in JavaScript.  Sometimes these libraries are needed to fill the interoperability gaps between different Web browsers’ implementation of a feature.  Other times, such as this one, they are developed  as a reference or pilot implementation, which resolves research questions experimentally and which provides a hands-on experience for a future standard.  In this case the future standard that we’re polyfilling is a proposed extension of HTML, that we call MapML.

Accessibility Comes First

The first thing that we worked on this past fall and winter in the MapML polyfill was to improve the keyboard navigation of query and feature popups, by adding forward/backward navigation controls to the bottom of the popup. These controls prevent a keyboard-only user from getting trapped in a sequence of many features by providing fast-forward or fast-backward mechanisms. There is still work left to do, which is made a bit harder by the fact that the Leaflet project appears to be on hiatus and is not accepting pull requests.

While deep in the maps-in-the-browser polemics with @shepazu, it was agreed that while popups are a common visual UI used for map and feature interrogation, they are certainly not the only option. Further, and a sign of hope for the continued evolution of HTML in the Web Platform, there is currently a well-received proposal for a native <popup> element. As a result, we have tentatively decided to disarticulate the MapML proposal at this junction; we’ll try to specify a query/popup event, which could be emitted and handled by a native widget, but just as easily handled by a custom element or other script-based client based of the native widget. The result is a simplified MapML proposal, which we think is a win for all concerned.

The video also demonstrates the implementation of the <feature> element with a child <featurecaption> element, which allows a feature to have a consistent “accessible name“. Accessible feature names were established as a requirement of workshop participants. The <featurecaption> element is rendered by the polyfill as an aria-label attribute on the output SVG content. The <featurecaption> element allows a screen reader and mouse user alike to efficiently navigate through map features. They are supported by the polyfill, and in GeoServer you are able to map any combination of feature or coverage attributes to the element returned by GetFeature or GetFeatureInfo queries, via a ${template} substitution mechanism.

One of the big ideas that has been pushed by Maps4HTML community member @zcorpan, among others, is that the MapML proposal needs to be expressed in terms of shareable primitives (my words), in other words, provide one or more APIs. Furthermore, it is pretty clear from the experience with the <video> element and pretty much all the native controls provided by the browser, that one of the first things programmers want to do is change the UI of stuff. So one of the side projects that we started was to create a script-based client of our polyfill suite. We hope to push this work further in autumn 2021, in particular to provide an outlet for rendering the diversity of vector tile formats.

One potentially important and shareable primitive of a native element would be the projection engine that, if robust, might support a wide variety of “custom” projections via an API. We also have made a first pass at mocking up such a facility, for example, here’s an implementation of the British National Grid with data from the Ordnance Survey UK, mashed up with data from the British Geological Survey.

If you have a look at the source of that page, you’ll see the following definition of the coordinate system in use:

 let customProjectionDefinition = `{
            "projection": "BNG",
            "proj4string" : "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.999601 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894 +datum=OSGB36 +units=m +no_defs",
            "origin" : [-238375,1376256],
            "resolutions" : [896,448,224,112,56,28,14,7,3.5,1.75,0.875,0.4375,0.21875,0.109375],
            "bounds" : [[-238375,0],[900000,1376256]],
            "tilesize" : 256

In GIS-land, that definition could be abbreviated to just the proj4string value (or something akin to it), which provides the parameters of the projection method. The GIS world has even gone so far as to define well-known codes that can be used to abbreviate the abbreviation, in this case EPSG:27700, which is short for the British National Grid, which is a very convenient shorthand.

Unfortunately, the codified definition is insufficient for Web use, as can be seen by the presence of the required additional “origin”, “resolutions”, “bounds” and “tilesize” JSON members. These parameters do exist in the definition of TileMatrixSets from OGC specifications, and I have tried suggesting that these parameters be included in the codified definition of CRS, with no success so far.

Please get in touch if you have ideas about this problem on the Web; I believe this is related to best practices 6 and 12 and possibly others! MapML’s definition of Tiled Coordinate Reference System is founded on adding these parameters, and tries to obtain the convenience of the codified approach with its projection name tokens: ‘OSMTILE’, ‘WGS84’ and so forth.

Requirements Fulfillment Matrix

The Maps for HTML community’s Use Cases and Requirements for Web Maps specification is intended to be an evolving representation of what a native Web map widget would need to be able to do for users. The document’s major structures are: Use Cases, map viewer widget capabilities, and client-side / widget APIs. Operating examples of each use case are provided where possible, implemented by each of several Web mapping toolkits and/or Web map content providers. This UCR document is recognized by the browser developer community as representing the best path to success for Web maps, and it was recommended that we continue to evolve that document to the point we have got solid agreement on it from the Web mapping and Web standards interests.

Some community members have been working on the MapML Proposal and its associated polyfill Web map widget for several years, and in light of the weight given to the UCR process by the browser developer community, we thought it wise to begin the process of tabulating exactly how well or to what degree our specification and polyfill track the identified requirements (capabilities). So Doug Schepers, Maps for HTML community member and former W3C staff SVG leader, contributed the UCR Fulfillment Matrix, which is a visually comprehensible 2D representation of the spec and polyfill’s progress against the UCR document. We intend to maintain and extend the UCR Fulfillment matrix with linked operating demonstrations of the polyfill and associated specification sections.

At this time, the community is looking for a Web mapping-and-standards -savvy organization to pick up the important work of stewarding the UCRs and associated Fulfillment Matrix to agreement and completion. Please get in touch if you know of a company, government or NGO that might be willing to help in this area.

Implementing the GeoWeb

Browsers have included a non-spatial but accessible <map> element for more than two decades, for example, this Canadian weather map is used to provide an accessible yet simultaneously visual access to weather forecasts for communities across Canada. It uses the native <area> element to link to provincial maps and communities. The reason it is ‘non-spatial’ is because the coordinate system used by the <area coords="..."> elements is defined on the ‘client side’, by the <img> that uses the <map> to provide the visual component. In an earlier age, client side image maps were popular for graphical site layout, much like <table> used to be used for grid-based site layout, before the improved separation of semantics from style that CSS brings to the Web. Nowadays, client side image maps aren’t recommended for use, but they still maintain the accessibility advantage of simple native hyperlinks. And the beauty of that is that unlike their “modernized” counterparts, such maps form part of the non-JavaScript Web, exposing their accessible information content to users and crawlers alike.

At our workshop, we heard from some participants that HTML should include an emphatically non-spatial native element, perhaps named “slippy”, that could allow for both non-spatial AND spatial maps that support pan and zoom aka native rendering. But that doesn’t make sense. Such an element would be taking perfectly georeferenced content (from a server), be it images, or tiles, or features, and removing information from it (the georeferencing) in order to render it. Such an implementation would defeat the interoperability goals that public spatial data standards-makers have sought for decades. Indeed the Open Geospatial Consortium was founded on the notion of interoperability of spatial data so that you could overlay them and gain insight from the resulting mashup.

Since “slippy” is an ill-conceived approach, ignoring as it does HTML semantics; a more sensible path is to recognize that HTML already has an accessible yet non-spatial element that could be progressively enhanced and made slippy (natively rendered) if sufficient coordinate system metadata (in the form of attributes) is present. The benefit, besides consistent semantics, is that Web pages that have maps in them become georeferenced, spatially indexable, spatially searchable and, if the provider permits it, as the operators of spatial data infrastructures generally do, potentially mashable.

In any case, regardless of the bikeshed problem, a native element can learn from the existing Web, and employ hyperlinks to advantage, so we set out to experiment with use cases that required hyperlinks. To remain faithful to the notion of the “shared primitives” imperative, one of the core use cases is backwards-compatible (with client side image maps) -yet-slippy rendering of images which are non-spatial, with links in them. Our implementation example does not quite meet all possible requirements yet, since the base image is not a single static image or even a set of responsive images, but is a classical “tile pyramid” that is readily managed by scripted URL template techniques. On the other hand, it does provide examples of internal and external links on top of a non-spatial tile pyramid, using <feature>s with a descendant <map-a> element.

The Web as a Federation

The Web itself is a large scale federation that applies standards, such as HTTP and HTML and so on. Regardless of what technology we use to implement them, if we want to play on the Web, we need to use the standards. And what is the glue that keeps that federation together? It’s the humble hyperlink, <a>, that’s what. So, why should the thing that binds the Web together not work for maps? That’s the idea behind this experiment (you might want to use Firefox to view, since Chrome is getting persnickety about mixed content), which draws on the standards-based infrastructure of the Arctic SDI. The links in that document bind together maps of different projections, which could in theory be on different domains i.e. in different countries. The resulting usable map is federated by linking with the <map-a> feature link implementation. <map-a> is a work in progress, and probably not yet properly accessible. If you have comments or suggestions, please let us know via an issue or by any means necessary.

Changing Projection Depending on Zoom

If you’ve clicked a little bit in the previous demo, you’ve experienced changing the projection of the map when following a hyperlink. A potential requirement of maps in HTML could be changing the projection of the map based on the zoom level. This is often seen to good effect in modern Web map silos: as the user zooms the map out, the projection changes from Mercator tiles to the globe view of the Earth. So we implemented a prototype of that capability, which can be experienced if you follow the Canada link in this map, and zoom in. The map projection (and source) should change from Lambert Azimuthal Equal Area (the initial view) to (at first) another completely custom polar projection (Atlas of Canada’s Polar Wall map), and then to the Lambert Conformal Conic that forms the backbone of Canadian federal map services. If you zoom in even further, you will change sources to the public OpenStreetMap tile cache, in its Web Mercator glory. While a globe view of the Earth remains an unrealized (dream) use case, we are pursuing defining the markup semantics that will allow us to take good advantage of it when it does arrive. If you know of an organization that might be interested in contributing a globe view capability to the polyfill, do get in touch.

That’s all for now. Apologies for not writing more regularly; that is an important thing that gets forgotten in the fray. If I’ve missed anything that you can think of, please drop me a note.

Thank you

Thanks to Ahmad Yama Ayubi, for his able help in clarifying my sketchy requirements, and implementing them without the sketchiness. Much / most of the JavaScript code described in this post was conceived and developed by him.

I would like to thank Amelia Bellamy-Royds and her team, Nic Chan, Nick Fitzsimmons and Bennett Feely for their excellent work on the UCR document and the workshop web site, we definitely couldn’t have done it without you all.

Thanks also to Doug Schepers, who got into discussing the details of this proposal in a way that very few people have had the time or inclination to do; without that friendly debate I would despair.

Many many ongoing thanks are due to Robert Linder, who keeps me inspired with his determination to see accessible Web maps realized, for everyone. Robert has also made significant contributions to the overall coherence of the documents we’ve produced and his attention to detail is very much appreciated.

Faster, smoother Web maps with new browser features

As an active developer of the OpenLayers mapping library, I have been working a lot on performance improvements in the rendering pipeline. Performance is usually good, but there are corner cases where the user experience is negatively affected by an unresponsive user interface. There is a new browser technology, OffscreenCanvas, which allows rendering in web workers that run in parallel to the main thread. Unfortunately it is not widely supported in mainstream browsers. In this post, I am going to show how rendering performance in OpenLayers could benefit from OffscreenCanvas.

Continue reading

The Design of MapML

So, the big idea is this: MapML resolves the Web Platform gap by combining map and map data semantics into a hypermedia format that is syntactically and architecturally compatible with and derived from HTML. MapML provides a standardized way for declarative HTML content to communicate with  custom spatial server software (which currently use HTTP APIs based on multiple queries and responses). MapML allows map and map data semantics to be either included in HTML directly, or referred to at arbitrary URLs that describe stand-alone layers of map content, including hyper-linked annotations to further content. This allows HTML and map authors to easily create markup inline or refer to Web map content from their documents without needing procedural programming (JavaScript) to fetch and integrate data.  Finally, MapML defines a DOM structure for the map content that can integrate with Cascading Style Sheets and JavaScript, in exactly the same way HTML content does.

Continue reading

Maps4HTML is on GitHub

There is a new Maps4HTML organization on GitHub, dedicated to the use of the Maps For HTML Community Group.  Every member of this Community Group has received an invitation to join the members team on that organization.  Members can create repos associated to the organization.

A key factor in the success of any Web standard is community.  To that end, if you accept the invitation to join the Maps4HTML community on GitHub, please consider making that fact public.  Your presence on the front page of the organization will help drive other interested people and companies to join us.

The objective of the Maps4HTML organization on Github is to help us collaborate not just on ideas, but on actual specification and implementations of those ideas.   You will find a few repos already there which may help stimulate more ideas and prototyping.  Go for(k) it!

Please feel free to discuss existing repos either as issues or on the Web Incubator Community Group Discourse forum for Web mapping.  Demonstrating community support for a standard is as important as specifications and implementations.

Let’s get the geo-Web moving again!


New forum to discuss standardization of Web maps

Standards are hard.  Just ask anyone who has been in the trenches of standards organizations working for the Web. Getting agreement on technical subjects requires a lot of effort, on the part of individuals and organizations.  The broader in scope the intended standard, the greater is the requirement for simple, clear language, meaning and function. Importantly, the greater is the requirement for diverse community input, if not agreement.

The Web Incubator Community Group (WICG) was created from the successful experience of the Responsive Images Community Group, in order to facilitate broader contribution to the development of Web standards that respond to community needs.

Realizing that mailing lists are not always the most productive environment in which to develop standards, the WICG hosts a discussion resource for the Web standards community based on the Discourse platform, and they have graciously accepted to host a category dedicated to Web mapping for the use of our and related communities.

The Maps For HTML Community Group is dedicated to the development of Web standards which support Web mapping, which with your help, will lead to integration of maps into the Web platform.

Please join us, and contribute to the grassroots of the Web mapping standards development process!