This document represents the use cases and requirements for standardizing a solution to enable modern Web maps for map content authors, HTML authors and users. The use cases and requirements were gathered in consultation with the Maps for HTML Community Group and others.
Some standards are crafted in isolation, and presented to the world as a fait accompli. Others arise through collaboration over mailing lists, like those favored by the IETF. There are many standards defining organizations, with different models of standards development. On the Web, the notion of community is almost ubiquitous: communities of interested parties and committed individuals have created and contributed incredible works for the benefit of the Web at large.
The path chosen for collaboration over Web maps is guided in part by the advice and experience of the W3C, who have created facilities for Web communities to collaborate in the open. The community groups listed below have also provided resources which have helped inform the current effort.
The Extensible Web Manifesto by the Extensible Web Community Group will be used as a guideline for how development should proceed for Web maps. In particular, one or more working prototypes will be developed using Custom Elements / Polymer, to demonstrate feasibility and examine ideas in a real context.
The Web Incubator Community Group has established a recommended path based on past experience to successfully influence the browser development community. For example, the experience of the Responsive Images Community Group to create the <picture> element is an established best practice. The work of the Maps For HTML Community Group will try to emulate that experience to the greatest extent possible.
The MicroXML Community Group has openly developed a simple declarative syntax whereby HTML-like document vocabularies can be developed. The syntax eliminates much of the legacy complexities of the XML syntax and data model, notably namespaces. Such a syntax lends itself to DOM-compatible parsing and CSS selectors in the browser.
The Maps For HTML Community Group arose as a result of face-to-face discussions at the Linking Geospatial Data workshop 2014, co-sponsored by the W3C and the Open Geospatial Consortium. Discussion of this and related documents should take place in the Maps4HTML or the Web Incubator Community Group, since it is in the CG context that clear license terms for contributions of intellectual property are in force.
The HTML Design Principles were created by the HTML Working Group, and should also be used to guide the development of these use cases, requirements and related specifications.
Web mapping sites have become an essential daily Web destination for millions of Web users. Web maps, like paper maps before them, have become indispensable to many human activities, across a wide spectrum of categories, including but not limited to: government, journalism, business, science, education, travel and leisure. The first iteration of image maps in HTML was intended to represent simple cartographic maps. Some techniques that were pioneered in those early HTML iterations remain in common Web map usage today. Despite the initial semantic of the <MAP> element, HTML did not continue to evolve to include what users today consider a standard Web map.
Web mapping technology has undergone a long period of evolution, starting before and giving rise to that first HTML <MAP> element. This has resulted in some very sophisticated client-server applications which serve maps to Web users. Implementations vary widely, and some of the underlying techniques, software, semantics and formats have become accepted patterns, de facto, and even de jure standards. Some of the techniques HTML authors are required to use in creating maps for the web include:
Semantics are an important quality of the Web, yet the elements which are used to create Web maps (typically <div>) are semantically neutral, and have no spatial meaning or explicit location. Web maps cannot therefore be progressively enhanced in the normal sense of the term. The spatial location of (elements in) a Web page could permit spatial indexing of Web content, yet modern Web maps fail to provide such content, making the Web pages they exist in spatially non-discoverable.
It is noteworthy that the existing semantics of the client side image map could be used as the base state of a progressively enhanced map that might provide basic map semantics and functions even in cases where the user is off line.
Instead of depending on the core values of the Web , Web maps depend in some cases, on standardized techniques which are incompatible with modern best practices. URL Templates somewhat alleviate this reliance, however they also effectively bypass the benefits of hypertext. Service providers are not free to control the domain of URL values in their own Web domains. A clever hack, or misguided standard, it is unclear which category URL recipes fall into, however taken as a whole, its broad application prevents spatial data and maps from scaling to Web scale.
Spatial data is a domain with an abundance of formats which cover a broad range of content. Yet few of those formats offer much in the way of support for URL-based links, and fewer still support the concepts of building the semantics of client-server interaction into the format specification. Those that do offer such interaction possibilities have service type-specific assumptions built in to them, and /or have other characteristics which limit their application in this problem space. While Web architecture standardizes certain client server mechanisms, the style of the Web depends on non-service specific application of those mechanisms, especially that of hypertext.
Off the Web, cartography is a demanding, science-oriented graphical design discipline. Many generations of sophisticated hardware and software and technologies have been invented to meet its challenging requirements. The results of the application of such technologies is often reflected in the form of images created explicitly for Web maps, without the need for recourse to styling of the underlying spatial features as HTML (or SVG) elements. Notwithstanding the importance of images for Web maps, geographic features are also important on the client side of the Web, since they provide the basis for user interaction with map information.
The prevailing wisdom on today's Web is to compile geographic features on the server to CSS-styled SVG for consumption by the browser.
The first problem with this approach is that despite its nature as a hypertext language, SVG has 2D vector graphics semantics and coordinate systems. Its elements relate to the graphics page, not to the Earth. Furthermore, by using CSS+SVG as a server side compilation target, Web map content authors are insulated from the standard techniques of the Web, a situation not unlike using a word processor to generate CSS+HTML. Finally, few server GIS technologies are built to leverage Web technologies such as CSS and SVG. This is likely due to the fact that XML as a base technology for GIS vectors on the server is unpopular and widely dismissed. In consequence, Web map content authors are unlikely to learn the techniques of CSS, SVG, and HTML.
In some situations, especially those where geographic features' shapes are used as link representations, it is desirable to style and interact with inherently geographic features as distinct from SVG vectors. It would be ideal if in those situations, Web map content authors could apply the techniques of CSS, SVG and HTML while reaping the benefits of maintaining geographic feature semantics and without sacrificing server performance due to inefficient server side formatting.
The lack of a virtuous cycle of feedback from cartography technologies to Web styling standards is an impediment to development of higher quality, more broadly applicable Web standards, and assures the continued development of custom symbolization techniques at the expense of shared standards.
The net effect of ceding Web maps to the aforementioned techniques is a Web which is ever more fragmented, yet ironically centralized, in regard to maps i.e. a Web which provides progressively fewer options for HTML authors and map content. Such a situation works against the goals of the Web itself, which is or was to provide a medium in which individuals might develop a shared understanding [TimBL] through hypertext Web pages, that are not necessarily official, nor top-down. The same goal should be shared by the Web of maps: to achieve a shared understanding of global spatial issues and phenomena, without undue deference to a central authority. To achieve this goal, it will be necessary to diminish and remove barriers to HTML Web map authors and content producers alike.
Modern Web maps deliver a user experience which provides animated, seamless zooming, panning and orientation of the map as though it was a globe i.e. with apparent physical momentum.
Often, interaction with Web maps is afforded by means of a pointing device, but importantly also with keyboard controls and other accessibility devices. Maps should be usable by persons with disabilities, such that a range of assistive technology may be used at a minimum for navigation, but potentially also to access and interact with the underlying data, if applicable.
Gazetteer-type search is a commonly standard function of Web maps, allowing the user to search for a place of interest, select the place from a suggestion and/or result list, and automatically zoom and pan the map to be centered over the place of interest upon selection.
Web maps should enable both within and inter-map linking, either to locations or features, using standard (opaque, not-necessarily-semantic) URLs. Links are an essential quality of the Web platform, and existing standard linking and navigation techniques should be embraced by Web maps. Related to Search and Search Suggestion Services use case, where the result of a textual search is presented as a link in a list of matching results. Also related to the Identify, Select, Edit, Post use case, and others.
Web users expect to interact with (select/touch/query/modify) appropriately styled vector features in the map i.e. driven by user and system events, without the feeling that there is something heavy about processing that information when compared with other visual information in the Web context. In other words, without necessarily realizing they are interacting with "vectors", that are in some way different than the fabric of the map they are interacting with, except perhaps by their style.
The HTML design principles are a useful guide for the specification of requirements.
The use cases give rise to the following requirements:
The Web maps solution(s) MUST support a declarative HTML syntax, and must allow the HTML author to provide fallback content for use on user agents that don't support the new feature
The Web maps solution(s) MUST support use of existing (Open Street Map-compatible) tile caches to provide a slippy map user experience
The Web maps solution(s) MUST support progressive enhancement via a scriptable DOM API
The Web maps solution(s) MUST enable Web map content authors to create content that is accessible to assistive technologies
The Web maps solution(s) MUST support declarative Web map content through CSS for styles and SVG for symbols
The Web maps solution(s) MUST support declarative vector content that follows standard data models for geometries and attributes (features)
The Web maps solution(s) MUST enable HTML authors to create content that is accessible to assistive technologies
The Web maps solution(s) MUST support links created by HTML authors, to create in-map pushpins, balloons, and standard links (behavior like <a>)
The Web maps solution(s) MUST enable mashups by HTML authors by leveraging opaque URLs to Web map content sources
The Web maps solution(s) MUST support links and link relations created by Web map content authors to support such functions as "identify", "select" and others, as well as links within and between maps on different origins
The Web maps solution(s) MUST support a default and a limited set of standard projections, accessed by declarative HTML syntax
The Web maps solution(s) MUST allow Web map content authors to advertise search links in Web map content
The Web maps solution(s) MUST support manual or automated HTML authoring, enabling sensible defaults for projection, zoom, and location
The Web maps solution(s) MUST support a special type of link for attribution / license term links
The Web maps solution(s) MUST NOT require service-specific nor service type-specific URLs
The Web maps solution(s) MUST support HTML authors to create / control Web map controls, except for license terms control which should be the domain of Web content authors
The Web maps controls solution(s) MUST support progressive enhancement via a scriptable DOM API
The Web maps solution(s) SHOULD be available in one or more Custom Elements-based implementations, so as to allow the best features to be selected for implementation by native browsers
To date, a set of projects put forth together embody a first iteration-type solution to the objective of adding Web maps to the HTML Web. The authors of these projects welcome other projects to address the use cases and requirements, or to contribute to these existing projects. The objective is to arrive at a set of technologies which are mature enough to incorporate in the HTML Web itself.
MapML is a MicroXML-based hypertext format for Web map content, including tiles, vectors, images, links and metadata.
A Java servlet for MapML. Once the feature set stabilizes and matures, it would be desirable to port the functionality to an Apache module and other Web servers.
The specification for extending the semantics of the HTML <map> element based on the Use Cases and Requirements for Standardizing Web Maps. The specification reflects what is implemented, and what is to be implemented in the next iteration of the HTML <map> Custom Element implementation.
A Polymer-based implementation of the HTML <web-map> Custom Element. The intention of the project is to demonstrate the features that are specified in the HTML <map> (Custom) Element specification, and to not allow the specification to get "too far out there" with respect to reality / the implementation. The project uses the MapML Leaflet Client internally. More than one such element implementation is possible and would be welcomed, although it would be optimal to collaborate on a single project.
We are tracking issues on Github.
The figure on Representational State Transfer is derived from Roy Fielding's thesis: Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.
Many thanks to: Benoît Chagnon and Yannick Blain for their review of this document.