TPAC 2025
Kobe, Japan & online
10–14 November 2025
Satoru Takagi-san convened a TPAC 2025 breakout session to document and discuss his "Hyper-Layering Architecture" (HLA) proposal for maps on the web. The HLA proposal envisions a layered approach to web maps, where different layers of map data and functionality can be combined and interacted with in a loosely coupled and de-centralized manner.
It is my belief that the HLA 2.0 described by Satoru is at its core compatible with the MapML proposal, which is actually the subject of my presentation. However, estblishing this compatibility remains the subject of future collaboration and integration efforts to harmonize the two proposals, and it is my hope that a unified proposal to shape the future of the web may emerge from this process. Therefore, before talking about the details of MapML, please allow me to play a short video which compares and contrasts HLA 2.0 with MapML, from Satoru's perspective.
MapML is a proposal to make maps and locations accessible and interoperable as part of HTML
The idea is to create a layered map viewer element, similar to <img>, <video> or <audio>. MapML is polyfilled using custom autonomous HTML elements. A simple working example follows:
<mapml-viewer controls zoom="17" lat="34.666" lon="135.213"> <map-layer checked hidden src="openstreetmap.mapml"></map-layer> <map-layer src="kobe-convention-centre.mapml" checked ></map-layer> </mapml-viewer>
Making maps part of the HTML standard will improve accessibility and usability for users.
Creating simple maps should be simple; making complex maps should be possible, using standard tools, i.e. HTML, CSS, JS.
MapML will reduce the web's dependence on proprietary services, promoting privacy and decentralization by enabling user choice.
2022 research showed that 16% of web pages loaded a JS mapping library. For context, the <video> element was measured on 4.1% of page loads at the time.
Developers are forced to rely on complex, and in some cases inaccessible JavaScript libraries, due to lack of standards support for maps and location.
Location is a fundamental primitive form of information on the web, akin to text, images, video and audio.
Accordingly, maps should be prioritized for implementation by the web platform.
2020 community research demonstrated that maps built with JavaScript have highly variable accessibility, creating an inconsistent and often exclusionary experience for users. In research by Bocoup from 2022, 84% of developers reported that they lacked the tools to create accessible maps.
Map publishing is dominated by centralized platforms who track user location and search interests. Users have few privacy-preserving alternatives. Standardization of maps in HTML would facilitate a decentralized web of mapping services.
Map interfaces vary widely across sites. Standardizing an accessible map widget would give the web a baseline experience for maps, as well as a foundation for innovation. Implementing an accessible map and location rendering system will lead to a virtuous feedback loop for the web.
Following our successful, global 2020 Maps for the Web joint W3C/OGC* workshop, our community co-chair led extensive research and documentation of mapping use cases and requirements
There are likely scenarios that we haven't considered yet, which may give rise to more use cases and related requirements.
*Open Geospatial Consortium
Use cases are catgorized by user persona:
The Use Cases and Requirements (UCR) specification attempts to identify the capabilities a mapping application must have in order to fulfill those use cases. Each capability is further categorized as a requirement, an enhancement, impractical or undecided
A central hub for MapML is our developer documentation site.
There is a reference section for each element and its proposed interface. For each element or interface there is a "Requirements" section.
The Requirements section is formatted as a table that links the element or interface's capabilities to the specific capability identified by the UCR document, and to the spec for that feature. The aim of this table is to be able to compare what is implemented against the requirement.
Where applicable and available, there's a link to the specification for the feature, if a capability has been described there.
The MapML polyfill was the subject of collaborative research and development by the OGC and W3C community prior to the 2020 Workshop, and subsequent requirements formalization. Since 2020, MapML has seen further refinement and development driven by UCR requirements, and community input.
The polyfill is seen as a vital tool, not only to respond to, but also to generate and elaborate requirements. Prior to the MapML polyfill, there was no purely declarative mapping solution for the web. With the development of the polyfill, it became possible to explore the capabilities and limitations of a declarative mapping approach. Because the polyfill is based on JavaScript libraries, there is a practical limit to how much code we can include before the implementation becomes too large to be practical for web use.
Some requirements that drive the polyfill development
Declarative extension of HTML. "View Source"
Maps and location semantics built into element(s) behaviour
Progressive enhancement of existing HTML semantics where possible and practical
Pave the cowpaths of the geospatial web, too: integrate existing services, data
REST / hypermedia-based format / loosely-coupled specification
DOM-available feature model following OGC Simple Features standard
Use / import / render / save GeoJSON for feature content
Standard and accessible linking, usable by user, for map state transitions
Enable location indexing / spatial search of the web
Strong keyboard and screenreader map / feature navigation
Icons / pushpins
Add layers via URL to layer, not neccessarily as services
Map scale, projection, coordinate reference systems as defined by science and practice
Enable application of CSS on map content
Standard DOM API for mapping elements
Support mashups with different domain layer content
Standard license / attribution / layer metadata links
MapML defines what are called Tiled Coordinate Reference Systems (TCRS). TCRS are a way of bundling a tiling system and a Coordinate Reference System(CRS) together, so that a map layer can be self-describing via the MapML media type definition. This simplifies the developer interface to maps in HTML.
<mapml-viewer zoom="17" lat="34.666" lon="135.213" controls projection="OSMTILE"> <map-layer checked hidden src="openstreetmap.mapml"></map-layer> <map-layer src="kobe-convention-centre.mapml" checked ></map-layer> </mapml-viewer>
The MapML viewer represents a rectangular viewport in a document. It can be the whole page, or there can be
many viewers on a page, each subject to CSS styling. A viewer element contains one or more layer elements, rendered in painter's order, each of which can contain map features, tiles or templates for features and/or tiles. The viewer has attributes to set the initial view, including latitude, longitude, zoom (scale) level, and controls for user interaction. The viewer also supports different map projections through the projection attribute.
MapML layers are defined using the <map-layer> element. Each layer can contain features, tiles, and / or one or more templates for loading tiles or features, wrapped in the <map-extent> element. Many layers can be added to a viewer element to create a "mashup" map experience. The layer element has the checked boolean attribute to indicate whether it is displayed on the map. The checked attribute serves as an important API for map layers. The layer element also has the hidden boolean attribute, which serves to hide the layer from the layer list UI, but still include it in the map rendering.
<map-layer checked hidden src="openstreetmap.mapml"></map-layer> <map-layer src="kobe-convention-centre.mapml" checked></map-layer>
<map-layer checked label="TPAC 2025 Venue">
<map-meta name="projection" content="OSMTILE"></map-meta>
<map-feature zoom="17">
<map-featurecaption>神戸国際会議場 <br>Kobe International Conference Center</map-featurecaption>
<map-properties>
<h2><a href="https://kobe-cc.jp/en/facilities/conference-center/">神戸国際会議場<br>Kobe International Conference Center</a></h2>
</map-properties>
<map-geometry>
<map-point>
<map-coordinates>135.213171 34.666085</map-coordinates>
</map-point>
</map-geometry>
</map-feature>
</map-layer>
Layers can be loaded from external MapML documents using the src attribute, or defined inline within the <map-layer> element. Layers can also include metadata using the <map-meta> element, which can define properties such as the projection used by the layer.
Standalone MapML documents encoded as XHTML are an important use case. The existence of
such documents and the corresponding text/mapmlMIME media type is required to enable the simplest use case of creating a dynamic layered map using hyperlinks, similar to
embedding images or videos in HTML pages.
<mapml- lang="ja" xmlns="http://www.w3.org/1999/xhtml">
<map-head>
<map-title>オープンストリートマップ</map-title>
<map-link rel="license" href="https://www.openstreetmap.org/copyright" title="© オープンストリートマップの貢献者 CC BY-SA"></map-link>
</map-head>
<map-body>
<map-extent units="OSMTILE" checked="checked">
<map-input name="z" type="zoom" min="0" max="18"></map-input>
<map-input name="x" type="location" units="tilematrix" axis="column"></map-input>
<map-input name="y" type="location" units="tilematrix" axis="row"></map-input>
<map-link rel="tile" tref="https://tile.openstreetmap.org/{z}/{x}/{y}.png" ></map-link>
</map-extent>
</map-body>
</mapml->
<!DOCTYPE mapml>
<html lang="ja">
<head>
<title>オープンストリートマップ</title>
<meta charset="utf-8">
<link rel="license" href="https://www.openstreetmap.org/copyright" title="© オープンストリートマップの貢献者 CC BY-SA">
</head>
<body>
<extent units="OSMTILE" checked>
<input name="z" type="zoom" min="0" max="18">
<input name="x" type="location" units="tilematrix" axis="column">
<input name="y" type="location" units="tilematrix" axis="row">
<link rel="tile" tref="https://tile.openstreetmap.org/{z}/{x}/{y}.png" >
</extent>
</body>
</html>
<map-extent>A <map-extent> element defines a map 'form' that binds to the viewport of the map viewer. Within the <map-extent> element, you specify
variables, using <map-input> elements, to bind to a scalar property of the predefined viewport positions (top-left, bottom-right, etc) or properties (e.g. scale). Scalar properties include zoom, easting, northing, longitude, latitude or relative or absolute pixel coordinates. These variables are used to 'fill in' the form and submit to the server, obtaining images or other map resources (tiles, features) for rendering.
<map-layer label="オープンストリートマップ" checked>
<map-extent label="OpenStreetMap tile template" checked hidden units="OSMTILE">
<map-input name="z" type="zoom" value="18" min="0" max="18">
<map-input name="x" type="location" units="tilematrix" axis="column">
<map-input name="y" type="location" units="tilematrix" axis="row">
<map-link rel="tile" tref="https://tile.openstreetmap.org/{z}/{x}/{y}.png">
</map-extent>
</map-layer>
MapML features are defined using the <map-feature> element. Each feature can represent a point, line, or polygon on the map, and can include additional metadata such as titles, descriptions, and styling information.
<map-feature zoom="17">
<map-featurecaption>神戸国際会議場 <br>Kobe International Conference Center</map-featurecaption>
<map-properties>
<h2><a href="https://kobe-cc.jp/en/facilities/conference-center/">神戸国際会議場<br>Kobe International Conference Center</a></h2>
</map-properties>
<map-geometry>
<map-point>
<map-coordinates>135.213171 34.666085</map-coordinates>
</map-point>
</map-geometry>
</map-feature>
The <map-feature> element is based on the foundational OGC Simple Features standard, and is therefore
compatible with GeoJSON, KML, Shapefiles and other common geospatial data formats. Features can be styled using CSS, and can include interactivity through event listeners and other JavaScript APIs.
We are seeking feedback and collaboration from the W3C community, and especially the browser projects, on the our proposal, including the polyfill implementation, use cases, and requirements.
We invite participation in the Maps for HTML Community Group to help refine and advance the proposal towards standardization.
If possible, the Maps for HTML community would prefer to integrate the MapML and HLA 2.0 proposals into a single coherent proposal for standardization and implementation
Please provide your feedback and insights to help us move forward with a unified community-backed proposal.
For more information, please visit the Maps for HTML Community Group at maps4html.org.
Contact: Peter Rushforth, Maps for HTML CG co-chair
or via our public mailing list: public-maps4html@w3.org