OGC Testbed-14: MapML Engineering Report

This ER is required to capture all of the results of the MapML task in OGC Testbed-14. In particular, it is required to collect use cases, implementations, best practices, experiences and results.

This ER makes particular emphasis on a MapML Extension Study that is the result of extensive discussion in the group.

This document is required to specify and suggest adaptations or integration of OGC Web Services (OWS) (e.g. Web Map Service (WMS), Web Feature Service (WFS), Web Map Tile Service (WMTS)) serving MapML.

From the set of topics suggested at the beginning of the testbed, the participants have addressed the following:

The following topics initially suggested at the beginning of the Testbed have not been addressed and might be included in future testbeds:

This ER also collects experiences through the Browser Extension implementation of the HTML <map> element Application Programming Interface (API) and event model, to make programming maps on the Web an exercise in the application of browser-supported standards. This ER also collects experiences through the implementation of a Cloud-based Proxy for MapML.

During OGC Testbed-14, some suggested changes got into a new version of the MapML specification (https://maps4html.github.io/MapML/spec/) including clarifications on the coordinate systems (that completely aligns it to the WMTS concepts), the inclusion of tile support for the World Geodetic System 1984 (WGS84), the use of selects as an extra parameter in extent (such as elevation, time or band names), the use of alternative styles and the possibility to use external features-based linking to files (or WFS request URLs) instead of having to embed the features directly in the main MapML.

The support for tiles and images in the specification is now consolidated, but more work needs to be done in implementing the vector part. In particular, we need to clarify the attribute encoding, the CRS used and the eventual relation with vector tiles.

Another recommendation is to explore how MapML should be integrated in social media as a media type (formerly referred to as a MIME type). In social media there is neither editable HTML nor a <map> section but just the inclusion of a MapML file in a message. This message, could say something about a position ("I’m here" or "please go to this restaurant") but also discuss about more general topics ("this is the impact of Climate Change in global temperature"). The suggested approach of having extra parameters in a MapML URL could be considered to make it possible to recycle and exchange MapML files, while pointing to a restricted area of time in them. For example, the extent of a MapML file could be changed with Bounding Box (BBOX) parameters after the name of the MapML file, as explained in the corresponding section.

The new MapML specifications define how to use WMS and WMTS services in URL templates to dynamically serve tiles or images linked to the MapML file. More work needs to be done on the integration of OGC services as a source for recovering MapML files. In contrast, WMS and WMTS are potential standards for this but none of them are currently able to create MapML files. The former is not aware of TCRSs (tile matrix sets in the OGC vocabulary) and it is not in a good position to understand the zoom level concept. The latter is not able to return a MapML document that includes more than one tile because the purpose of GetTile is the generation of only one tile. There have been some proposals in previous testbeds to have a WMTS GetTiles operation and some drafts developed in the WMS group. Unfortunately, there has not yet been a demonstration of the real performance of such operations in practice, so the proposals have thus far not been accepted as a WMTS extension.

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

MapML is unique relative to other encodings but there is some level of duplication. What makes MapML unique is that it takes Spatial Data on the Web Best Practices [3] and applies them directly to HTML users instead of favoring the web developers.

The requirements for MapML were originally published on the Web here: http://maps4html.github.io/HTML-Map-Element-UseCases-Requirements. MapML is an extension to HTML, which if implemented, implies that the browser understands map/layer semantics (however those elements are eventually named), as well as feature, property, or geometry semantics. MapML is intended to be user-oriented. It aims at enabling users to create Web pages in all manner of styles, but having the common denominator being HTML and CSS, as well as JavaScript for progressive enhancement. Today, there is no built-in map/layer behavior in web browsers, much less feature/property/geometry semantics in such browsers. MapML provides the ability to encode map/layer and feature/property/geometry semantics in one (simple) format that will be read and interpreted by web browsers directly. MapML brings geographic knowledge to the web browser, thereby making the web browser the user agent.

There is no other encoding or service that attempts to do what MapML does. GeoJSON, Geography Markup Language (GML), or KML require JavaScript interpretation and are not native on the web browsers. MapML should not be constrained by other encodings should the need for user-oriented features arise (e.g. markup in coordinate strings and possibly other requirements). A major objective of MapML is to make the browser understand not only where the user is (that is already standardized by the GeoLocation API, https://www.w3schools.com/html/html5_geolocation.asp), but also to understand where features are in relation to the user.

A MapML document is a new media type for maps on the web. It looks very similar to and it is inspired by HTML, but it is not HTML. Even if it could look like HTML, it is actually written under the rules of MicroXML.

This document uses text/mapml as the media type for MapML documents.

A MapML document can be included in an HTML document in two ways:

There is a fundamental difference between the first and the second approach. If the MapML document is linked to the HTML page, the MapML becomes opaque to the HTML page. In practice this means that the internal content of a MapML document is not part of the Document Object Model (DOM) structure of the HTML and it will not be accessible for scripting (e.g. it will not be accessible to the JavaScript code associated with the HTML page). When the MapML encoding is embedded in the HTML page, it is part of the HTML DOM and it can be read and altered by scripts.

The fact that linked MapML documents are opaque to the scripts suggests the need to have events associated with MapML linked documents, in order to notify scripts about some changes in the map produced by user interactions. This will be discussed later in this document.

The MapML specification defines 6 possible CRS types as possible values for "input@units". The following possible values are defined in the version of the MapML specification that was available for OGC Testbed-14 (September 7, 2018):

MapML is dependent on the concepts of raster tiles and two-dimensional (2D) map projections. Projected CRS are commonly expressed in 'meters' with a few exceptions (such as the equirectangular plate carréer). Traditionally we refer to these coordinates as (x, y). Projected spaces are expressed in floating point numbers and can be as precise as the technology is to store coordinates. Many of them are defined to cover large portions of the Earth.

To define raster tiles, we superimpose cells (pixels) to a region of the projected coordinates. The region will start at the so called top-left corner and will be covered by tiles to the right and downwards. To do that, we need to define 3 pairs of regular index axes (for each zoom level) that are parallel to the projected coordinates and quantizes the space in pieces. The first one divides the space in cells (often referred to as pixels). Cell space starts at the top-left corner of the tiled space, and cells (pixels) are counted with integer numbers that increase to the right and downwards. The OGC draft specification for Tile Matrix Sets refers to these coordinates as (i',j'). The second index axis appears when the cells are grouped into tiles. The tiles are numbered from the top-left corner of the tiled space and count (with integer numbers) increases to the right and downwards. WMTS refers to these coordinates as (TileCol,TileRow). There is also an internal double index inside each tile to point to a cell in a given tile. In WMTS these coordinates are referred to as (i,j).

The authors of this ER proposed the following changes and clarifications in the "input@units" table to align the concepts (not necessarily the names of the concepts) with WMTS. To do that, there was agreement on introducing a new TCRS in the MapML table that would define an equirectangular plate carréer. This TCRS has Base CRS / Projection system=CRS:84, Origin (easting,northing)=-180,90, Tile row/column size=265, Projected Bounds / LatLng Bounds=LatLng(-180,-90), LatLng(180,90) and has the following zoom level values:

Then, this ER proposes to change the table of values for input@units in the following direction:

An approach for documenting alternative CRS has been proposed, during OGC Testbed-14, consisting of the combined use of "meta" and similar capabilities. If for some reason a TCRS different for the current one is needed, the map browser can simply replace the current MapML document by an alternate one that has the same information in the desired projection.

Apart from documenting the current and alternative projections in the MapML document, it would be good to define a parameter in the headers of the GET request to be able to specify the current accepted or supported projections by the web browser in the same way that accept-language works today (see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html).

which means: "I prefer OSMTILE, but might accept WGS84".

This subsection includes some features in MapML that were included in the candidate standard during this Testbed.

The current proposed encoding is a direct translation of the GeoJSON Encoding into a MicroXML. The following code is an example of how a MultiPolygon looks like in the current MapML encoding.

This subsection discusses the encoding of geometrical characteristics of a feature.

After examining the geometrical part of the features, this ER now concentrates on the attribute part. There is some consensus on the convenience of using HTML to express attributes ready to visualize. This has the issue of machine readability of the information contained in the HTML fragment. The suggestion is to use schema.org encodings to enable that.

Recently, some vendors (such as Mapbox, Google, etc) have produced encodings for vector tiles. There is no consensus of a transversal or interoperable encoding yet, what currently makes vector tiles an 'unknown media type' as far as the browser is concerned. As such, they are handled by the JavaScript layer (e.g. a leaflet plug-in), not by the web browser engine, except e.g. for the canvas API calls that might be done by the JavaScript library. In this respect, vector tiles are even less portable than PNG tiles, since for the latter the web browser engine 'understands' how to layout and paint picture formats. The main advantage of vector tiles is bandwidth conservation, which is important, but it is not the first main goal in standardization of geospatial concepts in the web browser.

MapML does not overlap or duplicate the role of vector or raster tiles. However, a MapML client engine, whether it was implemented in JavaScript or Web Assembly, or preferably by the web browser, could use vector data, (instead of, or in addition to raster tiles) to paint a map layer. To adopt vector tiles, the main barrier is the standardization of the vector tile format to the point where it is widely understood and implemented as a PNG. Finally, despite the canvas element, vector tiles styling is done by scripting, because vector tiles are not included in the DOM, hence they are not susceptible to styling via CSS.

The more direct way to apply CCS symbolization is to do it in-line by using a style attribute in the same way that it can be done in other HTML tags.

Another direct way to set styles is to use a class or and element identifier attribute to assign a CSS ruleset by its name.

Things start to be more interesting when we use a characteristic in CSS that allows for selecting elements to be symbolized depending on the values of some attributes of the element.

CSS has selectors that can be used to select element tag names, class attributes or elements id’s. An interesting capability is that selectors can be used to select whatever element name that has an attribute (using the '*' character).

As suggested by https://www.brmwebdev.com/dev/css/schema-based-styling, this can be used for semantic tagging in schema.org microdata to define the symbolization of elements that has a particular semantic annotation. This means it can be used to select features that have a particular property. In practice, if features are tagged with microdata, then elements of a particular itemtype can be selected. Going further in this approach, itemtype’s that are in a particular scope can be selected. The authors of this ER have not been able to find anyone suggesting that, but it is what you should do if you want to be precise in your selectors. This approach was already mentioned in OGC 16-053r1 [4].

Exploring all these possible combinations together, and analyzing what is possible in CSS, some important limitations in CSS were found that prevent developers from doing things that are common in GIS such us conditioning the style of a geometry to some values of the properties or specifying a style declaration value as a function of a property value.

In the experimentation done to apply CCS to features with properties and geometry, the following limitations were detected:

Some experts suggest that the limitations in the selectors syntax were imposed on purpose to limit complexity of the parses and to allow a faster parsing of the HTML-CSS styler.

One of the extensions needed the capability to apply a selector based on some properties values to the geometry. The authors of this ER propose to incorporate condition1 attribute to point another selector that will add extra conditions based on elements that are not directly the ones to symbolize. Both the selector and the condition1 should be of the same father.

A suggested possibility is:

Another extension could be to condition a declaration value (e.g. width) to a property value (e.g. lanes). This could be achieved by using a selector as a value of a symbol declaration:

This subsection assumes that CSS rule-sets are provided in an independent CSS file and linked from the MapML page.

There are two practical ways that emerged from the experiments done during OGC Testbed-14, which support a use case giving the opportunity to the user to select among a list of styles for the "same" map content.

One approach is to use the link rel approach to indicate that there are other alternative styles related to the same map available. This can be done by using the link/@rel=style to indicate alternative styles that will have a title and an href to another MapML document. The style currently in use can be tagged as "self style".

In a client, alternative styles can be expected to result in alternative presentations available in the legend (e.g. as a drop-down selector or a group of radio buttons)