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.