OGC Testbed-14: MapML Engineering Report
OGC Testbed-14: MapML Engineering Report
Publication Date: 2019-03-06
Approval Date: 2018-12-13
Submission Date: 2018-12-09
Reference number of this document: OGC 18-023r1
Reference URL for this document:
Category: Public Engineering Report
Editor: Joan Masó
Title: OGC Testbed-14: MapML Engineering Report
OGC Engineering Report
Copyright (c) 2019 Open Geospatial Consortium.
To obtain additional rights of use, visit
WARNING
This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.
LICENSE AGREEMENT
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
Table of Contents
1. Summary
1.1. Requirements & Research Motivation
1.2. Prior-After Comparison
1.3. Recommendations for Future Work
1.4. Document contributor contact points
1.5. Foreword
2. References
3. Terms and definitions
3.1. Abbreviated terms
4. Overview
4.1. MapML in relation to other encoding
4.2. MapML as a media type
5. CRSs in MapML
5.1. Introduction
5.2. CRS types in MapML
5.3. CRS negociation
6. URL templates
6.1. Evolution of the interaction between clients and services exchanging MapML.
6.1.1. Features can be linked as well as embedded
6.1.2. Static MapML
7. Feature Encoding
7.1. Current version encoding
7.2. Encoding geometries
7.2.1. How different is GeoJSON in MicroXML from GML?
7.2.2. Adding CRS
7.3. Encoding attributes in features
7.3.1. Encoding feature properties with Microdata.
7.3.2. Alternative 1: Compact geometry encoding with microdata
7.3.3. Alternative 2: Compact geometry encoding with microdata
7.3.4. Alternative 3: GML geometry encoding with microdata
7.4. MapML in relation to vector tiles
8. CCS Symbolization
8.1. How to apply css styles to geometries
8.2. Limitations in CSS
8.2.1. You cannot set a selector based on the value of the element.
8.2.2. You cannot set select an element of the HTML and apply the symbol to another element
8.3. Extensions of CSS to support geospatial requirements
8.4. Selecting alternative styles for MapML
9. Events
9.1. Maps4HTML events
9.1.1. Proposed Maps4HTML events
10. Other aspects in MapML
10.1. MapML and CORS
10.2. Languages in MapML
10.3. Considerations on multidimensional data (and time) in MapML
11. Testbed-14 Implementations
11.1. Cloud Based Proxy (cascade) for MapML
11.1.1. Requirements
11.1.2. Approach
11.1.3. Implementation
11.2. ServiceWorker Proxy for MapML
11.2.1. Requirements of MapML Browser Extension
11.2.2. Approach
11.2.3. Restriction
11.2.4. Software Design
11.2.5. Software Environments
11.2.6. User Interface
12. Including MapML in social media.
12.1. The use of MapML as the new media for exchanging maps.
12.2. Drag and drop maps.
12.3. Tests trying to share maps
13. OGC Web service to produce MapML.
13.1. A proposal for new services that integrate maps and tiles
Appendix A: OpenAPI
Appendix B: Revision History
Appendix C: Bibliography
1. Summary
This is the second Engineering Report (ER) about the Map Markup Language (MapML) [
] resulting from OGC Testbed initiatives. To find an introduction of MapML and how it works, please, refer to the previous ER OGC 17-019 [
]. MapML is a new media type that can be included in a element of a

embedded directly in the HTML page, in the same way a Scalable Vector Graphics (SVG) document can also be included.


projection
CBMTILE
zoom
17
lat
45.4624905
lon
-74.9787676
width
900
height
400
controls
label
CanVec+ Features
checked
units
WGS84
method
GET
...
<...>
rel
features
...





Note
At the time of writing this document, the second option was not part of the Maps4HTML draft specification but the need was discussed in OGC Testbed-14 with the authors of the MapML specification and might be incorporated in the near future.
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.
5. CRSs in MapML
This chapter discusses about CRS definitions and CRS negotiation in MapML.
5.1. Introduction
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):
Table 1. Original table defining the input@units possible values.
Value
Definition
tcrs
The location should be serialized in units associated with the TCRS instance, i.e. pixels or in the case of WGS84, decimal degrees
pcrs
The location should be serialized in units associated with the projected coordinate system associated to the TCRS instance, e.g. meters for OSMTILE, which has an associated projected coordinate reference system of EPSG:3857.
gcrs
The location should be serialized in units associated with the geodetic coordinate system associated to the TCRS instance, e.g. decimal degrees for the OSMTILE TCRS, which has an underlying geodetic coordinate reference system of EPSG:4326. In the case of a TCRS such as WGS84, the gcrs and tcrs location are the same.
map
The location should be serialized in units associated with the map coordinate system defined by the extent, i.e. in pixels with the origin at the upper left corner of the extent, with coordinate axes' increasing right and downwards, respectively.
tilematrix
The location should be serialized in units associated with the tilematrix at the zoom level of the extent.
tile
The location should be serialized in units associated with a tile at the zoom level of the extent.
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).
5.2. CRS types in MapML
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:
Table 2. Proposed a new Equirectangular TCRS zoom levels.
Resolution
0.703125000000000
0.351562500000000
0.175781250000000
8.78906250000000 10^-2
4.39453125000000 10^-2
2.19726562500000 10^-2
1.09863281250000 10^-2
5.49316406250000 10^-3
2.74658203125000 10^-3
1.37329101562500 10^-3
6.86645507812500 10^-4
3.43322753906250 10^-4
1.71661376953125 10^-4
8.58306884765625 10^-5
4.29153442382812 10^-5
2.14576721191406 10^-5
1.07288360595703 10^-5
5.36441802978516 10^-6
Then, this ER proposes to change the table of values for input@units in the following direction:
Table 3. Proposed new table defining the input@units possible values.
Value
Definition
Representation
tcrs
For a given zoom level (that defines a pixel size), the location is expressed in pixel coordinates with the origin at the top-left corner of the tiled space. Not applicable when extent/@units=WGS84
OGC Tile Matrix Set suggested naming is (i',j').
pcrs
The location is expressed in projected coordinates. Units are meters except for the geodetic CRS of WGS84 that is expressed in longitude-latitude. e.g. meters for OSMTILE, which has an associated projected CRS of EPSG:3857
Commonly they are represented as (x,y)
gcrs
The location is expressed in the geodetic coordinate system associated to the projection, e.g. decimal degrees for the OSMTILE TCRS, which has an underlying geodetic coordinate reference system of EPSG:4326. In the case of extent/@units=WGS84, the gcrs and pcrs location are the same.
Commonly they are represented as (long,lat)
map
For a given zoom level and a given extent, the location is expressed in pixel coordinates with the origin starting at the upper-left corner of the extent increasing right and downwards, respectively
They are equivalent to the (i,j) values of the OGC WMS standard.
tilematrix
For a given zoom level, the location should be expressed in number of tiles starting to count tiles at the top-left corner of the tiled space increasing right and downwards. Not applicable when extent/@units=WGS84.
In OGC WMTS standard they are names (TileCol, TileRow).
tile
For a given zoom level and a given tile, the location is expressed in pixel coordinates with the origin starting at the upper left corner of the tile increasing right and downwards, respectively and ending at 256. The combination of tilematrix and tile coordinates give a location with the precision of a pixel size. Not applicable when extent/@units=WGS84.
They are equivalent to the (i,j) values of the OGC WMTS standard.
Warning
At the time of publishing this document, a new version of the MapML specification has been released (October 17, 2018) adopting most of the changes suggested in this chapter.
5.3. CRS negociation
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.
Alternative CRSs in MapML.
name
projection
content
OSMTILE
/>
rel
alternate
projection
CBMTILE
href
/>
Note
The reason behind the combined use of
meta
and
link
elements derives from the fact that the web browser needs to know the actual projection to be able to decide if the projection for the current MapML (written in the
meta
field; as well as in the extent) is compatible with the other layers already in the view or it needs to try an alternative map projection. Currently, the list of alternatives for projection values is limited by the MapML specification. These differ from the
styles
case where there is no list of
a-priori
alternative name values or even the guarantee that two styles with the same name are actually compatible.
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
).
Alternative CRSs in MapML.
Accept-Projection: OSMTILE, WGS84;q=0.5
which means: "I prefer OSMTILE, but might accept WGS84".
6. URL templates
The introduction of URL templates in the MapML specification was one of the suggestions of OGC Testbed-13 that was adopted. This chapter explores how the URL templates have been extended in OGC Testbed-14 and how the introduction of the URL templates has provided a new level of interaction between clients and services exchanging MapML documents.
6.1. Evolution of the interaction between clients and services exchanging MapML.
This subsection includes some features in MapML that were included in the candidate standard during this Testbed.
6.1.1. Features can be linked as well as embedded
In the previous versions of MapML, features could only be embedded in a MapML document as MicroXML encoded (with an XML encoding inspired in the original GeoJSON format). Now it is possible to include a link to external features files that may or may not be encoded in MapML.
6.1.2. Static MapML
The OGC Testbed-13 MapML ER (OGC 17-019) presents a description of a dynamic interaction between a client and server that required the exchange of a MapML document for each action the user does in the map (e.g. a pan or a zoom). That was due to, at that time, a MapML document containing references (URLs) to all of the individual tiles that were needed to populate the viewport without making use of possible patterns that tile URLs might follow. An action of the user (e.g. a pan) resulted in a new bounding box and most of the previous tiles were no longer useful so that new tile URLs needed to be obtained resulting in a new MapML exchange. The
Figure 1
shows the sequence of events of one of these client-server interactions. This OGC Testbed-14 ER refers to this approach as
dynamic MapML
. In this approach a server is needed to generate MapML documents on-the-fly. The following example illustrates the response of the server to one of these interactions. In it, can be seen several similar tile URLs, one for each tile necessary to cover the viewport.
Dynamic MapML example for describing a tile service




href
/mapml/en/osmtile/cbmt/
/>
href
rel
license
title
Canada Base Map © Natural Resources Canada
/>


action
/mapml/en/osmtile/cbmt/
enctype
application/x-www-form-urlencoded
method
get
units
OSMTILE
max
2048
min
name
xmin
type
xmin
value
104
/>
max
2048
min
name
ymin
type
ymin
value
389
/>
max
2048
min
name
xmax
type
xmax
value
1034
/>
max
2048
min
name
ymax
type
ymax
value
789
/>
max
15
min
name
zoom
type
zoom
value
/>
name
projection
type
projection
value
OSMTILE
/>

src
/>
src
/>
src
/>
...
src
/>
src
/>


Figure 1. Interaction between client and server in a dynamic MapML
In OGC Testbed-14, participants experimented with the use of URI templates to simplify the iteration. In this case, a MapML document no longer offers full URLs pointing to individual resources. Instead, it includes a generic URI template and the client should be able to figure out the necessary URLs to request tiles, images of features. Since the URL template is valid for any zoom and pan, this approach removes the need for having a server responding to each and every user basic interaction (e.g. zoom and pan) and generation MapML documents on the fly. In the extreme, it removes the need for MapML generation on the server-side because MapML documents can be statically produced for the resources and stored in a web server as files. In this document, the approach is referred to as static MapML. The following example illustrates a MapML document that describes how to access a tile service. In it, can be seen a single URI template for tiles; the client should be able to derive from the URI template all the necessary tiles to cover the viewport. In addition to the URL template, the MapML document includes the definition of each variable in the URI template as an of the section. In the case of the zoom level it also includes the minimum and maximum value this variable can adopt. Note that this approach allows for dialoging with different services using different variable naming conventions. For example, in OSM it is common to express the URL template using the
and
variables while WMTS uses
TileMatrix
TileRow
and
TileCol
respectively.
Figure 3
shows the inspection of the network interaction of the web browser with the tile server, demonstrating the conversion of the URL template into 10 different tile requests in a 2x5 matrix (including the request for 2 non-existing tiles that results in an error).
Static MapML example for describing a tile service (from:
simplified)



href
/mapml/en/cbmtile/cbmt/
/>
rel
license
href
title
Canada Base Map © Natural Resources Canada
/>


units
CBMTILE
method
GET
name
xmn
type
xmin
min
768
max
1024
/>
name
ymn
type
ymin
min
768
max
1280
/>
name
xmx
type
xmax
min
768
max
1024
/>
name
ymx
type
ymax
min
768
max
1280
/>
name
type
zoom
value
min
max
17
/>
name
projection
type
projection
value
CBMTILE
/>
name
type
location
units
tilematrix
axis
row
/>
name
type
location
units
tilematrix
axis
column
/>
type
tile
tref
/>



Please note that individual tiles are defined outside the section while the tile template has been moved inside the section.
Figure 2. Visualization of the static MapML Transportation map, usign tile URI templates.
Figure 3. Visualization of the static MapML Transportation map, using tile URI templates.
Most tile services are commonly based on the definition of URL templates favoring the transition to static MapML documents. Other services (e.g. WMS, WFS…) do not explicitly expose URL templates for accessing its resources. For that reason, it was not so obvious that the same approach could be extended to other kinds of information services.
The first case that is examined is the case of a map server that provides an image that covers exactly the size of the viewport. In this case, an OGC WMS instance is used.
Static MapML example for describing a OGC Web Map Service (from:
simplified)



href
/api/beta/mapml/en/osmtile/toporama/
/>


units
OSMTILE
name
type
zoom
value
18
min
max
18
/>
name
type
width
/>
name
type
height
/>
name
xmin
type
location
units
pcrs
position
top-left
axis
easting
min
-2.003750834E7
max
2.003750834E7
/>
name
ymin
type
location
units
pcrs
position
bottom-left
axis
northing
min
-2.003750834E7
max
2.003750834E7
/>
name
xmax
type
location
units
pcrs
position
top-right
axis
easting
min
-2.003750834E7
max
2.003750834E7
/>
name
ymax
type
location
units
pcrs
position
top-left
axis
northing
min
-2.003750834E7
max
2.003750834E7
/>
rel
image
tref
&
REQUEST=GetMap
&
FORMAT=image/jpeg
&
TRANSPARENT=FALSE
&
STYLES=
&
VERSION=1.3.0
&
LAYERS=WMS-Toporama
&
WIDTH={w}
&
HEIGHT={h}
&
CRS=EPSG:3857
&
BBOX={xmin},{ymin},{xmax},{ymax}
&
m4h=t
/>



Even if the WMS standard never mentions URI templates, the standardized Key-Value Pairs (KVP) notation can easily be expressed as a URI template. When a WMS URI template is used to include an image in MapML, all variables in the URI template should be stated as input parameters. Width and height are special cases because MapML does not imposes a map width or height; actually, they are only present if the MapML document has been included in a


If the web page is loaded into a web browser and the developer tools activated, the inspection of the page reveals that a request is done automatically to this URL:
, and the response is in a fully flagged MapML format that contains the needed features. In practice, if it contains other formats such as GeoJSON the other formats may also be supported. Support for other formats will make possible a connection with the new WFS 3.0 web services that the OGC is drafting.
Connection with the next generation of OGC web services
The OGC has recently been working on the next generation of WFS services (WFS 3.0) that has been completely remastered. Other OGC web services are being considered for a similar approach, that is based on OpenAPI. The adoption of an approach consistent with the current draft of WFS 3.0 can favor integration with the static style of MapML. The reason is that both (MapML and OpenAPI) have adopted the same URI template standard to define what is to be retrieved. WFS 3.0 lists resources that the service can offer in a OpenAPI document. Resources can be retrieved individually or as part of a collection. In the OpenAPI document, for each resource type a URI template is specified as well as all variables that the URI template contains, indicating the data type and the restrictions imposed on the values (including limits, enumerations, etc)
There are some differences: OpenAPI separates the variables that may appear before or after the '?' in the URI. The variable before the '?' are assumed to have order and are part of the URL template definition. Variables that appear after the '?' are assumed to be in KVP notation, do not have any order so they do not appear in the URL template (but are enumerated as variables needed by the resource path). To understand this better, consider how the WFS 3.0 OpenAPI defines the way a feature collection should be retrieved.
WFS 3.0 OpenAPI document fragment
/collections/{collectionId}/items
get
summary
'retrieve features of feature collection {collectionId}'
description
>-
Every feature in a dataset belongs to a collection. A dataset may
consist of multiple feature collections. A feature collection is often a
collection of features of a similar type, based on a common schema.\

Use content negotiation to request HTML or GeoJSON.
operationId
getFeatures
tags
Features
parameters
$ref: '#/components/parameters/collectionId'
$ref: '#/components/parameters/bbox'
components
parameters
collectionId
name
collectionId
in
path
required
true
schema
type
string
bbox
name
bbox
in
query
required
false
schema
type
array
minItems
maxItems
items
type
number
style
form
explode
false
Even if the authors of this document consider mentioning the difference, they do not perceive this as a problem. MapML can document a more restrictive URI template containing the query variables provided that the proposed template is compatible with the requirements of the WFS 3.0 (provided that the KVP syntax for the query variables is followed).
Interestingly, WFS 3.0 uses GeoJSON as a default encoding and WGS84 for the coordinates, which is compatible with the way MapML is defined today.
Implications for OWS Context
In OGC Testbed-13 there was a discussion on the similarities to other standards and in particular to OWS Context. The evolution of MapML into a more static client-server interaction moved MapML a step closer to OWS Context documents. OWS Context provides a way to create a document describing the viewport on an integrated client. OWS Context documents can encode the presence of one or more geospatial services that will be opened by a user interface when the document is loaded. There are still significant differences. In OWS Context, a sample of a server GET request is included instead of a URI template. There is an assumption that the client knows about the logic of the service requests and there is no need to include a URI template or any reference to variables on the URI template pattern. When writing a context document, developers can take the logical decision of at least providing a URL sample that that covers the viewport, but this is not mandatory in OWS Context. In other words, OWS Context assumes that the client is fully aware of the mechanics of the GET URLs used in OGC services and will be able to read the capabilities document, extract all the information it needs about the service and its layers and formulate GET requests when it needs it. In contrast, MapML provides the client with enough information to formulate GET requests for sending to the server by using URI templates and input variables, and does not require knowledge of the geospatial standard used in the request.
7. Feature Encoding
This section discusses approaches for encoding feature information in MapML. MapML features do not consider any form of vector tiles yet. Instead, features are provided as points, lines, polygons (and aggregations of them), the geometry of which is encoded as coordinates in one of the defined coordinate systems.
7.1. Current version encoding
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.
Code Example of a MapML containing embedded feature information

Alaska