Use Cases and Requirements for Standardizing Web Maps

6.1.1 Create, initialise, and display a map

This is the starting point for all API usage.

Existing implementations

Implementations differ in how much is expected of the developer wishing simply to initialise and display a map. Those APIs that are tightly bound to a single source of mapping data tend to provide a single method call with options for configuration, whereas APIs that are data-provider-agnostic at least require initialisation of data sources in addition.

Implementations also differ in the sources and types of mapping data they support. Tiled raster map layers, with additional support for vector layers to provide supplementary content such as routes, are widely supported. Some implementations also support rendering maps using tiled vector map layers or untiled vector data.

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

tomtom-sdk

full support: Google, Bing, MapKit and TomTom allow straightforward creation of a map with configuration options.

Leaflet, OpenLayers, and MapBox require explicit construction of objects defining the map layers and viewport, with sensible defaults for creation of, for example, a map showing OpenStreetMap tiles in a standard National Imagery and Mapping Agency Technical Report 8350.2, Third Edition projection. This provides added flexibility, at the expense of increasing the complexity of code that uses these libraries.

d3-geographies-api

supported, with limitations: The d3-geo module supports vector data in the form of either GeoJSON or TopoJSON. It renders this data to either an SVG or Canvas element. It requires the developer to implement support for interaction using other d3 modules, such as d3-zoom and d3-transition.

By utilising the d3-tile module, tiled raster data can be combined with vector map data.

Supported use cases

Uses beyond mapping

Leaflet, OpenLayers, and MapBox allow for the creation of layers displaying non-geographical raster tiles.

The HTML Standard specifies a number of aspects of elements that embed media in a web page and expose JavaScript APIs to enable interaction and dynamic configuration.

The DOM Standard provides interfaces for creating HTML elements, which are what these implementations are using under the hood.

Scalable Vector Graphics (SVG) 1.0 Specification provides interfaces for creating vector graphics. These are used as one of the available primary methods of rendering map data by d3-geo, and for rendering supplementary content by other implementations.

The GeoJSON Format defines a method for representing geographical data in JSON. This is one of the primary data formats supported by d3-geo and is also used by other implementations for representing additional content.

DOM Standard HTML Standard Scalable Vector Graphics (SVG) 1.0 Specification The GeoJSON Format

Conclusion

This functionality is a requirement for modern web maps. Incorporating this functionality of existing map libraries in HTML would benefit users by reducing download size and time to interactivity. Web developers would benefit from being able to program against a standard interface.

However, it is to be expected that a native HTML web map element would be constructed and initialised via existing DOM interfaces such as document.createElement and DOMElement.insertAdjacentHTML. Additional aspects of the map element's configuration might be achieved either through existing DOMElement interfaces such as setAttribute, or through element-specific attributes and methods; cf. the attributes and methods of the HTMLMediaElement.

• Accessibility: potential improvement A native implementation would be better able to incorporate a semantically meaningful representation of a map into its accessibility tree than current implementations, which depend on the accessibility features of more general native elements in conjunction with Accessible Rich Internet Applications (WAI-ARIA) 1.1.
• Performance: potential optimization A native implementation would be more efficient in avoiding the need to download code, in code execution, and potentially in avoiding the necessity of creating complex DOM structures to build the map's representation.
• Author experience: simple defaults At present, authors need to decide on an implementation to use and to learn how to use it. They may then be unwilling to switch to an alternative implementation for applications in which it would be more suitable. Knowledge of and experience with a standardised native implementation would be more widely applicable.
• Author maintainability: cost savings Although there are free implementations available, many authors make use of paid implementations whether through inertia or the desire for a paid support route. A native implementation would reduce the operating costs of paid map implementation providers, though they could continue to charge for other services such as tile servers and support, and those savings could (in an ideal world) be passed on to their customers.
• Consistency: fallbacks possible Existing implementations fail if JavaScript is disabled in the user's browser, or if connectivity failure prevents the necessary scripts being downloaded. A native implementation would be able to at least display an initial view of a map under such conditions, even if further enhancements intended by the author failed to be applied.

6.1.2 Add a marker or multiple markers to a map

Markers are discussed in more detail at § 5.2.1 Show pinpoint locations or custom markers on the map. The APIs provided for adding markers to a map generally allow a developer to use default icons or to specify their own, to specify a short label such as a letter or number to be displayed within a marker, and to attach annotations which are displayed when the marker is selected by the user.

Existing implementations

Existing implementation support:

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

full support:

These implementations all provide straightforward APIs for adding markers to locations using a default icon.

open-layers-api

supported, with limitations:

Rather than providing a straightforward API, OpenLayers requires a number of steps to be followed: providing icon imagery (as there is no default imagery provided), creating icon features, creating a map layer to hold those features, and finally adding the layer to a map. This is noticeably more complex than the APIs provided by a number of other implementations.

d3-geographies-api

partial support:

By default, d3-geo will render point features as circles. These can be styled using whatever techniques are being used to style the map content, typically either using presentational SVG attributes, or CSS. In practice, adding markers in a manner similar to that offered by other mapping APIs might best be achieved by dynamically creating a GeoJSON feature containing the point features in a FeatureCollection and adding this as an additional layer on the map.

Supported use cases

Uses beyond mapping

In cases where non-geographical data is being displayed, markers could indicate points of interest in the same way that they do on maps.

The GeoJSON Format defines a method for representing geographical data in JSON. This is one of the primary data formats supported by d3-geo and is also used by other implementations for representing additional content. For adding markers to a map, a GeoJSON FeatureCollection containing one or more points can be used.

The GeoJSON Format

Conclusion

This functionality is a requirement for modern web maps. Incorporating this functionality of existing map libraries in HTML would benefit users by reducing download size and time to interactivity. Web developers would benefit from being able to program against a standard interface.

• Accessibility: potential improvement Existing implementations vary widely in how they implement markers and annotations. This lack of consistency has the potential to lead to accessibility issues, as there may be no clear way for the information the marker is intended to denote to be accessed by assistive technologies. A native implementation could expose clearly-defined interfaces for accessing the meaning of the marker and the content of any related annotation.
• Accessibility: needs author-provided context Although a native implementation could make it easier to expose related content in annotations, it would still be incumbent on authors to ensure that such content was presented in well-structured HTML for assistive technologies to be able to make best use of it.
• Internationalization: potential improvement (spatial data) Assuming the fundamental content of a marker is its location, a native implementation would be able to present that in a form appropriate for a user's locale.
• Author experience: simple defaults A consistent interface for creating and showing markers and annotations would be advantageous compared to the widely-varying approaches used by existing implementations.
• Author experience: customizable design By providing suitable interfaces for specifying the appearance of markers and annotations, a native implementation could allow authors to ensure they were consistent with the overall design of their site.

6.1.3 Implement a custom control

Controls are user interface elements that enable interaction with the map. Map implementations typically provide a number of default controls supporting interactions such as zooming and switching layers.

A map implementation will typically provide the developer with various options for configuring controls. This will include such capabilities as adding and removing controls, showing or hiding them, and being notified of changes in their state. It is also necessary to provide support for controlling the positioning of controls, to avoid the situation where two controls occupy the same position on the map's UI.

Developers may wish to implement additional controls, either replacing the functionality of the map's default controls, or adding new functionality. Map implementations should provide APIs to support such custom controls, allowing them to integrate fully with the map at a level that is on a par with the map's own controls.

Existing implementations

Support for controls varies widely among existing map implementations. It is generally the developer's responsibility to create a suitable DOM construct, styled with CSS and augmented with JavaScript to provide behaviour, for use as a control. But though some implementations specify detailed APIs which controls should support in order to be properly integrated with the map, others provide minimal support and expect the developer to take full responsibility for responding to control lifecycle transitions.

mapbox-gl-api

leaflet-api

open-layers-api

tomtom-sdk

full support:

All of these implementations fully support the concept of controls, including support for control implementations to be notified when they are added to or removed from the map, so they can update their own internal state accordingly. They also allow controls to request their desired positioning within the map's UI, and will position controls using sensible defaults if developers choose not to implement that capability.

MapBoxGL specifies an interface to which controls are expected to conform. The map API provides methods for adding and removing controls to and from the map UI.

Leaflet, TomTom (which uses Leaflet), and OpenLayers provide base classes which controls extend, along with map methods for adding and removing controls. OpenLayers also exposes its control collection directly.

google-maps-api

supported, with limitations:

While Google Maps supports the adding and removing of controls and the specifying of their placement within a number of predefined areas within the map's UI, there is no specific interface to which they are expected to conform.

bing-maps-api

partial support:

Bing Maps expects controls to be implemented as a type of overlay. It provides no particular support for controls beyond that, not even for positioning them within the map UI, which is left to the developer to achieve using CSS positioning.

apple-mapkit-js-api

no supporta>:

Apple MapkitJS does not provide an interface that can be implemented to create a custom control, nor does it have any generic mechanism for adding and removing controls beyond those provided.

d3-geographies-api

not applicable:

Although d3 supports a variety of user interactions, the concept of a user interface presenting a collection of controls to the user is not part of the library.

Supported use cases

Uses beyond mapping

As controls are explicitly intended as part of the map's user interface, further uses for the concept might be found in other cases where complex interactive content is presented by an element, such as adding controls to media containers.

Conclusion

It might seem that, as controls are implemented using existing interactive HTML elements, there is no pressing need for them to be supported by additional APIs. However, the need for them to be closely integrated with a map's own UI, state, and lifecycle suggests that this functionality is a requirement for modern web maps.

6.1.4 Add a layer to a map

Adding a layer to a map viewer is a fundamental capability, as without it the base layer itself could not be added to the viewer. While map viewer implementations from a provider of mapping data can be expected to automatically add a base layer showing the data they provide, other implementations require a base layer to be explicitly created and added to the map as part of its initial configuration.

Adding further map layers other than the base layer allows additional information to be presented to the user in geographical context.

Existing implementations

All of the reviewed APIs support the creation of alternative base layers for the map, and the addition of layers to the base map. Both raster and vector layers are supported.

bing-maps-api

leaflet-api

open-layers-api

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

tomtom-sdk

d3-geographies-api

full support:

The implementations from mapping data providers generally require additional configuration to be specified in the case where an alternative base layer that does not use their data is provided.

Supported use cases

Uses beyond mapping

As a map viewer provides the ability to pan and zoom imagery covering a large extent, there are many alternative uses. Some examples include works of art that have been digitised at ultra high resolution, allowing anyone to examine them in fine detail, and ultra high resolution panoramic photographs.

Conclusion

Based on the fundamental nature of this capability, it is a requirement for web map APIs. In addition to providing basic and extended capabilites for the display of geographic data, it also allows the repurposing of such APIs for wider application.

• Author experience: extensible This capability promotes extensibility by allowing authors to incorporate additional or alternative data into a map.
• Author experience: customizable design This capability allows for customization of both base maps and additional data presented on the map, thereby giving authors flexibility to customize the appearance of maps to suit the design of the site on which the map is displayed.

6.1.5 Define a data source for a tile layer

Existing commercial implementations will generally show map data from a preconfigured source, while open-source implementations will either provide or document an initial configuration using open map data. But many applications require the use of alternative sources of map data, and it is therefore necessary that a map implementation provide suitable APIs for the configuration of such sources.

Configuring alternative data sources is also necessary to support the display of non-geographic tiled imagery.

Existing implementations

Existing implementation support:

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

tomtom-sdk

d3-geographies-api

full support:

All implementations support the creation of a layer with a specified data source that conforms to an OWS standard. This requires specifying a way for the layer to access the data source, which is achieved by specifying which OWS protocol to use along with a URL template. Some implementations support the use of a URL template function to return the required tile URLs when invoked with arguments specifying the geographical position and extent the required tile should represent.

Supported use cases

Uses beyond mapping

All uses of map implementations to display non-geographical imagery require this capability.

Conclusion

Based on the fundamental nature of this capability, it is a requirement for web map APIs. In addition to allowing for the display of alternative geographic data, it also allows the repurposing of such APIs for wider application.

6.1.6 Create an overlay defined by vector data

Description to follow

Existing implementations

Existing implementation support:

leaflet-api

open-layers-api

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

d3-geographies-api

full support:

All of the API-based map viewer implementations support the use of vector data defined in a number of standard formats, such as GeoJSON and KML. When topogeographical data is available that is not already in one of the widely-supported formats, application developers can readily convert that data into object structures that can be utilised by the existing APIs, such as the structure of a GeoJSON object.

Supported use cases

Uses beyond mapping

ToDo

Conclusion

This functionality is a requirement for modern web maps, as there are numerous sources of such data. Furthermore, vector data allows a level of precision higher than that achievable with raster data, or that it may not be convenient or possible to present in the form of rasters.

• Author experience: simple defaults: existing implementations mostly allow vector data to be incorporated into a map view with a single method call, making it easy for web authors to utilise such data.
• Author experience: customizable design: the styling of vector data is in the hands of authors, allowing them to easily match it to the design of the containing site.
• Author experience: extensible: this capability allows authors to incorporate high precision data representations over a base map.
• Consistency: progressive enhancement: vector data can be incorporated into an HTML document as a list, table, microformat metadata, or similar structured content. The data can then be extracted by a script, formed into a suitable object structure (such as GeoJSON), and rendered on the map.

6.1.7 Create an overlay defined by heatmap data

Point intensity data is a useful way of representing the distribution of a phenomenon across geographical areas. Examples include frequency of earthquake occurrence in different regions, the distribution of types of vegetation found in an area, or the spread of a global pandemic at a particular point in time.

It is possible to preprocess such data into a raster or vector format for display, but giving a map implementation the capability of rendering such data into an overlay directly averts such problems as maintaining consistency between multiple representations of the same data. Implementations will commonly accept point intensity data defined in a number of standard vector data formats, such as KML or GeoJSON.

Existing implementations

Existing implementation support:

google-maps-api

mapbox-gl-api

open-layers-api

full support:

All of these implementations support the display of point intensity data as a heatmap. In the case of Google Maps, it is necessary to specify the inclusion of support declaratively when loading the script library. Typically, a vector data source object is defined in JavaScript either by specifying the URL of a resource or by specifying the data directly in code.

bing-maps-api

leaflet-api

tomtom-sdk

d3-geographies-api

partial support:

Bing Maps has native support for heatmaps via a separate module that must be explicitly loaded in JavaScript, rather than being specified declaratively in HTML. Leaflet (and by extension TomTom) and d3 have third-party plugins available which add support.

apple-mapkit-js-api

not applicable:

MapKit JS does not support a heatmap overlay at present, and no third-party plugins adding support are known of.

Supported use cases

Uses beyond mapping

Heatmaps have existing applications unrelated to geography in a number of fields. For example, they are used in molecular biology for such purposes as visualizing gene expression. An implementation capable of displaying non-geographic point intensity data would therefore have potential value in the display of such data on the web.

Conclusion

This functionality could be added to enhance native web maps in the future.

• Accessibility: potential improvement Existing implementations only allow access to the underlying data represented by a heatmap if the author explicitly provides it, for example by also including the source data in an HTML table. A native implementation has the potential to improve access to the data. Furthermore, the choice of colours used in the heatmap may present problems for users with visual impairments. A native implementation could expose controls to allow users to select an alternative palette, such as a high-contrast version.
• Performance: potential optimization Rendering a heatmap from data can be computationally expensive, and it may be possible for a native implementation to achieve greater efficiency.

6.1.8 Control which layers are included in a map

Description to follow

Existing implementations

Existing implementation support:

leaflet-api

open-layers-api

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

tomtom-sdk

d3-geographies-api

full support: All of these implementations allow hiding and showing a layer on a map.

Supported use cases

Uses beyond mapping

ToDo

Conclusion

Based on the limited data, we are undecided about whether this should be a requirement.

6.1.9 Specify the style of a map

Description to follow

Existing implementations

Existing implementation support:

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

d3-geographies-api

not applicable:

Supported use cases

Uses beyond mapping

ToDo

Conclusion

Based on the limited data, we are undecided about whether this should be a requirement.

6.1.10 Determine the current style of a map

Description to follow

Existing implementations

Existing implementation support:

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

d3-geographies-api

not applicable:

Supported use cases

Uses beyond mapping

ToDo

Conclusion

Based on the limited data, we are undecided about whether this should be a requirement.

6.2.1 Get the bounds of a map

Description to follow

Existing implementations

Existing implementation support:

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

d3-geographies-api

full support:

Supported use cases

Uses beyond mapping

ToDo

Conclusion

Based on the limited data, we are undecided about whether this should be a requirement.

6.2.2 Pan, zoom, or re-centre a map

Developers expect to be able to control a map by changing its centre and/or zoom level, and may also wish to support the capability of resetting a map to its view as originally presented. If the map view cannot be dynamically modified by an application, as opposed to changes by direct user interaction with the map, then it offers fewer advantages over a static map view.

It is usually also desirable that such changes can be accomplished in a manner that gives sufficient visual feedback to the user that a change is occurring, for example by animating the transition rather than simply redrawing the map with the new view, which may not be immediately noticeable to the user.

Accessibility is an important consideration when the state of a map is altered dynamically. Thought should be given to how the change can be made known to assistive technologies so that the user is fully informed and thus cognisant of the current state of the map at all times.

Existing implementations

All the reviewed JavaScript API implementations support changing the bounds, centre, and zoom level of a map, and allow such transitions to be animated.

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

d3-geographies-api

full support:

Animated transitions are supported by calling specific methods with names such as flyTo or via a Boolean parameter to a more general method such as setView.

Supported use cases

Uses beyond mapping

This capability would be relevant to use of web map technology for the display of non-geographic imagery, such as navigating the view to relevant parts of a complex diagram as the user progresses through related content.

[css-overflow] Consider adding new CSS primitive for per-element panning and zooming (for web maps) #5275

Conclusion

As this is capability is required for any dynamic update of a map view such as would be expected of a map-based application, it is a requirement for embedded web maps.

• Privacy: potential improvement As there is the potential for third-party scripts to observe the panning and zooming of a map, there is a risk with current implementations of this feature exposing an individual's or corporation's interest in particular locations. This risk would be mitigated with appropriate browser-level security.
• Accessibility: potential improvement Current implementations can only represent changes in the map state in a semantically meaningful form to a limited degree via such mechanisms as Accessible Rich Internet Applications (WAI-ARIA) 1.1 live regions. A browser implementation would be better able to provide meaningful representations of such changes to assistive technologies.
• Performance: potential optimization As current implementations rely on extensive manipulation of DOM nodes to achieve these effects, it is probable that a native implementation would be much more efficient.

6.2.3 Subscribe to notifications of map events

A web application embedding a map will commonly need to respond to changes in the state of the map, whether as a result of user activity or from other causes, so that it can update its own internal state and user interface as necessary to remain consistent with the map view. At a minimum, any change of the area displayed by the map needs to be notified to the application. In practice, it is usually desirable for other high-level events within the map view to be exposed as well. This allows an application fine-grained control of the level of detail of interactions it responds to, from simple updates when the map is moved or the zoom level is changed, to detailed feedback during user interactions of longer duration such as continuous panning.

In addition to events relating to the state of the map view itself, developers will expect to be able to receive notifications of events triggered by other components within the map such as controls, markers, and layers.

A native HTML map element would be expected to support the existing DOM event binding interface, using the standard addEventListener() method to bind listener functions to map events, and receiving an object derived from the standard Event interface as the argument to such functions.

Existing implementations

Implementations of map events vary widely in both the terminology used and the semantic richness of the events available. For example, the Google Maps API provides events named center_changed and zoom_changed, allowing a developer to provide discrete event handlers for such changes. The Leaflet API supports similar events, but named moveend and zoomend. The Bing Maps API, on the other hand, provides a more general viewchangeend event, and the handler for this event must examine the state of the map to determine what has changed.

APIs generally also provide lower level events directly correlating to user interactions, such as click and mouseover in the Google Maps API, though again terminology varies. The event objects passed to handlers of such events have additional properties compared to their equivalents in normal DOM event handling, such as a property giving the position of the event in terms of latitude and longitude.

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

tomtom-sdk

d3-geographies-api

supported, with limitations:

Although all existing implementations support an events system capable of meeting the needs of developers, inconsistencies in terminology, semantic richness, and the interfaces provided for adding and removing event listeners mean that it is unclear whether any one of the existing APIs would be a suitable model for the various capabilities available across the entire range of them.

Supported use cases

Uses beyond mapping

As it is anticipated that standard DOM event interfaces would be the basis for an HTML map's event system, it is likely that further uses could arise for such capabilities. For example, an HTML text annotated with geographical microdata could allow DOM events arising from user interaction (such as clicking on the name of a city within the text) to be enhanced with the same kind of position property, specifying latitude and longitude, as would be present in an event object created by a similar interaction with a map element.

As outlined above, it is expected that events as defined in DOM Standard would form the basis for a map element's event system.

HTML Standard media objects provide an existing example of extending the basic event system to support particular capabilities of embedded content.

Conclusion

This capability is a requirement for the scripting API of a native HTML map element. Responding to changes in the state of a map, or user interactions with elements of the map such as markers, is necessary for a web application to usefully modify its own state so as to reflect the results of such interactions.

• Privacy: reveals sensitive data Collating the positions on which a user centres the map could allow a script to infer an interest in a particular region and, for example, target advertising accordingly.
• Accessibility: potential improvement If events from maps and map interface elements are exposed to assistive technologies via the browser's existing accessibility mechanisms, it would be easier for those technologies to present them in a way consistent with other browser interactions.
• Performance: potential optimization Existing implementations must perform complex tasks such as transforming browser coordinates to map coordinates in order to provide such data in enhanced event objects. Native implementations could be expected to provide significantly better performance.
• Author experience: extensible The ability to respond to user interaction is crucial in building rich application interfaces that include embedded maps.
• Author maintainability: cost savings A standardised interface against which to write event-driven mapping applications reduces the amount of time developers need to spend becoming competent and productive.
• Consistency: established patterns Current implementations already seek to either extend or mimic the existing event mechanism.
• Consistency: progressive enhancement An application can determine which event-driven enhancements it is capable of supporting in a given environment.
• Consistency: fallbacks possible An application can choose not to subscribe to a given event or events if it determines that it cannot usefully provide an enhancement in its current environment.

6.2.4 Change the bearing of a map

Although the default bearing of a map - that is, the direction of "up" - is usually north, it can be useful to change this.

Existing implementations

Existing implementation support:

open-layers-api

apple-mapkit-js-api

mapbox-gl-api

d3-geographies-api

full support: these implementations all permit the bearing of a map view to be changed.

google-maps-api

bing-maps-api

leaflet-api

no support: these implemtations provide no support for changing the bearing of the map.

Supported use cases

Uses beyond mapping

This capability could be useful when a map viewer is used to display zoomable technical drawings.

Conclusion

This functionality could be added to enhance native web maps in the future.

6.2.5 Move the map to display a given location

An API should support allowing the map to be moved to display a given location.

Existing implementations

Existing implementation support:

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

d3-geographies-api

not applicable:

Supported use cases

Uses beyond mapping

ToDo

Conclusion

This functionality is a requirement for modern web maps.

6.2.6 Pan and zoom a map so as to completely show the area covered by a given bounding box

Description to follow

Existing implementations

Existing implementation support:

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

d3-geographies-api

not applicable:

Supported use cases

Uses beyond mapping

ToDo

Conclusion

Based on the limited data, we are undecided about whether this should be a requirement.

6.2.7 Animate the re-centering of the map view

Description to follow

Existing implementations

Existing implementation support:

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

d3-geographies-api

not applicable:

Supported use cases

Uses beyond mapping

ToDo

Conclusion

This functionality could be added to enhance native web maps in the future.

6.2.8 Animate the zooming of the map

Description to follow

Existing implementations

Existing implementation support:

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

d3-geographies-api

not applicable:

Supported use cases

Uses beyond mapping

ToDo

Conclusion

This functionality could be added to enhance native web maps in the future.

6.2.9 Animate the re-centering of the map

Description to follow

Existing implementations

Existing implementation support:

google-maps-api

bing-maps-api

apple-mapkit-js-api

mapbox-gl-api

leaflet-api

open-layers-api

d3-geographies-api

not applicable:

Supported use cases

Uses beyond mapping

ToDo

Conclusion

Based on the limited data, we are undecided about whether this should be a requirement.