This report outlines the use cases and requirements for standardizing modern Web maps, in a way that works for map content authors, webpage authors, and website users. The use cases and requirements were gathered in consultation with the Maps for HTML Community Group and others.

Three aspects of web maps are reviewed: map viewer widgets, client-side mapping APIs, and map data formats. For each, evidence is gathered from widely-used scripted JavaScript web map frameworks. The common features and limitations of the current techniques are the basis of the requirements for a standardized solution that could be built in to HTML and web browsers.

Comments, corrections, and suggested additions should be made as GitHub issues. If that is not possible, send an email comment to public-maps4html@w3.org.

Introduction

The current state of web maps

Web maps today are indispensable to billions of people, for exploring and understanding the world around them. Like paper maps before them, web maps are used for planning, wayfinding, analysis, and more. But the power of an interactive, hyperlinked medium supports a richer experience than could have been imagined by a cartographer from a previous century. Online maps can be dynamically redrawn with new data, or according to the user's preferences. They can connect to other maps — for adjacent areas, finer detail, or different geographical features — and can link out to complex information about the places they represent.

But despite their ubiquity on the web, maps have no native, semantic representation in HTML.

HTML has had “image maps” — hyperlinked graphics, where selecting different parts of the graphic triggers a different URL — from its early days. These were quickly adopted to represent simple cartographic maps. The <MAP> element sounds like it should be the basis of a web map, but its basic functionality (to define geometric areas on an image that represent distinct hyperlinks) has not evolved to include what users today consider a standard web map (such as those provided by Google, Bing, or OpenStreetMap).

Web mapping technology has undergone a long period of evolution. Today's web maps are usually sophisticated client-server applications, dynamically combining many types of spatial data on demand for web users. Implementations vary widely, but some of the underlying techniques, software, semantics and formats have become accepted patterns (for example, the tile naming systems), or formal standards (for example, the standards published by the Open Geospatial Consortium, some of which are also ISO standards).

Many sources of spatial data are available online, from governments, commercial services, and non-profit projects. But accessing and using the data is a specialized task; most web developers or website content creators rely on JavaScript frameworks (or sometimes still Flash frameworks) that can fetch the correct map image tiles or vector data, draw them to the screen, and handle the most common user interactions.

Many of these web map frameworks are tied to a specific commercial provider of map data, making it difficult for website creators to integrate their own data, or data from multiple sources. Many of the web map frameworks do not work at all without JavaScript, and require considerable resource downloads and processing. The end user has limited control or customization over the map interface — unless the website author happened to choose the web map provider that matches the native mapping application on the end-user's device.

Web maps today may not be perfect, but they have filled a clear need for website authors and users. The multiple frameworks used to generate web maps implement the same capabilities with different code — code that needs to be downloaded and processed for each website with a map in it. These core aspects of Web maps represent mature, ubiquitous user interface (UI) and application programming interface (API) patterns. It is now reasonable to consider standardizing these capabilities for implementation by web browsers directly.

A key challenge is to do so in a way that is compatible with the core values of the open web, and integrated with other web platform technologies.

The Maps for HTML Community Group

The Maps For HTML Community Group (Maps4HTML) 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.

The group operates within the structure of a W3C community group, with clear license terms for contributions of intellectual property. The community group process designed to support the eventual transition of the group's work to become open web standards. The group attempts to follow the established best practices for web standard development, as outlined in the guiding principles for this report.

The initial requirements sketched out at LGD2014 were expanded into an initial use cases and requirements summary. That work was the basis of the draft [[[MapML]]] specification and [[[HTML-map-element]]] proposal. Although MapML has had notable support and development efforts from within the geospatial community, as of early 2019 it has not received significant support from web browser developers or HTML standards teams. For that reason, the current document rolls back the focus to the discussion of mapping use cases and requirements. The structure of this report is intended to more comprehensively explain why native HTML web maps would be beneficial, and how they should best be defined.

This report is a work in progress! Feedback and contributions are welcome. To make substantive contributions (that is, anything that is bigger than typo corrections or formatting fixes), you will need to first become a member of the community group and make the corresponding IP commitments.

Structure of this report

The purpose of this report is to describe (1) why and how the open web would benefit from having web map features built in to web browsers, and (2) what this native web mapping function should look like, to website creators and to end users.

This report uses an empirical approach to identify required features of web maps, by looking for the common features of web map frameworks used today. However, we also recognize that web maps today have limitiations. A proposal for a native HTML web map, built in to web browsers, needs to be assessed on the same merits as any other proposed web standard.

In , we outline the theoretical factors we use for assessing whether a given feature should be included as a requirement. In , we introduce the web map frameworks that are used in the empirical review.

The review of potential requirements is then divided into three parts:

Within each part, we identify potential use cases: problems that a website author or user wants a web map to solve. The use cases are defined in pragmatic terms, describing a specific function or action. Real-world, domain-specific applications of the use case are summarized in an introductory description.

For each use case, we then list capabilities: features, which a web map might include, that could help solve the use case. Capabilities are potential requirements for a native HTML web map. To assess whether the capability should be a requirement, we examine:

Existing implementations
How common is this capability in the reviewed JS web map frameworks? Do they implement it with consistent, well-established patterns? Are there any notable limitations of the current implementations, when measured against the principles of the inclusive web?
Uses beyond mapping
Is there a demand for this capability on the web, beyond its use in web mapping?
Related web specifications
How is this capability related to existing web standards or proposed specifications? Can the web map implementation build on existing features?

For each capability, we conclude by summarizing its costs and potential benefits (using tags defined in the next section) for integration as a native HTML web map feature. We assign it one of three possible conclusions:

requirement
The capability is essential for a native HTML web map implementation.
enhancement
The capability would be nice to have in native HTML web maps, but isn't necessary for the initial specification.
impractical
The capability isn't currently realistic for inclusion in native HTML web maps.

If there is not yet enough evidence for a conclusion, the capability will be marked undecided.

Guiding Principles

The structure of this review is inspired by many other projects that have outlined best practices for web standards developments. This section briefly outlines the principles behind our approach, with links to further reading.

The extensible web

The report uses an evidence-based approach, defining requirements not based on hypothetical use cases but on web map tools that are already in use. We assume that the common features of existing, widely-used web map frameworks represent core functionality that web users and website authors expect from native web maps.

This approach is inspired by [[[EXTENSIBLE]]] which aims to “tighten the feedback loop between the editors of web standards and web developers,” establishing “a clear path for good ideas by web developers to become part of the infrastructure of the web” [[EXTENSIBLE]].

Much of the manifesto focuses on making it easier for developers to experiment with new features — to expose web platform capabilities at a more granular level, so that developers can remix and extend them to try out new ideas. HTML custom elements and CSS custom properties are just two of many examples of how web standards efforts since 2012 have focused on creating better building blocks for web developers.

But the implicit second step of the extensible web approach is that, once a consensus has developed from real-world experience with particular features or patterns on the web, those features can be standardized with confidence.

Web maps are extremely complex user interfaces. If that complexity is to be built-in to web browsers, the extensible web mindset requires that it be exposed to developers as individual capabilities that can be remixed and extended. For that reason, this review breaks web map functionality into very low-level capabilities. In addition to describing how each capability is used in mapping, we discuss how the same building block could be used for other web content. Focusing on these low-level capabilities also ensures that we do not overlook important details, such as the need to make individual interactions accessible to all users.

Priorities for web standards

To decide whether a capability should or shouldn't be considered a requirement for web maps, we need to assess its benefits and costs. But benefits and costs are subjective: to calculate them, we need a set of values or principles defining best practices for web standards. Only then can we assess whether integrating a feature into web browsers can bring the web closer to our ideals.

Benefits and costs are also different from different perspectives. Integrating web maps into HTML means convincing other web standard editors and web browser developers. But once a web standard is adopted, the number of website authors who use it will (hopefully) be much larger than the number of people who worked on the initial standard; the number of people who use those websites will be larger still. The [[[html-design-principles]]] rely on these numbers to establish a “priority of constituencies”:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. … Of course, it is preferred to make things better for multiple constituencies at once. [[html-design-principles]]

This section introduces the categories by which we measure costs and benefits to each of these constituencies.

Users

An inclusive web is available to everyone, to connect and create in the ways most comfortable to them.

In this report, the user-friendliness of a potential web map feature is assessed on these points:

privacy & security

Can this feature be implemented in a privacy-respecting manner? Are there any other security concerns from this feature? Would making it a built-in feature, standardized in web browsers, improve privacy & security compared to current web practice?

Tags for the costs and benefits of potential requirements:

  • Privacy: potential improvement indicates that a built-in browser implementation of this feature, if done correctly, could improve the protection of the end user's privacy, compared to current practices on the web.
  • Privacy: potential improvement for website origin isolation indicates that a built-in browser implementation of this capability, if done correctly, could make it easier for website authors to use web maps without exposing confidential (user or corporate) data to third parties.
  • Security: potential improvement indicates that a built-in browser implementation of this capability, if done correctly, could improve the protection of the security of the browser environment, compared to current practices.
  • Privacy: involves personal data indicates that in order to fully implement this capability, the browser would have access to sensitive or personally-identifying data about the user, which would need to be protected.
  • Privacy: possible fingerprinting indicates that implementing this capability would expose to website code user settings or data from device sensors, which could make it easier for website trackers to generate a unique “fingerprint” for identifying that user across many sites.
  • Privacy: reveals sensitive data indicates that fully implementing this capability requires revealing sensitive or personally-identifying data to website code.
  • Security: user interface override indicates that this capability allows website code to alter the normal browser UI in a way that could be used by a malicious code to mislead users.
  • Security: other risks indicates that this capability includes other aspects that could make a secure implementation difficult.

Further information:

accessibility

Does including this capability in a web map standard make it easier to ensure an accessible experience (assuming an accessibility-focused browser implementation)?

Related tags:

  • Accessibility: potential improvement indicates that a built-in browser implementation of this feature, if done correctly, could improve the accessibility compared to current practices on the web.
  • Accessibility: research needed indicates that there is not a clear best practice for how to implement this capability accessibly.
  • Accessibility: needs author-provided context indicates that a good browser implementation is not enough to make this capability fully accessible; content author would always need to provide extra information (e.g., alternative text or captions).

Further information:

internationalization & localization

Can this feature be implemented in a manner that works for all languages and regions? Does building it into the browser increase the likelihood that internationalization is done correctly?

Related tags:

  • Internationalization: potential improvement (languages) indicates that a native browser implementation, if done correctly, could improve the handling of text in many languages, compared to current practices in web maps.
  • Internationalization: potential improvement (spatial data) indicates that a native browser implementation, if done correctly, could improve the ability of web maps (compared to current practices) to work in many regions with different ways of describing locations and other spatial data.
  • Internationalization: UI localization required indicates that a correct implementation of this feature would need to include translations or other localizations (e.g., different icons or layout).
  • Internationalization: regional standards indicates that the standard UI patterns or data formats vary by geographic region.
  • Internationalization: difficult to do well indicates that the capability involves other aspects that are frequent sources of internationalization and localization errors.
  • Internationalization: unstable data indicates that a correct implementation depends on information that may change over time , and would need to be updated by the browser.

Further information:

performance & cost to users

Would building in this feature significantly reduce the amount of data downloaded to the user device, or the amount of custom code that needs to run? Or would it impose heavy computation demands on the user device?

Related tags:

  • Performance: data savings indicates that making this a browser feature could reduce data demands on the user's network. Of course, nearly any built-in capability will create some data savings compared to downloading JavaScript to achieve the same effect; this tag is only used when the potential data savings are particularly notable.
  • Performance: potential optimization indicates that a native browser implementation could be much more efficient in its computation requirements, compared to JavaScript tools.
  • Performance: high cost feature indicates that this feature involves high performance costs, regardless of whether it is defined in browser code or in JavaScript.

Further information:

  • Need references regarding performance considerations for spec developers.

Authors

Website authors include developers who write code and writers, designers, and other creators of web content. When discussing web maps, website authors also include geospatial experts who create map data and want to publish it on the web.

For an author that cares about their user, it of course helps if there are native implementations of author-focused features like accessibility. But there are other ways a good web standard can make the author's job easier:

simplicity & flexibility

For an author, a good web standard should make it easy to create common web patterns, while still making it possible to create unique and customized experiences.

Related tags:

  • Author experience: simple defaults indicates that the capability would greatly simplify authoring common use cases.
  • Author experience: extensible indicates that the capability provides an important hook for extending the basic web map experience.
  • Author experience: customizable design indicates that the capability is needed to allow authors to customize the appearance of web maps to better integrate with their site design (while still using other web map capabilities).
maintainability & cost to authors

Do current implementations of the feature rely on third-party services which may change in ways that could break website content? Do they involve ongoing costs that could be mitigated by a native version of the feature?

Related tags:

  • Author maintainability: removes dependencies on third-party services indicates that current implementations cannot be fully self-hosted by the website, creating a third-party dependency that could be removed with a native HTML capability.
  • Author maintainability: cost savings indicates that current web map implementations of the feature have ongoing service costs which could be mitigated by integrating with native platform versions of the feature.
consistency & coordination with the existing web platform

Can this feature be defined in a way that integrates well with the rest of the web? Does it reuse API and markup patterns that authors already know? Can it be added to websites in a way that degrades gracefully in unsupporting web browsers?

Related tags:

  • Consistency: established patterns indicates that this capability can be modelled after an existing concept or pattern in the web platform.
  • Consistency: progressive enhancement indicates that this capability could be included in websites as an optional enhancement of existing functionality.
  • Consistency: fallbacks possible indicates that this capability could be designed to support degradation to a fallback state (with corresponding loss of function or extra costs).
  • Consistency: platform is inconsistent indicates that it will be difficult to make this feature consistent with the web platform, because existing platform features are inconsistent with each other.
  • Consistency: breaks established patterns indicates that the feature would be clearly inconsistent with other aspects of the web platform.

Further information for all authoring & API design considerations:

Implementers

Implementers, for a web standard, are the people who build and maintain web browsers and other user agent software. Because much of the work of a web browser is to work as the user's agent, features that are good for the user when it comes to security or performance are also good for implementers. But some implementer benefits aren't directly exposed to the user:

ease of implementation

An implementation that already exists is always easier. Could this feature reuse code that is already available to the browser?

Related tags:

  • Implementation: Extends web platform indicates that this capability is an incremental extension of existing web platform features, and could be designed to reuse a lot of existing code.
  • Implementation: Exposes native platform indicates that, while this capability is not currently available in the web platform, it exists in native application frameworks supported by the major operating systems. A web browser could expose the native feature instead of re-implementing it from scratch.

Reviewed JavaScript Tools

Numerous options currently exist for a website author who wants to include a map viewer in a web page, with a minimum of custom code. The examples reviewed in this section are used to identify the common features (and limitations) of web map viewers.

Many major commercial providers of web map data tiles provide ready-to-use map viewer widgets for websites to use. In addition, multiple open source JavaScript libraries have developed to make it easier for website authors to build on other map data services.

Need data on the frequency of use of the different JS tools. has numbers, but no methodology.

The reviewed implementations come in three forms:

With these different structures, comparisons are not always exact. Similar functionality may be generated from very different APIs. We assess first whether a given capability is present in each implementation, and second whether there are common patterns in how that capability is exposed.

For each capability (potential web map feature) that we review, we assign one of the following implementation levels to each of the reference tools:

full support
The capability is implemented in a correct and comprehensive manner.
supported, with limitations
The feature is implemented, but there are notable limitations when assessing the implementation against our priorities.
partial support
Some parts of the feature are implemented.
no support
The capability could theoretically exist in the tool, but isn't included.
not applicable
The capability doesn't make sense for this tool, because of other aspects of its design.

Compiling and serving map data is a complex, expensive enterprise. Many of the map data and search services require registered developer accounts, with usage-based pricing. This review focuses on features that are free-to-use for website creators, at least for low-traffic websites, or that use data which is available from many interchangeable sources. However, because of the complexities of pricing models used by some services, we don't strictly exclude paid features from our assessment of support.

Google Maps embeds and Google Maps Platform API

By far the most frequently used map widget on the web,[citation needed] Google Maps established many of the de facto standards in how a web map works.

Customized iframe embed URLs can be generated from the maps website (search/customize the view and then select "share"), or by constructing the URL query string yourself (a developer API key and account is required).

The Google Maps Platform includes a JavaScript API for generating map viewers and adding custom features and data layers. It also includes methods to access more complex search functions, local images, and other data. Most features require an API key and usage is billed per page view.

OpenStreetMap embeds

Bing Maps embeds

MapKit JS (Apple Maps) API

Leaflet.js API

Leaflet is a popular JavaScript framework for building customized map views. It doesn't currently have a declarative API, but widgets similar to map embeds can be generated with a few calls to the library methods.

Leaflet isn't associated with any particular map data source. It can use image tiles from most web map (tile) services.

This review is based on the version 1.4.0 API docs.

OpenLayers API

Map Viewer Widgets

The map viewer widget is the interactive component that displays a map to end users. The map might be the primary purpose of a website, or a small embedded element in a larger HTML page.

For this section of the review, we focus only on aspects of the map viewer that are generated by the map widget framework based on initial configuration and data by the website developers. In other words, these are the features that could be represented by elements and attributes in a native HTML solution. The next section, on client-side APIs, covers custom JavaScript manipulation and event handling for the map view.

Use case: Display an interactive map

This is an abstract use case: it covers all the generic features that are common to map widgets, ignoring the details about how the map location or specific geographic features specified.

For this section, we simply assume the browser can convert the map data into images on screen. The potential requirements in this section describe ways in which map viewers enhance the normal experience of viewing a static image (e.g., img element) in a web page.

See examples of default map viewers as implemented by the reference JavaScript tools.

Capability: Display a default map for a given area

Often, the website author does not want to specify the map data source or other details about the map; they just want a generic wayfinding map of the area.

Existing implementations

The embeds and commerical APIs all provide default street maps without the author needing to specify the map source. In contast, the more flexible APIs must be combined with an separate map provider (e.g., OpenStreetMap).

google-maps-embed
google-maps-api
openstreetmap-embed
full support: this is the basic function for these widgets: give it a location, it will draw the map.
leaflet-api
open-layers-api
no support: must be combined with a separate map provider.
Uses beyond mapping

No non-map uses for generating a default street map. But, there may be interest in displaying default maps as static images in addition to using them within map widgets.

Related web specifications

Conclusion

This functionality is a highly valuable enhancement for native web maps, especially if it could be built on native platform features that allow the users to download maps in advance for later use. However, if user agents cannot integrate with a native operating system feature, they would need to rely on a third-party service for the map data.

Capability: Pan the map display

A key part of the interactivity of a web map widget is that the user can change the region displayed. To pan the map is to shifting the view horizontally or vertically, so a different location is centered in the map display.

For mapping, panning is tightly linked with zooming and with dynamic loading of new content. For this discussion, we've divided them into separate features so that the costs, benefits, and non-mapping use cases can be assessed separately.

Existing implementations

The following UI is standard among the reviewed map viewers:

  • Drag the map view by clicking and holding a mouse.
  • Swipe the map view with touch gestures.

The following UI is available in some viewers, but not all:

  • Pan the map view with arrow keys.

None (?) of the map viewers show a visible indication of keyboard focus for panning, or any other affordances to indicate how keyboard panning should work.

openstreetmap-embed
supported, with limitations: Mouse, touch (?), and keyboard panning; no keyboard focus indication
google-maps-embed
google-maps-api
partial support: Mouse and touch panning only.
Uses beyond mapping

The standard panning interactions are also common on the web for other JS-enhanced zoom and pan graphics (e.g., a close up of a product photograph, a data chart). Similar interactions may be used in some games, or in navigation of large spreadsheets. Creating a native way to trigger panning within a web layout could help ensure consistent, accessible user experiences for panning.

Related web specifications

From a rendering perspective, panning a map is very similar to scrolling a section of a CSS layout. Important differences:

  • Although 2D scrolling is supported, the interaction usually emphasizes a primary reading axis. Panning is usually 2D, and may be conceptually diagonal as often as horizontal or vertical.
  • The initial scroller view is usually at the start of the content (and “start” has meaning); an initially panning view is often in the middle, with panning in all directions possible.
  • Scrollable content is often visually indicated by scrollbars (although it is now common to hide scrollbars until use).
  • The user interactions are different for some input methods: mouse panning uses click and drag instead of mouse wheel for (primary-direction) scroll, keyboard panning only uses the arrows, not the space bar and page up/down keys (which trigger scroll in the primary axis).

Panning interactions also overlap with the proposed CSS spatial navigation spec.

In web maps and many other applications, panning effects are combined with zoom effects; for that reason, panning is often implemented using CSS transforms or SVG viewBox, which can also handle zoom. [[css-transforms-1]][[SVG2]]

Conclusion

Panning the map is universally supported in JS web maps, and is therefore a requirement for native web maps. The relevant specification should be coordinated with CSS, considering other use cases for panning on the web. Thought is needed on how to make panning accessible to all users.

Capability: Zoom the map independently from the rest of the page

In addition to panning the view, it is standard to allow the user to adjust the map scale: zooming in to increase magnifaction (show finer detail), zooming out to decrease magnification (show a wider area).

Existing implementations

The following UI is standard across the reviewed map widgets:

  • Accessible buttons labelled with plus (+) and minus (-) signs zoom by steps.
  • Mouse wheel movements (usually used to scroll the page) are captured and converted into continuous zoom adjustments (mouse scroll down becomes zoom in, mouse scroll up becomes zoom out).
  • Touch gestures for pinch zoom are used to zoom the map instead of the page.
google-maps-embed
google-maps-api
openstreetmap-embed
full support: (as described above)
Uses beyond mapping

Localized zooming is used on the web for charts and diagrams, photographs (e.g., to examine details in a product photo, or for photo editing apps), embedded documents (e.g., a PDF viewer), and sometimes data tables.

Related web specifications

Zooms are often implemented using transforms, which defines the scale as a multiplicative factor compared to the normal size (scale(2) for doubling the size, zooming in; scale(0.5) to zoom out by the same amount). Scale transforms are paired with translations to create zoom and pan effects. [[css-transforms-1]]

An alternative approach for describing zoom and pan is used in SVG viewBox attribute and in spatial media fragments. In this system, the container element defines its own width and height (e.g., with CSS) plus a target rectangle in the zoomable graphic's coordinate system (x and y offset, plus width and height); the user agent then zooms and pans the graphic to display the target rectangle in the available space. [[SVG2]][[media-frags]]

Conclusion

This functionality is a requirement for modern web maps, with other uses in the web platform. A zoom specification will need to carefully consider all uses so it can be implemented consistently, and should be coordinated with panning.

  • To Do

Capability: Load additional map tiles when they pan into view

Capability: Wrap/duplicate data tiles when panning around the globe

Capability: Maintain reasonable scale of labels and lines when zooming

Zooming a map widget is different from magnifying a regular image, or adjusting the overall browser zoom level; the layout is magnified, but annotations such as text size and stroke width do not.

Capability: Dynamically load different resolution map tile on zoom

Capability: Hide or show (and maybe dynamically load) vector features and labels on zoom

Capability: Display map data attribution and links

Map data is subject to copyright, and use of the maps on the web usually requires at least attribution, and maybe links to terms of use. Many map services also include links for end users to report errors.

Standard practice in the reviewed web map tools is to display this attribution in the lower right of the map widget. For map viewers that provide their own map data, the links and copyright is automatically generated. For map frameworks that allow the developer to specify the map data source, these "attribution control" values can be set in configuration.

Use Case: Display a specific location on a map

For a website creator, this is the simplest web map use case: display a map from a description of a location.

This type of web map is used by websites for stores, restaurants, and countless other organizations with physical locations. It is also used by newsmedia to display the location described in an article. In social media and blogs, a single-location map can be used to show where a post was uploaded from, or where a photograph or video was taken.

See examples of single-location map viewers as implemented by the reference JavaScript tools.

Capability: Select map view from latitude and longitude point

Latitude and longitude defines a point on the Earth's surface, without requiring any further information. For website content, latitude and longitude data might come from photo or video metadata (from GPS-enabled cameras), or it might be calculated by the author using map search services. In a dynamic web app, latitude and longitude might be generated from geolocation on the user's device.

Existing implementations

All the reference tools allow the website author to display a specific location, defined by latitude and longitude, from a map tile set.

google-maps-embed
google-maps-api
openstreetmap-embed
leaflet-api
full support: setting a location by latitude and longitude is straightforward.
open-layers-api
supported, with limitations: A location defined with longitude and latitude must be converted to the map tile coordinate system, but the API provides the conversion function.
Uses beyond mapping

Related web specifications

The Geolocation API and Geolocation Sensor API expose the user's location using latitude and longitude data. It should be possible to set the view on a web map using data returned from these APIs. Both of these APIs use the [[[WGS84]]] as the technical definition of longitude and latitude (consistent with most modern geospatial standards), and a web map standard should use the same definition. [[geolocation-API]][[geolocation-sensor]][[WGS84]]

Conclusion

This functionality is a requirement for modern web maps.

Capability: Generate map automatically from street address or place name

For many mapping use cases, a website author won't have exact latitude and longitude values pre-calculated. They'll have street addresses or place names in a human-readable, localized format. To convert these addresses or names into a point on a web map, the web mapping service needs access to a Gazeteer search and corresponding databases.

Capability: Save the location or export to other application

For the user, it is often useful to bookmark or save a location from a map, separate from the website which included it. The user may want to export the location to a GPS or native mapping application so they can calculate directions to it.

Use Case: Display multiple features (locations, routes, or regions)

Use Case: Display custom HTML annotations for map features

Use Case: Display a map using data from a specified web map service

Use Case: Search or sort within a set of geographic features

Client-side Mapping APIs

Client-side Mapping APIs (application programming interfaces) allow website developers to create customized map viewers, or other geographic applications. Existing APIs are JavaScript libraries that offer ready-to-use functions for fetching or rendering parts of a map, or for manipulating a map-viewer widget. A built-in web map solution would need to expose similar DOM APIs to JavaScript code.

Use Case:

To Do

Map Data Formats for Map Viewers

Many different types of spatial data can be integrated in a web map: satellite imagery, cartographic representations of roads and terrain, 3D building profiles, pinpoint locations with annotated descriptions, route directions or other polyline paths, and more. Many standard and proprietary formats exist to describe this data.

A built-in web map viewer will need to work with spatial data that is already available from web servers, or that can be provided with minor server upgrades.

Use Case:

To Do

Summary of Requirements

To Do: finish the script to generate a summary table from the annotated markup.

Open Issues

We are tracking issues on Github.

Acknowledgments