MapML.js release v0.14.0: CSS and Pmtiles

Scripting, Styling and Web Maps: Who’s On First?

The Big Three

Part of the job of being a Web standard means that you have to follow the architecture of the web, which allocates specific jobs across the Big Three languages: HTML, CSS and JavaScript.  For JavaScript, this ideally means supplying and enhancing site-specific semantics and user experience, and leaving accessibility and rendering up to the browser’s HTML infrastructure; for Cascading Style Sheets, it means supporting the HTML rendering engine through accessibility-enhancing styling instructions declared by the page according to the CSS language.  For HTML, it means parsing the page and rendering HTML elements as accessible content, and providing a DOM API to allow access to the content by JavaScript manipulation to provide and enhance effective user experiences.

In the Maps for HTML universe, our goal is an update to Web standards that sees maps and location decomposed with accessibility as a precondition, into rendering, style and behaviour, and fit into the appropriate architectural domain, be that in HTML, CSS or JavaScript.  There is no support today for maps or location in any of the Big Three languages. The consequence of this lack of platform support for web maps is their exclusive and massive allocation to the JavaScript domain.  The societal implications of this misallocation are a subject for another post.

To date, we have articulated a mechanism to embed accessible and semantic web maps and locations into an HTML viewer widget, the <mapml-viewer> element.  So far, the fit of this widget to the HTML media widget paradigm seems appropriate.  For a refresher on how the viewer works, check out our Quick Start video.

The question that bears additional scrutiny and community involvement, and that which is the question of this post is: How can we better leverage CSS for styles of maps and location, while enhancing accessibility?  Opaque (binary) media types HTML media like video and audio don’t have much relationship with CSS, whereas map rendering has a natural connection to text and graphics styling.  It’s the natural connection of maps to web architecture that makes maps and location a good candidate for a web standard.

What You Can Do With CSS in MapML Today – Support by GeoServer

The main use of CSS in MapML is to style the tree of elements rooted at the <map-feature>.  The <map-feature> element is a custom element that can be obtained in a fetched MapML-format XHTML document, or found inline in HTML proper, between the <layer-> … </layer-> layer tags.  <map-feature> elements are parsed and their <map-geometry> elements rendered as a shadow-DOM embedded SVG <g> tag (group element), with different geometry values rendered within that group as <path>s within the parent <g>.  Any class attributes on the <map-feature> are copied to the root <path> element, and class attributes on descendent geometry elements are copied to the <path> that they are rendered as. This allows us to apply CSS rules to <map-feature> as though its parts were actual SVG tags, so long as the rendered feature parts can be selected via their class, which is copied from the source <map-whatever> element.  This can even be useful for making accessible interactive maps. 

This technique  is used by GeoServer for example, which transforms Style Layer Descriptor server styles into CSS stylesheets with selectors for generated class values from the server layers’ contents.  In addition to allowing basic styling of points, lines and polygons, this facility enables GeoServer to dynamically generate and style MapML-encoded vector tiles.  The perceived performance of tiled vector maps can be acceptable, especially when such tiles are created and cached for later access, and improvements can be expected with additional specification and software development effort.  This is all pretty interesting because it is starting to show us a path to (better) integration between the native web platform languages like HTML and CSS on the one hand, and maps on the other.

Mapbox Vector Tiles and the pmtiles Archive Format

“pmtiles” is the name of a modern, cloud-friendly map tile archive format that is gaining popularity among web mapping applications, because it allows websites to readily serve their own map vector tile data without necessarily hosting the whole world, which is cost- and time-prohibitive.  The motivation behind pmtiles (a product of the Protomaps project) would seem to be compatible with our community’s goal of standardising maps for the web. In the words of its creator Brandon Liu, :

Maps are everywhere on the Internet. Think of any popular retail site, travel search or local government portal. The infrastructure of the web, from languages like JavaScript, front-end frameworks, and databases, is overwhelmingly free software. Maps are one of the few remaining choke points* of an otherwise open web.

* choke points aka control points

pmtiles efficiently manages potentially massive amounts of tiled vector data in a single archive file.  The archive can be hosted in a variety of server environments, but the main criteria for success is that the host server is capable of http range requests. When a client needs a particular tile, it makes the request not using the zoom, row and column coordinates as URL parameters or path steps, but by transforming the tile’s coordinates to a pmtiles archive byte range, using the tile’s byte offset and length, calculated from the archive’s metadata which contains, among other information, the formula to perform the transformation.

Under the hood, a .pmtiles archive file is a clever application of Hilbert space filling curves to efficiently compress tiles in the Web Mercator projection, encoded in the Mapbox Vector Tiles or other format (mvt).  Mvt is a kind of de facto standard among vector tile formats, of which there are many, too numerous to mention.  The protomaps-leaflet library integrates support for both .pmtiles archives as well as raw .mvt tile responses served through a web server API, following the {z}/{x}/{y} URL (template) convention.  Protomaps-leaflet styling of tiles is accomplished via “themes”, or “rules”.  Rules encode canvas 2D API call parameters on a per-tile, per-layer basis, such that map feature styles are encoded as JavaScript objects and methods that are called back by the protomaps-leaflet tile rendering engine. A theme is a named collection of rules, e.g. “light” or “dark”.

The newly-renamed MapML.js release 0.14.0 supports pmtiles archives and .mvt format API services, including custom map styling, via a protomaps-leaflet integration, mainly through the templated <map-link> element.  Projection support is currently limited to OSMTILE maps, because of the (hopefully short-term) restriction of protomaps-leaflet to the Web Mercator projection and powers of 2 tile pyramids. Custom styles can be created and included as a “stylesheet” module by means of an exported symbol named “pmtilesStyles”, containing a defined and required JavaScript object structure.

If you’re using GeoServer, or pmtiles / mvt support in MapML.js, or any open source component from our community in your maps, please get in touch, we’d love to hear from you about your experience.

Call For Community

A large measure of the payoff for the effort of building maps into HTML will be simple and decentralised access (i.e. no “choke points”) to the incredible rendering performance afforded by native code styling through CSS.  What wouldn’t be possible in such a world?  Accessible location navigation, animations, moving features, real time location updates, oh my!  Worth mentioning: the CSS development community often sets an example of dynamic, open collaboration definitely worthy of emulating, if not wholly joining forces with.

In summary, let’s take the “special” out of spatial, and collectively imagine, design and implement a HTML+CSS engine capable of fully expressing and executing cartographic rules, for the future.