OGC Testbed-16: Machine Learning Engineering Report

The left side of the diagram illustrates the bundling of an ML instance into a Docker container. This Docker container is the execution unit for the ML instance once it is deployed to the ADES.

In order to make it discoverable, a catalogue record describing the details of the ML instance is created.

The bottom center of the diagram illustrates an exploitation platform to which the Dockerized ML model is deployed. Once deployed, the model can be executed using the Application Deployment and Execution Service (ADES) and the Execution Management Service (EMS) APIs.

The center of the diagram illustrates an Execution Management Service,(EMS).

The EMS interacts with a catalogue, illustrated in the top right of the diagram, to provide discovery capabilities for ML models and data.

Once a suitable combination of the ML model and input data has been identified, the EMS interacts with the ADES to coordinate execution of the model.

Once a ML model has been executed the EMS mediates handling of the results. This can involve passing the results (e.g. a GeoTIFF) directly to the client or publishing the results via OGC-based services (e.g. OGC API - Maps or OGC API - Tiles servers) for later retrieval. In the latter case, technologies such as MapML can be leveraged to view the results and federate with other authoritative sources.

For the Testbed ML activity, the preferred OGC interfaces are the those being defined for the OGC API framework. This section provides an overview of the specific APIs referenced in the Figure 3.

Two of the planned OGC APIs, such as OGC API - Features - Part 1:Core and OGC API - Features - Part 2:Coordinate Reference Systems by Reference, are official OGC standards. Others, such as OGC API - Processes or OGC API - Coverages, will become OGC standards sometime in 2021. Finally, several of the APIs (e.g. OGC API - Common, OGC API - Maps, OGC API - Tiles) are still under development within the OGC standards process.

OGC API - Tiles - Part 1: Core specifies the behavior of Web APIs that provide access to tiles of one geospatial data resource or more than one geospatial data resource. This standard defines how to discover which resources offered by the API can be retrieved as tiles, what are the tile matrix sets supported by the geospatial data resources, which are the limits of the tiled space and how to request one tile at a time.

OGC API - Maps - Part 1: Core describes an API that presents maps portraying data that has been rendered according to a style. The maps served by implementations of the draft OGC API - Maps Standard are retrieved as images of any size, generated on-the-fly, representing a geospatial extent determined by the client application, and with the styling also determined by the client application. When used together with OGC API - Tiles, the two APIs enable support for map tiles.

In this thread, a server was deployed that offered map and tile access OGC API interfaces to Sentinel S1A and S1B satellite imagery from Canada and to the Canvec Series of Topographic Data of Canada. Both the Sentinel and Canvec data were used to train ML model and as input data when executing trained models.

Since forest fires regularly occur in Canada, obtaining knowledge on water bodies that are candidates for serving water-bomber planes or helicopters is of high value. Many of the natural water bodies in the Canada backcountry vary in extent and water level. A ML model can provide insightful information using up-to-date radar measurements such as Synthetic Aperture Radar (SAR) data. Therefore, the goal was to train a model with historic SAR data and corresponding labels in order to apply the model to recent SAR data.

A specialized convolutional neural network (CNN) for training the model was used. This was the U-Net CNN developed for biomedical image segmentation. U-Net provides very good performance using modern GPUs, applying a segmentation of 512x512 images (the size of a tile) in approximately one second.

A dedicated data retrieval process was used to download the tiles for a specific area of interest from the prototype OGC API - Tiles instance. The retrieval process was implemented using a Jupyter Notebook and is available at https://nbviewer.jupyter.org/github/52North/testbed16-jupyter-notebooks/blob/master/ml/tiles/tile-resolution.ipynb. The prototype OGC API - Tiles integration made the usage of training data seamless and straightforward. The amount of training data can be very easily be scaled by applying a larger area of interest. The only mandatory manual step was the identification of the optimal zoom level. This was due to Sentinel-1 data only providing limited spatial resolution.

The model was then executed using the set of downloaded tiles. The matching tiles of the Sentinel-1 and the water body label data share the same file name in different folders which allowed the application of the U-Net segmentation in an efficient manner.

The model trained with the tiles can then be applied to other Sentinel-1 scenes. The only prerequisite is that the scenes are pre-processed in the same way as the retrieved tiles were. Using GeoTIFF as the input format, an output raster (also GeoTIFF) with Boolean pixel values (1 = water body) can be created. An example is illustrated in the below Figure (base layer © OpenStreetMap contributors), where the red areas are the overlaid inference results.

The integration of the model into ADES follows the approach established during the former OGC Testbeds. In summary, a Common Workflow Language (CWL) definition is used as the interface between the model execution within a Docker container and the ADES. As the model has been manifested with the test data in the previous development steps, it has been integrated into a Docker image that allows a platform-independent execution.

The deployment of the model into the ADES followed the approach established in previous OGC Testbeds (see: OGC Testbed-15: Machine Learning Engineering Report and OGC Testbed-14: Machine Learning Engineering Report). Specifically,

The CWL workflow definition used in this thread is provided below. An ADES can invoke the workflow using any number of CWL runner applications such as cwltool or cwl-runner.

The following listing illustrates a CWL job that can be used to execute the model:

The Docker image used in the ML Testbed activity for the D132 component holds two independently trained models:

The model parameter allows the selection of one of these two model.

The inputScene parameter references a raster scene to process and should match the pre-processing and data format of the referenced model (GeoTIFF in this case).

Since 1990, wildland fires across Canada have consumed an average of 2.5 million hectares a year. Even if these events represent a natural component of forest ecosystems maintaining forest health and diversity, this is a challenge to forest management entities. This is because the events at once can be potentially harmful (risky for human being, a threat to communities and infrastructures, can destroy vast amounts of timber resources resulting in costly losses) and beneficial (renewing and maintaining healthy ecosystems and enhancing ecological conditions and eliminating excessive fuel build-up). Beside natural fires and prescribed burns set by authorized forest managers, some uncontrolled wildfires are started by lightning or human carelessness. Being able to properly plan, control and respond to this very complex phenomenon is thus both a critical and vital component of forestry and emergency management in Canada. Artificial Intelligence (both Machine Learning and Deep Learning) presents a valuable opportunity thanks to multiple sources of geospatial information like satellite imagery and data coming from the Canadian Geospatial Data Infrastructure (CGDI).

Within the frame of the activities carried on in D133 Machine Learning Environment 2 deliverable, participants explored how to leverage ML technologies in dynamic context like wildland fire planning and response, exploiting the use of OGC Standards.

The aim of the D133 deliverable was to provide a common framework for supporting Machine Learning (ML) applications by:

While the focus of the activity focused on the design and development of the framework, an ML model to estimate fuel loads from Sentinel-1 data was developed and deployed in the framework as a test case to show overall framework functionality and to provide real a sample use case.

In the specific context of Testbed-16, the input data is discoverable at the following URL:

https://eratosthenes.pvretano.com/cubewerx/cubeserv/default/ogcapi/catalogues/collections/tb16cat

The catalogue (compliant with the draft OGC API – Records specifications) contains several Sentinel-1 acquisitions to be used as input to the ML model for both training and inferencing as well as calculating total biomass ground-truth.

Sentinel-1 acquisition can be downloaded via a standard HTTP request using the URL link found in the metadata returned by the catalogue. The ground-truth, instead, is served by exposing a standard OGC WMS service exposing the total biomass estimations (layer tot_bio_r).

Several interesting outcomes come with this activity. A framework has been implemented that can be used as a skeleton for theoretically any Machine Learning model (thanks to Input / Output adapters) and virtually coping with tons of different heterogeneous data sources. The modularity of this framework also permits any extension on any step of the whole chain. For instance, it would be possible to change to final output just by simply swapping the MapML with a different standard and only updating the relevant Output Adapter maintaining the rest of the structure as is with no impact and side effects.

As already highlighted in Testbed-15, speaking merely about development, having plenty of Python libraries available that implement OGC standards is really useful, and also having the ADES WPS server already available has been a valuable benefit. Further, having the framework encapsulated in a Docker container helped a lot to test the whole application independently for the environment and to scale it in production.

The use of the draft OGC API - Records Standard eased the development and the querying mechanism having to deal with a single standard. Some additional improvements are needed (e.g. some specific identifiers to find exactly the resource and format needed). At the same time, it is really simple to integrate within the framework other catalogues served for instance by OGC CSW Standard and data providers exposing OGC WCS services for the data retrieval. In addition, just by upgrading the data loader component it would be possible to integrate additional repository like Amazon S3 / Google Cloud Storage.

The following list presents some additional notes suggested to be considered for future developments:

In conclusion, the team demonstrated not only the feasibility of an ML Framework Environment in a generic and complex context but also the potential added benefit of this approach in terms of modularity and expandability.

Machine learning frameworks like Pytorch or Tensorflow provide interfaces that help developers to build and run computation graphs representing neural networks. Most of those frameworks provide similar capabilities but have their own format for representing these graphs. The main goal of ONNX is to offer a unified system API for switching between machine learning frameworks. ONNX provides a definition of a computation graph model, and definitions of built-in operators and standard data types. Each computation dataflow graph is structured as a list of nodes that form an acrylic graph and each node is a call to an operator. The ONNX graph also maintains metadata to help document its purpose, author, etc. The idea is that a user can train a model with one tool stack and then deploy the model using another for inference and prediction. To ensure this interoperability the user must export this model in the model.onnx format which is basically a serialized representation of the model as Protocol Buffers (protobuf). More precisely, the objectives of ONNX are:

The main goal of this task was to explore possible metadata that could be extracted from LIDAR tiles that could be useful to build training and testing sets. About twenty tiles were downloaded from the New Brunswick website.

One issue in building a training task (or even testing) is to make sure that the training set is balanced with nearly the same number of samples per relevant classes. Therefore, the relevant information could be the class names with their frequency or occurrences. For instance, the following statistics can be extracted using lastools:

Lastools provides the number of points per class which can be useful to build a training/testing dataset. Also, the general metadata contains class definitions: Using a Python script and the LASTool library, metadata are extracted from the .laz tiles to form Feature records:

A GeoJSON encoding containing the Feature Collection is then pushed into a pygeoapi server (https://pygeoapi.io/) with the following configuration file:

Records are showing up on the server (http://localhost:5000/collections/nb_lidar/items?f=html)

Recommendations for the LIDAR records:

The objective here is to simulate queries of records that could be useful for ML. Unfortunately queries using CQL are too limited for the LIDAR use case as they cannot deal with vectors or arrays of values.

One possibility is to use ElasticSearch as a provider as it has a good query engine. Instead, the participants chose a Python query using QGIS API. In the code fragment below, the participants directly query the LIDAR collections to identify tiles that contain our class of interest (for instance buildings or water).

These tiles can be loaded directly into QGIS as a vector layer (http://localhost:5000/collections/nb_lidar/items?f=json&limit=20 ). The QGIS Python API can then be used to query the records directly:

Below are two examples of queries requesting some tiles with specific classes:

The goal of this task was to enable the querying of a catalogue of trained models. ML models are minimally defined by their architecture and their parameters resulting from the training phase. However, this information is insufficient to form a viable ML pipeline that can be executed on new data. In this case additional information must be provided:

Several ML libraries or frameworks provide ways to package ML pipelines, we can mention MXNet, TorchServe, TensorFlowX, thelper (https://github.com/plstcharles/thelper), MLflow (https://mlflow.org/).

MLflow (https://mlflow.org/) provides a fairly complete model development and management framework from model training to model packaging and deployment:

The testbed participants harvested metadata from a model repo containing MXNet models: https://github.com/awslabs/multi-model-server/blob/master/docs/model_zoo.md

An example is shown below for the Alexnet model:

Below are some possible queries that could be useful:

Once the model archive is selected, the content of the .mar archive can be used to initialize a model.

Or if the archive contains an ONNX file it can also be used to initialize a model within MXNet. Note that PyTorch can export in ONNX format but cannot yet import ONNX.

Some recommendations for the model metadata:

The LIDAR inference application was packaged using the thelper library. The resulting image provides thelper (via base image) and all its sub-dependencies (although it is not explicitly required by itself for this application).

Some of the tools from LAStools suite are commercial (cannot be used without licence), but laszip specifically is publicly available. The model targets specific version tracking using remote Git commit within the Dockerfile to ensure traceability in case of future updates.

The model targets specific version tracking using remote Git commit within the Dockerfile to ensure traceability in case of future updates.

The inference application defined by the Docker container is wrapped by CWL and deployed as process at the following URL location:

https://ogc-ades.crim.ca/ADES/processes/ogc-tb16-lidar

The definition of deployment and example job execution are available within the source code repository.

Once the inference is performed, the new .las is converted in a raster format (.tif) showing the classification values. This application is defined by a docker container wrapped by CWL and deployed as process at the following URL location:

https://ogc-ades.crim.ca/ADES/processes/las2tif

Example of a successful job execution: https://ogc-ades.crim.ca/ADES/processes/las2tif/jobs/6a22e5e7-adc4-457d-8468-93e02ea6b471

CubeWerx provided a catalogue for the Testbed-16 ML thread. The purpose of the catalogue was to provide the following services:

The CubeWerx catalogue implements the current draft of the DRAFT OGC API -Records - Part 1: Core standard but also includes an implementation of the draft OGC API - Features - Part 3 Filtering and Common Query Language (CQL) to provide additional, advanced query capability.

The catalogues deployed for the ML Thread can be found at this URL: https://eratosthenes.pvretano.com/cubewerx/cubeserv/default/ogcapi/catalogues.

At its core, the OGC API - Records specification uses the API defined by the OGC API - Feature - Parts 1: Core specification (with enhancements) and a datamodel composed of a set of core queryables that a catalogue implementation should use to describe resources.

The OGC API - Records - Part 1: Core specification defines the following conformance classes:

The core conformance class includes a set of core properties also referred to as core queryables and a set of core query parameters.

The list of core queyrables is provided in the following table:

The list of core query parameters is provided in the following table:

The bbox parameter is composed of either 4 or 6 number values that define a bounding box. The default CRS is http://www.opengis.net/def/crs/OGC/1.3/CRS84. Any record whose spatial component intersects the bounding box shall be included in the result set of a query.

Example: …​&bbox=43.5805,-79.6390,43.8782,-79.1569&…​

The datetime parameter is a string. The format of the string is an ISO8601 date string or period. The string '..' may be used to denote "since the beginning of time" or "to the end of time".

Example: …​&datetime=2019-10-01T13:45:17/2019-10-31T22:10:14&…​

The limit parameter is used to specify the number of records that shall appear in single response document. If there are additional records, next and prev links shall be included to allow navigation to the next or previous set of results.

Example: …​&limit=27&…​

The type parameter is a string. Its value is a type identifier and only records of that type shall appear in the response document.

Example: …​&type=http://www.opengis.net/def/object-type/ogc-csw-ebrim/0/dataset&…​

The externalIds parameter is a comma-separated list of external identifiers. Only records with the specified external identifiers shall appear in a response document.

Example: …​&externalIds=id1,id2,id3&…​

The sorting conformance class defines the sortby parameter. The sortby parameter is a comma-separated list of core queryable names. The results in a response document shall be sorted by the specified queryables in the order in which they are specified. Each specified queryable can be additionally qualified to indicate a sort direction.

Example: …​&sortby=modified:desc&…​

The core conformance class provides a minimum query capability via the bbox, datetime, type, q and externalIds parameters. The OpenSearch conformance class provide a additional level of query capability that is also compatible with the OpenSearch specification and the OGC® OpenSearch Geo and Time Extensions.

The OGC® OpenSearch Geo and Time Extensions extend OpenSearch to provide the following query capabilities:

The OpenSearch conformance class is presented here for completeness but was not used by ML Thread participants.

The JSON conformance class defines a JSON encoding for a catalogue record by mapping the core queryables into a GeoJSON object. This was the primary output format used by the Thread participants. The following is an example of a JSON-encoded catalogue record:

The ATOM conformance class defines requirements for an XML output format of catalogue records that conform to The Atom Syndication Format.

The ATOM conformance class is presented here for completeness but was not used by Testbed-16 ML Thread participants.

The HTML conformance class defines requirements for an HTML output format of catalogue records. The requirements basically recommends that catalogues implementing the OGC API - Records - Part 1: Core specification provide HTML as a supported output format. The following example illustrates a catalogue record encoded as HTML:

This client is developed to visualize the geographical data which is published via the MapML specification, generated by machine learning and deep learning modules. MapML is short for Map Markup Language. It encodes map information using text format for the World Wide Web [1]. The author of a HTML document should be able to use the <map> element and the link of a MapML document to declare a sub-area of HTML page to create a two-dimensional map with general map operations, such as panning and zooming. The MapML specification should ultimately provide a convenient and declarative manner for HTML authors to include maps in a web page. However, finding a browser that supports the MapML application is currently difficult. Therefore, a common solution is to implement the MapML specification via JavaScript. This client implementation was developed based on a JavaScript library called Web-Map-Custom-Element (WMCE).

Except for the supported general map operations, this client realized the multi-layer management. With the client, users can view all the maps/layers they are interested in simultaneously displayed over any arbitrary basemap. Many layer operations are implemented, such as adding, removing, toggling visibility, adjusting transparency, zooming to the selected layer, and etc., to meet the requirements of different application scenarios. Finally, this client is wrapped and published as a Progressive Web Application (PWA), so that the client acquires following advantages:

With the WMCE library, maps can be included in the HTML document just following MapML specification. An example using the <map> element is demonstrated in the below code snippet.

The <map> element declares a sub-area in the web page as a map viewer for displaying maps. The attributes of the element indicate the projection information and how the viewer is initialized, such as zoom level and center location.

By adding child <layer> elements to the <map> element, a certain map/layer can be included in the map viewer. This step can be accomplished declaratively while drafting the HTML document. It also allows developers to inject the <layer> element programmatically and dynamically, and this feature was used in the ASU client to add functions for adding and removing maps.

When declaring a <layer> element, only the "src" attribute is required, which provides the link directly to the MapML document. The label attribute is optional. This information can be automatically extracted from MapML metadata. Similar to other HTML elements, such as <img>, the source link of MapML can be hosted in any servers, from any origin. For instance, the two layers included in the above code snippet are hosted in different servers, from the US and Canada respectively.

The WMCE library extracts most metadata from the MapML documents and is accessible via <layer> element object. However, while developing the client based on WMCE library, the participants encountered different fashions of exposing the MapML metadata. Some simple information such as title and legend information can be acquired by a straightforward format, a short plain text or a URL. However, the complex information such as layer extent is wrapped in a MicroXML. Below is an example of a MicroXML of layer extent:

This requires applications to implement their own module to extract the extent coordinates, which should be a general function included in the library. Moreover, only the projected coordinates are provided in the MicroXML. Other supported coordinate systems are missing, such as the commonly used geographic coordinates. Communicating with WMCE side, all mentioned issues were fixed. The extent information is now wrapped in an object, shown as follows:

Now, extent coordinates are easily accessible, and multiple coordinates systems are supported.

To examine the functions of the ASU client and explore the capability of map customization in the context of MapML based implementation, ASU obtained some sample output datasets from machine learning and deep learning modules from the other Testbed-16 ML Thread participants. The output samples are all raster data and formatted as GeoTIFF. They are published via an OGC Web Coverage Service (WCS) endpoint leveraging GeoServer. A GeoServer MapML plug-in [2] wraps the published OGC services into MapML, which can be directly visualized in the client. The code snippet below presents an example of MapML document response from GeoServer:

This MapML document publishes the total biomass of the Petawawa area dataset. This document is mainly composed of title information, available projections and corresponding links, and the extent information. The following figure demonstrates how this layer is displayed in the ASU client.

From the MapML document it is evident that the tile data required to render the map on the page will be retrieved from a WMS endpoint. The WMS link is shown in the <link> element which is a child of the <extent> element in the MapML document above. The tile images retrieved from the WMS are rendered from the original WCS endpoint when publishing the data. Therefore customizing the style of the layer that is published via MapML on the client side is challenging because the client only has access to the rendered images rather than the underlying source data. The settled-upon solution to this styling problem was to edit the original GeoTIFF file to achieve certain style customizations and to publish the result as another MapML layer. The following figure presents the MapML visualization of the original total biomass layer and the one rendered with a red-yellow-green color ramp which indicates the value range from low to high.

The objectives for this deliverable were to:

Potential stakeholders included:

One goal of this work was to begin the process of gaining agreement from two or more browser implementers by focusing on a small primitive subset and getting feedback from framework authors and/or web developers.

A second goal was to follow the Extensible Web Manifesto, the WHATWG process and the W3C’s HTML Design Principles, and browser engines’ processes for shipping new features (e.g., the Chromium intent process).

The work involved four streams:

The following documents were reviewed as part of this work (each item is described in more detail below):

This review led to reporting several issues including with feedback and recommendations for a process for standardizing web maps to increase the likelihood of adoption among browser vendors. Details are provided below. The review also identified two missing web platform primitives that are fundamental to web maps’ interaction model: panning and zooming. An issue was also reported to the W3C Cascading Style Sheets Working Group to initiate a discussion.

An "explainer" is a short design document with code examples showing how the solution is intended to be used. The intended audience is the web developer. The W3C Technical Architecture Group provides a document on what the purpose of explainers and what they should contain.

Based on the evaluation the current MapML (Map Markup Language) proposal is not an effective explainer, and should be rewritten for clarity and brevity. The reasons are:

The full review is available at MapML-Proposal issue #17.

The HTML <map> Element proposal redefines the existing HTML <map> and <area> elements, and defines new <layer> element.

The finding was that the model for client-side image maps (the existing semantic of the <map> element) and web maps (the proposed new semantic) are fundamentally different. For the former, an <img> element renders the image, and the <map> only provides the association between the <img> and the <area> elements, while for web maps the <map> element owns the rendering and interaction model. For this reason, the recommendation is not to reuse the <map> element for web maps.

As discussed in the full review at HTML-Map-Element issue #97 there are additional problems with reusing <map>.

Sixteen specific issues were also raised, with questions and feedback on web compatibility, API design choices, and technical errors.

The Map Markup Language specification defines a new markup language, as a MicroXML format but inspired by HTML. Being MicroXML means that it is XML but without using any XML namespace.

In this blog post, there is a statement that MicroXML might not be the right solution, and instead suggests something more HTML-like: “The new document type should be readily parseable with a (minimally) enhanced HTML parser”.

In the <map> element proposal, it is defined that the <layer> element can optionally contain inline MapML markup.

For these ideas to work, all MapML elements need to be HTML elements directly. MicroXML cannot be used inline in an HTML document. By changing MapML to be a direct extension of HTML, the HTML parser can be used without changes.

The implications of this recommendation are reconsideration of the MIME type, the doctype, the root element, and audit all MapML elements for either reuse and extend an existing HTML element, or rename to avoid clashing with HTML.

The full review is available at MapML issue #70.

Another aspect of the MapML specification is its statement that it should be possible to style MapML documents CSS. This sounds good but it is unclear how this would work. In particular, CSS may need new primitives and possibly a new rendering model, such as panning and zooming. Rendering MapML content should then be defined in terms of CSS (see: MapML issue #71).

The Use Cases and Requirements for Standardizing Web Maps document has excellent structure and clarity. It does not leave the reader with questions and concerns as reading the explainer did. This document also provides a process for the work, and a plan for accessibility, privacy, security. There is no feedback for improvements to this document. A summary of this document would make for an excellent part of a new explainer.

The team participated in the joint W3C/OGC Maps for the Web Workshop in September-October 2020, and held a presentation to present the review of the MapML proposal:

Future work in this area should explore ways to collect additional input from various stakeholders. Ideas include developing a research design with questions for each group of stakeholders, and to reach out to them directly. For web developers, questions could be added to the MDN Developer Needs Survey to learn about their pain points with web maps.

See: D016 Machine Learning Training Data ER.

Additional comments follow:

See Standardizing Web Maps to Increase Adoption among Browser Vendors.

The ML models developed by testbed participants were deployed to an ADES which provides a standard interface for executing and retrieving results. Execution results, however, do not persist for any length of time which is an issue for any downstream actors that may want to use those results for further processing. Currently the only option is that the client retrieves the results and arranges for their persistent storage.

The discussion between thread participants consistently proposed alleviating the client of this burden and to have the ADES arrange for the persistent storage of results.

This solution involves having the ADES mount a persistent volume (e.g. Amazon’s EFS) onto the Docker container into which the results of ML processing are copied. When execution of the Docker container terminates, the results of processing would persist on the mounted volume and would be accessible from the host machine. The workflow would proceed as follows:

This solution for persisting the results of executing an ML model via the ADES involves pushing the results to an object store (e.g. Amazon’s S3 or Google Cloud Storage). The results can be pushed to the object store from within the Docker container or it can be done by the ADES after ML processes has completed. The results can then be pulled from the object store and fed into the GeoServer or directly to the MapML client.

The primary issue with the approach concerns the mechanism of interacting with the object store to retrieve the results. In most cases the job of forming an access URL involves credentials and signed HTTP requests and can be quite onerous. However, vendor-provided and open-source libraries are available that may mitigate this problem.

This solution makes use of an extended OGC API - Coverages interface that offers a /images endpoint. When processing results (e.g. GeoTIFF) are available they can be HTTP POST’ed to the /collections/{coverageId}/images endpoint and then subsequently retrieved using the OGC API - Coverages coverage access interface. An example of the images endpoint can be found here: http://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections/Daraa_mosaic_2019/images.

The primary issue with this approach, at least in the case of the CubeWerx server, is that the GeoTIFF results need to be orthorectified (see clause: D016 Machine Learning Training Data ER, Sentinel-1). However, assuming the results can be pushed to a coverage server, a client (MapML or otherwise) can simply make a standard OGC API - Coverages (or map request, or tiles request for that matter) to retrieve the results for display.

This issue was concerned with how to parse MapML documents available from the GeoServer module.

In principle, the HTML parser should be able to be used in JavaScript, but for the time being, the XML parser built into browsers provides a reasonable API that browser-based clients can rely on to parse MapML.

Ideally, Progressing Web Apps (PWA) could actually use the Web-Map-Custom-Element and its somewhat obscure JavaScript API. It remains to be specified what this API should be in the HTML standard and thread participants experimented with that.

It was felt by thread participants that the API should be similar to the Leaflet API, but there are obviously elements of the latter API which shouldn’t be specified by HTML, but by libraries built on top (i.e. like Leaflet itself).

Web-Map-Custom-Element, being HTML DOM based, presents a clean and straightforward API.

Because Safari doesn’t support customized built-in elements (<map is=web-map…>), another regular custom element called <mm-mapp> has been provided which works in a similar manner but does not support the <area is=map-area> element).

The idea is to eventually load the ML output into GeoServer, perhaps via an OGC API, and then GeoServer could automatically publish that data as MapML for consumption by the client.

While developing a MapML client based on the WebMap Custom Element framework an alternative way was found to expose the layer metadata provided by the framework. Some simple information such as title and legend URL can be acquired in a straightforward manner (by short text). However, the complex information such as layer extent is wrapped in a MicroXML which requires a standard manner to extract all effective information from it. Below is an example of a MicroXML of layer extent:

The sought-after feedback about Web-Map-Custom-Elements is:

The answers to these open questions can be found in the MapML Client 1 (D130 - ASU) and Standardizing Web Maps to Increase Adoption among Browser Vendors clauses.