OGC Testbed-13: MapML ER

A map can currently be embedded in a web page by means of the HTML <map> element. However, such a map is essentially static: it allows the HTML author to draw hyperlinks over shapes on a static image. Maps should allow us to interact with map content in a way that is more interesting. To be able to do this, a new child element is introduced to the <map> element in the form of the <layer> element. A <layer> element allows to point to a MapML document describing content of a map layer. Multiple layers can be included in a single map, each by means of its own URL. A similar construct is used for the HTML <video> element, which can have one or more source files included as child <source> elements. (Of course, with a video, the most appropriate source file is chosen from the child <source> elements. In contrast, a <map> element’s child <layer> elements are stacked and overlayed together as a group.)

MapML could be used as a story maps mechanism where the user navigates progressively through the content and learns by reading a combination of text and map scenes. In story maps the narrative flow is linear but the user can play with the maps presented and verify the textual description that accompanies the map. Commonly, the story is presented as a single page that can be scrolled up and down with maps that are controlled by the text shown or text fragments each one accompanied by its respective map. To make story telling possible, more than one map needs to be supported in a single page.

An example of story maps can be shown here: https://grid-arendal.maps.arcgis.com/apps/Cascade/index.html?appid=54b862ef079445d9a99b8f6249249e4d

This standard starts by proposing an extension to the old <map> element that represented a map browser that starts in a lat,lon position in a projection (that is actually a tiled CRS: a tile matrix set) at a given zoom level. Apart from the old area elements for descended compatibility to old browsers, it has a new element type that is called layer that references one or more MapML files.

The source of the example can be found here: http://geogratis.gc.ca/mapml/en/osmtile/cbmt/

This is all you have to do as a web designer to include a map in your web page.

Behind an easy to do link "http://geogratis.gc.ca/mapml/en/osmtile/cbmt/" in the previous example there is the hidden complexity of the MapML implementation.

Let us start to say that in the previous layer section there is a src link to the http://geogratis.gc.ca/mapml/en/osmtile/cbmt/ URL that is actually a MapML MIME type (text/mapml) that looks like this:

Once the MapML engine gets a file, it determines the properties of the extent of the layer and the minimum, maximum zoom and the CRS projection. Then it goes back to the <map> section in the HTML page to calculate the real extent (xmin, xmax, ymin, ymax) that corresponds to the zoom="3" lat="60.5005254" lon="-98.2617190" that covers the width="900" and height="400". The result of this calculation is not done in CRS coordinates but in the tilematrix zoom 3 pixel coordinates (the so called "tilematrix" coordinates) that starts at the origin of the time matrix (Top-left corner). It virtually inputs it in the xmin, xmax, ymin, ymax and zoom values and submits the extent in the same way that a form is submitted. Since the method is GET and the enctype is x-www-form-urlencoded, the engine builds a URL with the form element name and values pairs and sends it to the server. In this case the request is: http://geogratis.gc.ca/mapml/en/osmtile/cbmt/?xmin=-104&ymin=389&xmax=1034&ymax=789&zoom=3&projection=OSMTILE

Please note that coordinates provided in the URL and in the responding MapML are also in tile matrix coordinates.

The return of this request contains a list of the URLs of all tiles that need to be requested to compose the map visualization area:

On the server side, there is an application that is producing these MapML responses. The application identifies the CBMT layer and knows about the ArcGIS web tile service that is able to provide the needed tiles. In this case we discover that the layer is actually associated with two datasets in an ArcGIS rest service: CBMT_TXT_3857 and CBMT_CBCT_GEOM_3857 so that, they will be presented as overlayer datasets in the map browser. Two URL examples are: https://geoappext.nrcan.gc.ca/arcgis/rest/services/BaseMaps/CBMT_CBCT_GEOM_3857/MapServer/tile/3/2/2?m4h=t and https://geoappext.nrcan.gc.ca/arcgis/rest/services/BaseMaps/CBMT_TXT_3857/MapServer/tile/3/2/2?m4h=t

Next time the user makes an action on the map, a new Key-Value Pair (KVP) request will be sent to the server with the new bounding box coordinates. For example a pan of only a few kilometers to the left hand side will result in the following request: http://geogratis.gc.ca/mapml/en/osmtile/cbmt/?xmin=-310&ymin=389&xmax=828&ymax=789&zoom=3&projection=OSMTILE that results in a very similar MapML response that is different for the previous on in the extent section and in the list of tiles URL it contains.

Since the references to the tiles (not reproduced in the last source code sample) correspond to the same URLs, the map browser takes advantage of the cache and does not request any additional tile. The map browser only portrays the same tiles in a different position in the screen.

The presented example only contains tile references but it could eventually contain features encoded in an XML encoding that has the same restrictions and capabilities that GeoJSON has. This capacity is defined in the MapML current specification but its implementation is very limited.

OpenSearch-Geo provides a mechanism to search for data. It incorporates a way to communicate a bounding box, a time window and a search by keyword. The parallelism with the current mechanism of MapML is apparent. But there are a couple of fundamentals differences that could justify two encodings: OpenSearch-Geo does not define an HTML form but a URL template based on KVP (that is almost the same as what enctype x-www-form-urlencoded intents to do) and the expected response of an action of submitting the form is an atom file, instead of a MapML document. Assuming that the two presented obstacles can be relaxed, it is worth continuing to explore the commonalities between both encodings and consider completely replacing the current extent section with an OpenSearch-Geo compatible one.

Let us compare the names of the parameters between the two standards in a tabular form:

The OpenSearch Geo section "9.2.1 Search request parameters" mentions, which refers to a bounding box (bbox):

This means that in order to use this mechanism, MapML should define a URL template that will fix the names in the extent form. For example the current MapML request template: xmin={mapml:xmin}&xmax={mapml:xmax}&ymin={mapml:ymin}&ymax={mapml:ymax}&zoom={mapml:zoom}&projection={mapml:projection}&search={mapml:search} could be assimilated to something like bbox={geo:box}&zoom={mapml:zoom}&projection={mapml:projection}&q={searchTerms}

Assuming that we keep the general mechanism as proposed, there are a couple of modifications that we can suggest.

In the new era of Big Data, there are many sources of datasets that are systematically being automatically acquired. It is important to know the time of the actual phenomena measured and to be able to filter by the time the user is interested in. In this document, we propose three alternatives to deal with time.

Some tile service implementations follow a pattern in the tile URL naming, making a tile URL predicable if the pattern is known by the client. TileCache uses the pattern {base_url}/{z}/{y}/{x}. OGC WMTS REST interface also defines URL patterns that are not fixed but declared in the service metadata. These patterns are declared using the URI templates specification (actually, the specification does not cite the approved version or RFC6570 https://tools.ietf.org/html/rfc6570 explicitly, but a draft of it, because the approved one was not available at the time WMTS standard was approved). In addition, the WMTS KVP syntax can also be expressed as a URI template like this: {base_url}?service=WMTS&‌request=GetTile&version=1.0.0&layer=etopo2&‌style=default&‌format=image/png&TileMatrixSet=WholeWorld_CRS_84&TileMatrix={TileMatrix}&TileRow={TileRow}&TileCol={TileCol}.

If a URI template describing the URL of all possible tiles is available, it could be included in a MapML file. In this case, the client could retrieve any tile if it needs to react to the actions of the user that changes the view bounding box (e.g. pan or zoom), without any need to request a new MapML file that contains the tiles URLs of the affected new bounding box. Instead, the client can transform the URL template into as many tile requests as it needs directly.

This approach introduces more programming requirements on the client side, since the client needs to transform a bbox in a series of tile requests, while, in the current approach, the server provides MapML files that include them. In contrast, this approach reduces the number of server interactions, in particular if the MapML only contains tiles (and not features).

We propose to extend the <extent> element to include an element called <template> that includes an attribute "type" (for the moment with a value fixed to "tile") and an attribute "uri" that will contain the URI template. The element <template> can be repeated more than once if the MapML includes tiles following more than one URI template (for example, if it includes tiles of two layers overlapped). The following example shows how the current MapML standard is extended to include the new characteristic in the extent element.

One of the most common actions in a map is clicking on it hoping to get more information about some represented features, such as can be obtained with a WMS GetFeatureInfo request. On a map browser, we can create a form that carries appropriate input@type children which will transmit event specific variables as query parameters (or other potentially also other templated request parts).

As a result of the click event submitting the above form, the server should return a MapML or HTML document describing the features at the event location that will show in a popup/map balloon (tooltip) or other browsing context. In examining the above (hypothetical) markup, a number of questions naturally arise. For example, in what units are the coordinates of the input@location? Should the units of the location be controlled by other input attributes? Should the input@type=location have a visual expression or should it be hidden by default?

Textual search is an important characteristic of maps. It is proposed here that such search be implemented by the HTML map element as an aggregating control; if the HTML author enables search for at least one layer that they include on their map, and if the map document for that layer includes a form element(s) configured for search via a child input@type=search element, a search text input control could be presented to the end user in a default manner by the user agent (for example at the top left of the map, as is common in today’s map browsers). Since there could be more than one layer on a map which is searchable, the map’s search text input would have to aggregate such searches, and convey result sets or search hints appropriately. In general, the user action of selecting from a result set list obtained through search should display the location of the result on the map in a natural manner. The challenge of designing the markup for the map documents is to identify what can be standardized versus what should be left to the provider of the MapML document and again, what should be the responsibility of the user agent. This brings up many questions, including whether a MapML document needs to be consumed by an HTML <map> element, i.e. what if the MapML document is the direct target of the browsing context. What would the map look and behave like?

A tooltip is a floating window (commonly with a yellow or orange background) that contains short information about the features in the map and that follows the mouse pointer. The information on the tooltip changes when the mouse changes position without any need for clicking it (hover). This characteristic is losing popularity since mobile phones and tables are not equipped with a mouse but it could reemerge in virtual reality glasses. We propose to define a form that has an input element with a name = event and a value defined as onHover that could replicate this functionally. The map browser would trigger this event when the mouse moves over the map.

In MapML there are two kinds of forms: <extent> and <form> (the second one is not yet included in the MapML current draft specification). Like HTML5 forms, MapML forms have an action attribute that specifies where to submit the form inputs, but there is no actual submit button for the user to press. In the case of the <extent> element, it is expected that the user agent submits the form each time the map needs more map content. Common situations where new information is required are when the user performs a pan or a zoom action, or the window is resized or re-oriented. In the case of the <form> element, this report recommends that when the user clicks the map to know more about a feature (per the above discussion), the assumed default target of the action is a map balloon. Depending on the target attribute of the form, the map author might direct what to do with the response to form submission. It is assumed that in the case of a default target, the submission will result in a MapML or HTML document that will display in a map balloon browsing context. If there was a target, the response could be redirected to another window or frame with that name and the map view will not be changed in the client.

Another important functionality in a map browser is to be able to provide directions to go from one place to the next. Again, the way the map element is implemented, we expect that search text input(s) should be provided at the map browser level and not at the layer level. Nevertheless a layer in the map browser should be able to provide this functionality, so a form (or some additional elements in the extent form) could be required to allow that. Two input elements of type "from" and "to" is the minimum set required but other attributes (such as the type of transport the user has access to) could be necessary.

MapML currently proposes an encoding for features that resembles GeoJSON in the sense that it describes a feature as formed by geometry and properties. Properties are not specified and can have a free list of property elements and values. The geometry is expressed by a set of coordinates. A MapML file can have a list of features but they are not grouped in feature collections.

The authors of this Engineering Report believe that features are an essential part of OGC semantics. As such, the encoding of feature information as currently implemented by MapML may be a starting point for more human-friendly encoding and display of geographic features. What follows are some alternatives or extensions to the current feature model that may make integration of geographic information more natural on the human web.

This encoding explores how to use schema.org to semantically tag html text and provide the necessary information that describes a feature.

There are several entities in schema.org that can be mapped to features depending of their meaning. If none of them apply, we can always use "Place" (http://schema.org/Place) or we can extend schema.org to our purposes. In this example, we are mapping each feature to "Place" and we use a few of the common properties of Place to tag our information fields (identifier, url and alternateName). Other existing properties can be useful in many cases (logo, photo, review, description, sameAs, potentialAction) In case none of the properties of Place apply, we can add uncommon properties using the PropertyValue mechanism which allows us to include in additionalProperty that define and use properties using name & value pairs.

For the geometry property, the standard OGC model could be used, structured into standard element names, with the additional consideration that the coordinates of a feature on a map are analogous to human-readable text in a traditional HTML document. As such, the coordinates content should be subject to further, though possibly constrained markup, such as <span>, <a> and possibly other phrasing content markup (further prototyping/analysis required).

The possibility of using HTML+schema.org for the geometry property has been analyzed but the elements GeoShape and GeoCoordinate do not fit with the requirements needed in terms of coordinate reference system and polygon composed of multiple rings (both possibilities are not supported by schema.org).

This example was validated by the Google Structured Data Testing tool (https://search.google.com/structured-data/testing-tool) resulting in no warnings or errors.

The editors of this document are now members of the discussion list and can submit a question on the best way to extend schema.org. OGC should review http://schema.org/docs/extension.html.

In fact, Schema.org is not very consistent in its own definitions. For example they are proposing a http://pending.schema.org/GeospatialGeometry that is actually talking about topology. It mentions an informal collaboration with the W3C Spatial Data on the Web Working Group. (http://schema.org/docs/releases.html)

The concept of a map in MapML shares a similarity with the definition WMS: "portrayal of geographic information as a digital image file suitable for display on a computer screen" (From WMS 1.3 Section 4.7: map). This section proposes an extension of WMS to support the direct creation of MapML from a WMS service. In addition, the details of the request derived from submitting an <extent> form to the server (that generates a KVP request concatenated to the action url) is conceptually very similar to the act of submitting GetMap request in KVP. Both request are aiming at getting a map back. Commonly, a WMS GetMap request returns a static image like a png or a jpeg but nothing prevents the server from returning other content formats, including some sort of markup language or JSON file. The only condition is that the returned format should be easy to render on the client screen. In practice, this means that the server should simplify the data to fit with the screen resolution and that the data can easy be represented as a vertical 2D view (bird view) of the scene. MapML fits perfectly with these requirements (in particular the decision of using 2D tilematrix coordinates in the vector coordinates and in the bbox). In the following table, we compare the parameters of the GetMap request with the MapML extent elements. The main conclusion is that a GetMap request has many more parameters but they will have fixed values during the MapML interactions and that the common parameters can be assimilated to the ones in WMS but they are not directly compatible.

To avoid radical changes in the MapML standard candidate, we propose to extend WMS with a new request GetMapML and to extend MapML "extent" allowing specific hidden parameters in the section.

Conceptually, a WMS GetMapML request needs the same as GetMap but substituting the bbox parameter with the parameter list xmin, ymin, xmax, xmax (that are in tilematrix coordinates and not in the CRS coordinate as bbox is); width, height is substituted with the zoom parameter (that is related to the actually a tile matrix identifier that allow to matematically calculate the width and height) and CRS is substituted by projection (even if it actually represents a tile matrix set name). In this case WMS GetMapML will not support Trasparent and BgColor favoring transparency by default whenever possible.

The GetMapML request will, in addition, incorporate the following extra parameters:

In addition to them, two additional parameters could be added: Time and Elevation for extra support to this two variables.

In response of a successful GetMapML request, the WMS service will produce a MapML that will have an extent section with the content similar to the illustration in this example:

In addition, the MapML document can contain all references to obtain the relevant tiles present in the extent bounding box in <tile> elements. These tile elements can be references to WMTS services, another kind of tile services, or full KVP WMS GetMap requests to get maps that will have equivalent characteristics in terms of bbox, width, height and format of the expected tiles. Secondly, the MapML can contain also features in <feature> elements that are visualized in the map as vector features.

If this proposal is accepted by the MapML community as a service that generates MapML files, it will be necessary to consider what concrete changes are needed to be done in the GetCapabilities response to expose the possibility of having GetMapML requests. The minimum changes in the ServiceMetadata document are:

In addition to this, the MapML work done in this testbed and documented in this document to allow simple queries for more information in a point of a map, should be aligned with the GetFeatureInfo.

The following UML diagram summarizes the approach suggested and gives emphasis to the two internal functionalities that need to be implemented to transform WMS into a MapML service. The most apparent difference is the existence of the GetMapML operation. The "BBOX to WMSC tile URLs" is aware of the tile matrix set concept and is able to transform the BBOX and the zoom level into a sequence of WMS requests that can populate the bounding box, but perfectly fits the requirements of a tile in terms of width and height. To be able to provide the features in the tile matrix coordinates, a "CRS to tile matrix coordinates (internal)" functionality is required. Based on the zoom level, transforms the WFS coordinates into a tile matrix coordinates and transforms a GML file into the right format for the MapML.

To satisfy the NR103 deliverable for OGC Testbed-13, CubeWerx implemented a MapML server compliant to the "Map Markup Language" current draft specification at "http://maps4html.github.io/MapML/spec/[http://maps4html.github.io/MapML/spec/]", and compatible with the "<web-map> HTML Element proposal" at "http://maps4html.github.io/HTML-Map-Element/spec/[http://maps4html.github.io/HTML-Map-Element/spec/]".

The implementation was made as an unofficial extension to the WMTS 1.0.0 specification (OGC 07-057r7) by introducing a "GetMapML" operation to the demo WMTS server at: https://tb13.cubewerx.com/cubewerx/cubeserv/default

Since GetMapML is not officially a WMTS operation, the WMTS capabilities document is typically bypassed (even though, as a matter of completeness, it does list GetMapML as one of its supported operations). In MapML, each layer has its own endpoint. For this particular server, the endpoint of each layer is (RESTful URL):

https://tb13.cubewerx.com/cubewerx/cubeserv/default/wmts/1.0.0/mapML/<layerName>

An alternative longer form for the endpoints using SOA KVP encoding is: https://tb13.cubewerx.com/cubewerx/cubeserv/default?SERVICE=WMTS&VERSION=1.0.0&REQUEST=GetMapML&LAYER=<layerName>

This implementation provides three layers:

As such, the three MapML endpoints are:

All three layers are available in the OSMTILE, CBMTILE and APSTILE projections as defined by the "Map Markup Language" draft specification, with the exception of "NAIP.NAIP" which is not available in APSTILE due to its southern geographic location.

To illustrate the implementation, CubeWerx have set up a fast demonstration map for each of the three projections:

As an example of the inner workings of MapML, one of the MapML accesses that is performed by the CBMTILE demo is:

https://tb13.cubewerx.com/cubewerx/cubeserv/default/wmts/1.0.0/mapML/NAIP.NAIP?xmin=105767&ymin=130523&xmax=107057&ymax=131123&zoom=9&projection=CBMTILE

This particular URL returns the following document (with extra formatting added for readability):

We found that implementing MapML as a WMTS extension was a natural fit, since it allowed us to reuse the tiling infrastructure of our WMTS codebase and to deploy it more easily.

The following UML diagram summarizes the approach taken and gives emphasis to the two internal functionalities that need to be implemented to transform WMTS into a MapML service. The most apparent difference is the existence of the GetMapML operation that allows for a bounding box input. To interpret this the "BBOX (CRS) to tile URLs (tilematrixset coordinates)" internal functionality is required. It transforms the BBOX and the zoom level into a sequence of WMTS requests that can populate the bounding box, considering the tile matrix that corresponds to the right scale denominator. To be able to provide the features in the tile matrix coordinates, a "CRS to tile matrix coordinates (internal)" functionality is required. Based on the zoom level, transforms the WFS coordinates into a tile matrix coordinates and transforms a GML file into the right format for the MapML.

WMS and WMTS are services that are dealing with scale and are able to translate between map coordinates (in a system commonly identified by a EPSG CRS) and screen coordinates (commonly known as CRS0 or CRS1).

In contrast, WCS and WFS are not supposed to associate/translate map coordinates to screen coordinates so they are conceptually different. You could argue that WCS and WFS are able to make CRS transformations on the fly so they could also do map coordinate to tile matrix coordinates transformations. This is true but this forces us to recognize tile matrix coordinates as true CRSs. We could reuse some of WCS.SWG work on parametric CRS’s where parameters could "travel" in the actual CRS URL (in our case the zoom level and eventually the top left corner). Parametric CRS are not very popular in CRS because many believe that a URL would be opaque and by definition a parametric URL is not opaque.

Alternatively, we propose to use a WMS or a WMTS as a facade or a broker that will serve the client a dialog with a WCS or WFS for requesting data. This is not a new idea. At the time that SDL was defined as an "extension" of WMS, there was the need to define the data morel behind the layer (it was not necessary in a pure WMS). You needed the data model to encode the symbology rules. A layer needed to be defined as "coming from feature types" or "coverage types". If you do that you immediately recognize that a WMS can have a WFS at the backend (or as a data repository). This means that when a WMS request comes to the service it translates it to a WFS request that is sent to the backend. When the WFS responses, the WMS takes the features combines the with styles, coordinates are transformed to CRS0/CRS1 rendered and served. The same for a WCS coverage. An illustration of this possibility can be seen here http://slideplayer.com/slide/4632571/15/images/41/Architecture+using+WMS,+WFS,+and+SLD.jpg in an slide of a presentation prepared by the George Percivall talking about the OGC reference model http://slideplayer.com/slide/4632571 and reproduced below for convenience. Actually the illustration also suggests another reason why this architecture could be convenient: that capacity of WMS to incorporate styles using Symbology Encoding rules that are applied to features that are provides "styleless" when coming directly for a WFS. The same architecture can be proposed to serve a MapML if we substitute CRS0/CRS1 for tilematrix coordinates and "render" by "encoding in MapML".

Currently, there are three OGC standards that can specifically address this request: GeoOpenSearch, CSW and WFS+Filter. Following the discussion about the MapML service above, that favors the use of a modified WMS or WMTS to serve tiles, this functionally cannot be implemented by a WMS or a WMTS without having to change the scope of the service in a way that moves it too far away for the original scope. This is the reason why we consider that this functionally should be provided by another service type that will act in tandem with the WMS or WMTS that is providing the main service.