This document is a Community Group Report draft intended to introduce the Hyper-Layering Architecture (HLA) as a topic of discussion within the Maps for HTML Community Group.
It is not a specification proposal, nor does it seek immediate standardization. Its primary purpose is to provide shared context, including the philosophical motivation, historical background, and references to existing implementations and materials related to HLA.
This report is published in the Maps for HTML Community Group following recent W3C discussions, where it was agreed that existing CG infrastructure provides an appropriate venue for architectural exploration related to maps on the Web.
This document is a Community Group Report draft intended to introduce the Hyper-Layering Architecture (HLA) as a topic of discussion within the Maps for HTML Community Group.
It is not a specification proposal, nor does it seek immediate standardization. Its purpose is to provide shared context: philosophical motivation, historical background, and references to existing implementations and materials.
This report is published in the Maps for HTML Community Group following recent W3C discussions, where it was agreed that existing CG infrastructure provides an appropriate venue for architectural exploration related to maps on the Web.
Motivation: Why HLA Matters to Maps for HTML
Web mapping has made remarkable progress over the last two decades.
However, much of this progress has occurred through centralized services, proprietary frameworks, and siloed web applications.
While these approaches enable rich functionality, they also weaken two foundational principles of the World Wide Web:
Avoiding centralization
User- and browser-centric interoperability
The Hyper-Layering Architecture (HLA) originates from a long-running attempt to reconcile maps with the original Web architecture: hyperlinks, distributed authorship, and integration performed by the user agent.
HLA asks a simple but far-reaching question relevant to the Maps for HTML CG:
Can maps on the Web be composed, combined, and reused with the same freedom as other Web resources—without relying on centralized aggregation services?
Core Idea of Hyper-Layering Architecture
At the conceptual core of HLA is the idea of "mapping the Web itself."
Rather than treating maps as isolated content within web pages,
HLA envisions the entire Web as a single, interconnected spatial canvas —
a "One Web Map" where all information and services can be connected through a common spatial context.
Illustration of the HLA concept: moving from maps inside the Web to envisioning the entire Web as a single interconnected spatial canvas — the 'One Web Map'.
At its core, HLA treats layers as first-class Web resources identified by URLs and combined dynamically by the browser.
This shift in perspective moves away from monolithic map applications toward a more granular and distributed model.
The key principles of this architecture are as follows:
No mandatory aggregation server: Integration does not require a central backend; instead, the integration happens directly on the client side.
Loose coupling by hyperlinks: Layers are referenced via URLs rather than being physically copied or merged into a single database, allowing for flexible updates.
User agent as integrator: The browser (user agent) takes on the role of the primary engine that performs composition and rendering of the multiple layers.
Distributed ownership: Each layer remains under the control and authority of its original publisher, preserving data sovereignty.
This approach directly inherits the original World Wide Web model—hyperlinks + user-agent integration—and applies it systematically to geospatial content.
Illustration summarizing the key principles of HLA: client-side integration, loose coupling via URLs, and distributed ownership.
Note:
The discussion in this section is based on the first half of Slide 1 from the materials prepared for the HLA breakout session at TPAC 2025. [[HLA-TPAC2025]]
Historical Background
Origin (1996)
The original concept of hyper-layering was conceived in 1996, following discussions on disaster information sharing after the Great Hanshin–Awaji Earthquake.
The inability to freely overlay heterogeneous disaster-related maps from different organizations revealed a structural interoperability problem that could not be solved by existing centralized GIS models.
Early Standardization Attempts (2000–2011)
From the early 2000s, HLA development focused on SVG-based mapping, anticipating SVG as a browser-native, interoperable map format.
Key milestones during this period include:
Participation in the W3C SVG Working Group (early 2000s; rejoined formally in 2007).
Establishment of the Japanese Industrial Standard: JIS X 7197 (SVGMap) [[JIS-X-7197]] .
W3C Member Submission (2011): SVG-based Tiled Layers and Mapping [[HLA-SVGT]].
Traces of this work remain visible in SVG specifications today, including geographic coordinate handling in SVG 1.1 [[SVG11-GEOR]] and SVG Tiny 1.2 [[SVGT12-GEOR]].
SVG 2 and Lessons Learned
During SVG 2 development, HLA-related requirements influenced features such as Vector Effects [[SVG2-VE]] , particularly for cartographic annotations and non-scaling symbols.
Despite this, browser-level standardization of a complete map architecture proved impractical at that time. This period clarified an important lesson for the community:
Over-specifying map formats inside a single standard does not scale with the diversity of the Web.
HLA 2.0: Layers as Web Apps (LaWA)
Architectural Shift
After the 2011 Great East Japan Earthquake, the limitations of centralized cloud-based map mashups became evident, particularly in their flexibility to handle diverse and rapidly changing data sources in crisis situations.
As a result, HLA evolved into HLA 2.0, also known as Layers as Web Apps (LaWA).
In the LaWA model:
Each layer is implemented as a small Web application using standard HTML, CSS, and JavaScript.
Encapsulation: Layer-specific logic, including user interfaces, parameters, and authentication, is encapsulated within each individual layer.
Shared Framework: A shared client-side framework (svgmap.js [[svgmap-js]]) provides a common geospatial canvas to integrate these independent applications.
Illustration summarizing the HLA 2.0 (LaWA) approach: each layer as an independent Web application integrated on the client side using a shared geospatial canvas.
Practical Results
The LaWA approach, powered by svgmap.js [[svgmap-js]] , has been rigorously tested and validated through extensive real-world application:
Integration of over 1,000 heterogeneous layers from various origins. [[HLA-DEMO]]
More than 15 years of internal operational use at KDDI Corporation.
Commercial deployment in disaster information systems started in October 2025.
While LaWA demonstrated that large-scale, heterogeneous map integration is entirely feasible without central aggregation, it also revealed scalability limits due to the implementation cost of developing and maintaining per-layer Web applications.
Note:
The concepts described in this section, including the evolution toward HLA 2.0, are presented in the second half of Slide 1 and in Slide 2 of the materials prepared for the HLA breakout session at TPAC 2025. [[HLA-TPAC2025]]
These slides elaborate on the architectural refinement and extended design considerations discussed with participants.
Relevance to Maps for HTML CG
From the perspective of the Maps for HTML Community Group charter, HLA fits naturally within the non-normative, exploratory scope of the CG.
HLA does not propose a new specification, syntax, or API. Instead, it contributes:
Architectural insights into how maps can align with core Web principles.
Historical experience with browser-centric, client-side map composition.
Concrete evidence that decentralized, cross-origin layer integration is feasible on the Web.
These contributions directly support the CG’s stated goals of understanding how maps relate to HTML, browsers, and the Web platform, without constraining the group to any particular declarative or imperative solution.
In this sense, HLA should be read as a context-setting architectural report, analogous to a white paper or use-case document, rather than as a proposal competing for adoption.
Its role is to inform discussion about what kinds of problems matter and which architectural trade-offs exist, leaving questions of concrete formats or specifications explicitly open.
By remaining within this charter-aligned role, HLA aims to enrich Maps for HTML CG discussions while respecting the group’s consensus-driven and exploratory mandate.
Purpose of This Report
This report is intended to:
Provide historical and philosophical context for HLA.
Clarify why decentralization and client-side composition matter.
Position HLA as a legitimate topic within Maps for HTML CG discussions.
It deliberately avoids proposing new specifications. Any future technical explorations will be discussed separately, in appropriate contexts.
It should also be explicitly noted that Hyper-Layering Architecture is not an abstract concept alone. HLA already has:
An articulated architectural specification developed over time.
Working, long-lived implementations, most notably the svgmap.js [[svgmap-js]] client framework.
Operational deployment experience that continues to inform its evolution.
At the same time, this report does not advocate bringing the HLA specification itself into the Community Group as a candidate for immediate standardization.
Questions of standardization—whether related to HLA, MapML, or other approaches—are better addressed through broader, open discussion involving browser vendors and diverse stakeholders, informed by practical experience rather than premature convergence.
References and Further Reading
The following resources provide additional technical details, historical documentation, and context for the Hyper-Layering Architecture:
