Testbed-13 Call for Participation

The OGC Interoperability Program ("IP") provides global, hands-on, collaborative prototyping for rapid development and delivery of proven candidate specifications to the OGC Standards Program, where these candidates can then be considered for further action. In IP initiatives, Participants collaborate to examine specific geo-processing interoperability questions posed by the initiative’s Sponsors. These initiatives include testbeds, experiments, pilots, and plugfests – all designed to foster the rapid development and adoption of open, consensus-based standards. Additional information can be found in the OGC IP policies and procedures documentation.

The OGC recently reached out to potential initiative sponsors to review the OGC technical baseline, discuss results of prior initiatives, and identify current testbed requirements. After analyzing these inputs, the OGC recommended that the content of the testbed be organized around two parts, Part 1 CFP and Part 2 ITT.

A complete list of all testbed deliverables (including both Part 1 CFP and Part 2 ITT) is provided in the Summary of Testbed Deliverables section below.

Participants may play any of several possible roles:

In general, Bidders should propose specifically against the list of deliverables described under the Summary of Testbed Deliverables section below. But Bidders may go beyond funded deliverables to propose in-kind contributions that will address unfunded requirements as well. Participants should note, however, that Sponsors are committed to funding only those deliverables identified as being funded.

This testbed provides a business opportunity for stakeholders to mutually define, refine, and evolve services, interfaces and protocols in the context of hands-on experience and feedback. The outcomes are expected to shape the future of geospatial software development and data publication. The Sponsors are supporting this vision with cost-sharing funds to partially offset the costs associated with development, engineering, and demonstration of these outcomes. This offers selected Participants a unique opportunity to recoup a portion of their testbed expenses.

This Part 1 CFP incorporates the following additional documents:

Any Bidder interested in participating in this testbed should respond by submitting a proposal per the instructions provided herein. Limited cost-sharing funds are available to partially offset costs incurred by Participants in support of this initiative.

One testbed objective is to support the OGC Standards Program in the development and publication of open standards. Each Participant will be required to allow OGC to copyright and publish documents based in whole or in part upon intellectual property contributed by the Participant during testbed performance. Specific requirements are described under the "Copyrights" clauses of the OGC IPR document identified above.

The OGC Principles of Conduct document identified above will govern all personal and public interactions in this initiative.

To submit a response proposal, complete the two Response Templates (narrative and financial) and email them as attachments to the OGC Technology Desk at techdesk@opengeospatial.org. Any of the following attachment output formats is acceptable:

Part 1 CFP proposals must be received at OGC before the appropriate response due date indicated in the Master Schedule.

For a Bidder’s response to qualify for consideration, the response must provide all required information in accordance with Part 1 CFP instructions, including those contained in appendices and the two templates. Please note that the Financial Response Template contains one worksheet for a cost-sharing request and another for in-kind contributions. Bidders must use these templates in preparing their proposals.

Note that proposal reviewers will be instructed to avoid reading or evaluating any material in excess of stated page limits.

Once the Part 1 CFP is issued, potential Bidders will be permitted to submit questions to support their proposal development and submission. Questions should be emailed by the Bidder-question due date (indicated in the Master Schedule) to the OGC Technology Desk (techdesk@opengeospatial.org). Question submitters will remain anonymous, and answers will be compiled and published in a regularly updated CFP clarifications document. OGC may also choose to conduct a Bidder’s question-and-answer webinar to review clarifications and invite follow-on questions.

Selected Participants will not be reimbursed for any of the following:

Organizations responding to this CFP, are invited to express their interest in being considered by select venture capital investment firms (VCs) regarding elements in their testbed proposal. OGC has teamed with the venture capital firm Data Tribe. OGCs role is to assist in the alignment of interests. After identification of common interests, OGC will introduce the VC and the Participant, and subsequent discussions should take place directly between these two parties.

If your organization is interested in coordinating with a VC, include a statement in your response to that effect, including an identification of the specific technology areas that should be considered by the VC. An outline of testbed technology areas appears below. Additional technical details can be found in Appendix B, including an overview of thread allocations for all work packages.

Additional technical details can be found in Appendix B, including an overview of thread allocations for all work packages.

Additional technical details can be found in Appendix B, including an overview of thread allocations for all work packages.

The following requirements apply to the proposal development process and activities.

Proposal evaluation criteria are listed in the main body of this document. Several steps conducted solely by the IP Team are presented below to aid readers in understanding the overall process. The IP Team and Sponsors will begin reviewing proposals soon after the proposal submission deadline. During this analysis, the IP Team may need to contact Bidders to obtain clarifications and better understand what is being proposed.

Testbed execution will commence with a Kickoff Workshop event ("Kickoff"). Refer to the Master Schedule for the target date(s). Each Participant must attend the Kickoff of any thread for which it was selected.

Prior to Kickoff, each Participant should have executed a Participation Agreement (PA) contract with OGC. Each PA will include a final description of all assigned deliverables (potentially including any mutually agreed modifications to the CFP requirements).

By the commencement of Kickoff, any Participant which has not yet executed a PA will be required to attest to its commitment to a preliminary PA Statement of Work (SOW). The PA must then be executed with OGC no later than Kickoff completion.

The Kickoff itself will address two interdependent and iterative development activities: (1) component interface and protocol definitions, and (2) demonstration scenario development. The scenarios used in the testbed will be derived from those presented in the CFP and other candidates provided by OGC and the sponsors.

Kickoff activities might include any or all of the following (note that there could be multiple iterations of interface definition and scenario development breakouts, and these may be interleaved):

One of the Kickoff work products will be a development schedule that includes more detailed milestones for subsequent activities.

Each work item in a labor funding request or in-kind labor contribution declaration (1) must identify the particular Deliverable from the Summary of Testbed Deliverables to which the work item applies and (2) must identify the particular Technical Activity Type for the proposed activity to perform the work item. The mandatory narrative and financial response templates will assist Bidders in meeting these requirements.

An extended outline of predefined Technical Activity Types is provided below. Each work item that a Bidder proposes or declares must either match (approximately) one of these types or provide an explanation and justification for why the proposed work item does not match anything from the list.

Adopting predefined activity types will help maintain consistency across Participants during testbed execution.

Under the testbed’s rapid pace, exposed issues can drive requirements for subsequent rounds of specification refinement, coding, and test. Guided by the thread architect, each cycle will proceed incrementally but rapidly, with focus on a bounded scope at each turn of the cycle. Periods of development will be followed by periods of synchronization between various component developers, enabling issue resolution before divergence can occur between the various components that must interoperate.

This type of activity would integrate, document, and test functioning interoperable components that execute operational elements, assigned tasks, and information flows required to fulfill a set of testbed requirements. Particular Testing and Integration Activity Types that may be specified in the Proposal include the following:

This type of activity involves the development of draft compliance test guidelines (at a minimum) and test suites for engineering specifications detailed in Engineering Reports. This type of activity would likely include coordination with the OGC Compliance Program. Particular Compliance Test Development Activity Types that may be specified in the Proposal include the following:

This Annex B provides background information on the OGC baseline, describes the Testbed-13 architecture and thread-based organization, and identifies all requirements and corresponding work items. For general information on Testbed-13, including deadlines, funding requirements and opportunities, please be referred to the Testbed-13 CFP Main Body.

Each thread aggregates a number of requirements, work items and corresponding deliverables, which are funded by different sponsors. The work items are organized in work packages that correspond to one or more related requirements. The work packages have then been assigned to 6 Threads:

Testbed-13 is organized in a number of threads. Each thread combines a number of work packages that are further defined in the following chapters. The threads integrate both an architectural and a thematic view, which allows to keep related work items closely together and to remove dependencies across threads. The following figures illustrates the allocation of work packages to threads.

Each of the following sections provides a detailed description of a particular work package.

Nowadays Earth Observation satellites generate Tera to Peta bytes of raw data each year. When looking at the future, new high-resolution sensors, either multi-, super-, or hyperspectral, will lead to even higher data quantities to be processed. This huge amount of data needs to be stored, preserved, processed to higher levels and be distributed to the user communities Cossu et al. At the same time, Earth Observation commercial data sales have increased a 550% in the last decade. The field is considered a key element in the European Research Road Map and an opportunity market for the next years globally. The forecast for this decade is $4 billion in commercial data sales at the end of 2019. This makes EO a major field of new business opportunities and work (entice, Becedas et al, 2015a, Becedas et al, 2015b, Ramos, 2016).

Cloud computing is rapidly growing in importance for many organizations, with ongoing take-up of a wide range of cloud services and the transition of both data and applications to cloud computing environments. The topics of interoperability and portability are significant considerations in relation to the use of cloud services. Cloud computing is having an enormous impact on how organizations manage their information technology resources. The abundance of easy to access computing resources enabled by cloud computing provides significant opportunities for organizations, but poses challenges for enterprises in a number of areas. The current cloud computing landscape consists of a diverse set of products and services that range from infrastructure services (IaaS), to specific software services (SaaS) to development and delivery platforms (PaaS), and many more. The variety of cloud services has led to proprietary architectures and technologies being used by vendors, increasing the risk of vendor lock-in for customers. Incidents such as a cloud service providers shutting down operations or the discovery of significant security vulnerabilities in applications have highlighted this risk [Cloud Council, 2014].

Testbed-13 shall help clarifying the specific interoperability and portability concerns that arise in the large cloud eco-system with its variety of cloud services offered. From the interoperability perspective, in particular two aspects are of primary interest in T13:

Testbed-13 addresses key elements in cloud computing research, such as loosely-coupled PB-sized archives for rapid geospatial information product creation at any scale based on open standards. This work item on Cloud Computing Environment for Earth Observation Data shall be reviewed in conjunction with the Part 2 ITT issued through ESA EMITS. The goal is to develop an integrated solution that works for the ESA Exploitation Platforms as well as for the Canadian Forestry Service.

The topic of the Canadian Forestry Service application is extracting forest features or biophysical parameters from space-borne Synthetic Aperture Radar (SAR) and optical data products while using the synergistic combination of Earth Observation (EO) missions to estimate forest biomass in Canada.

Testbed-13 shall develop a cloud computing environment for Earth observation data (big data) that is integrated with OGC web services. The environment shall support hosting of data processing tools including all necessary deployment and management steps. The environment is illustrated in the following figure. The individual steps are further described below.

The cloud computing environment shall support the following aspects, indicated as steps in the figure above.

The actual cloud environment documented above shall be further developed into an operation model that would support (pre-)processing of high volumes of Earth observation data. This (pre-)processing is envisioned to be handled in the Cloud where processing power and storage can be elastic. In the Cloud, processors and storage can be increased or decreased when needed. Resources are only used when necessary thus reducing overhead costs of maintaining expensive servers or computing power.

Requirements for the operational Cloud model include:

The last point addresses a general aspect of concern in previous testbeds: The repeatability of test experiments. To allow testing/experiencing the cloud environment as developed during the testbed, the participants shall make use of tools such as AWS CloudFormation, Azure Resource Manager templates, OpenStack Heat, or - to remain more vendor agnostic - Terraform. Here, OpenStack Stack is the preferred platform, as the sponsor requires to re-install and run the orchestration on OpenStack Heat in their own private cloud environment. These tools allow the details of an infrastructure to be codified into a configuration file. The configuration files allow the infrastructure to be elastically created, modified and destroyed. Depending on the actual setup, additional tools for lower level configuration management such as e.g. Chef or Puppet may be applied to manage bootstrapping and initializing resources.

Applying cloud orchestration engine templates allows the participants to develop the cloud platform as described above, and sponsors with access to these scripts can re-hydrate the test environment whenever they want, e.g. one week later, or even 2 years later. It even allows the Cloud sponsors to execute test environments at any preferred scale in their own accounts.

OGC has addressed cloud technologies and several testbeds before. The work performed under this work item shall take previous work into account, such as Testbed 10 Performance of OGC® Services in the Cloud: The WMS, WMTS, and WPS cases.

Requirements

The following test case will need to be satisfied by the established environment for the environment setup and operation.

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

Testbed-12 introduced the Semantic Registry Information Model (SRIM), a superset of the W3C DCAT ontology and the Semantic Registry Service. SRIM can accommodate registry items other than dcat:Dataset, such as Service description, Schema and Schema Mapping description, and Portrayal Information (Styles, Portrayal Rules, Graphics and Portrayal Catalog), Layer, Map Context, etc. The Semantic Registry Service is used as an integration solution for federating and unifying information produced by different OGC Catalog Service information by providing a simplified access through hypermedia-driven API, using JSON-LD, Linked Data and HAL-JSON. During the testbed, the Semantic Registry was used to store information about geospatial datasets and services, schemas and portrayal information.

The Semantic Registry Information Model (SRIM), is defined as a superset of W3C DCAT standard and encoded as a OWL ontology. However, the OWL does not capture some of the semantic integrity constraints that are necessary to validate the instance information encoded using the SRIM ontology profiles. This is not an isolated problem. The DCAT ontology, for example, defines a set of classes and properties and reuses a large number of external vocabularies such as Dublin Core, but does not provide any restrictions in the ontology. Users have to read the profile documents such as DCAT-AP or GeoDCAT-AP to know which and how properties should be applied for a given class (mandatory, recommended or optional). For example, a Dataset could have only one title per language, or contact information should have either a person name, organization name or position name, and either email or telephone number. These kind of restrictions cannot be captured with OWL, and until now it required human interpretation to implement the constraints in code.

To fill these gaps, the emerging W3C standard called Shape Constraint Language (SHACL) provides a powerful framework to define the "shape" of the graph data and the ability to define complex integrity constraints using well-defined constraints constructs defined in RDF and SPARQL/Javascript constraints. SHACL is not a replacement of RDFS/OWL, but a complementary technology that is not only very expressive but also highly extensible. While RDFS and OWL are used to define vocabularies terms (classes/properties) and their hierarchies (subclasses, subproperties), as well as the nature of the classes and properties (union, intersection, complement of classes, transitive, inverse, symmetric properties, etc.), SHACL is more appropriate to capture the property constraints (cardinality, valid values or shape values and interdependencies between them) and capable of accommodating multiple profiles by providing different shapes for the same ontology. The SHACL vocabulary is not only defined in RDF itself, but the same macro mechanisms can be used by anyone to define new high-level language elements and publish them on the web. This means that SHACL will not only lead to the reuse of data schemas but also to domain-specific constraint languages. Furthermore, SHACL can be used in conjunction with a variety of languages beside SPARQL, including JavaScript. Complex validation constraints can be expressed in JavaScript so that they can be evaluated client-side. In addition, SHACL can be used to generate validation report for quality control with potentially suggestions to fix validation errors. Overall, SHACL is a future-proof schema language designed for the Web of Data. While SHACL is not yet a standard, there are already existing implementations using it (Topbraid for example).

Overall goal of Testbed-13 is to investigate the applicability of metadata sets provided by the sponsor to SRIM and consecutively improve interoperability between ISO and DCAT metadata, to improve the ISO/DCAT integration, and to analyze the usage of SHACL to constrain the content graphs.

Further on, it should be evaluated to which extent the SRIM API is or can be designed to match the SKOS and OWL vocabularies, taking advantage of the fact that most modern vocabulary content is structured using SKOS and OWL classes and predicates. This API can then be used as the basis for various higher-level vocabulary applications (NLP applications, Concept Recommender, Semantic Enricher, etc.). These, in turn, can be used to enrich, for example, ISO 19115 metadata and other OGC services using controlled vocabularies in their metadata.

Testbeds-11 and 12 have explored the high-level description of ontologies and schemas to support semantic mediation, see the OGC 16-059: Semantic Portrayal, Registry, Mediation Services Engineering Report, which documents the findings of the activities related to the Semantic Portrayal, Registry and Mediation components implemented during the OGC Testbed-12.

Testbed-13 should explore in more detail the kind of metadata needed to enable search on controlled vocabularies by defining an ontology that addresses the following aspects:

Based on this ontology, a standard REST API can be designed to search and access vocabulary metadata and their terms using best practices in REST API (hypermedia driven for example).

For Testbed-12, the Semantic Registry harvested information from a federation of CSW services as the focus was to exercise the Semantic Registry Information Model (SRIM) and the REST API. For Testbed-13, intent is to focus on improving the efficiency of the harvesting process by investigating the publish/subscribe protocol and versioning management of the register items in the Semantic Registry as they change over time.

Requirements

The following figure illustrates the work items and requirements in the context of DCAT/SRIM.

This work shall include:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

In recent years, the concept of data quality has generated a notable interest among SWIM implementers, both organization-specific and global. In the context of SWIM — and SOA implementations in general — data quality pertains to two major use cases, service advertising and service validation.

Both use cases share two common preconditions: (1) an unambiguous definition of the concept of data quality exists, and (2) a set of measurable parameters that allow specifying data quality is defined.

The successful completion of the artifacts specified in the requirements defined below may well lead to development of a Data Quality Assessment Service (DQAS). While the requirements and funding for supporting development of a DQAS have not yet been established, the following considerations are included so as to help future implementers to see the “whole picture”:

The DQAS work shall consider and extend a previously tested pattern for quality assessment, which separates the rules from the actual data and uses a Web Processing Service to apply the rules to data. In detail, this pattern includes:

Figure Data Quality Assessment activities depicts the activities that need to be completed to produce a prototype of a DQAS. It should be noted that the process of developing a DQAS as shown in the figure below will require further elaboration. It may include development of a test information service, a client, determining a type and format of data, and so on.

Requirements

The following figure illustrates the work items and requirements in the context of Quality of Service in the Aviation Domain.

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

One of the critical factors in the overall usability of services - and SWIM-enabled services in particular - is the ability of a service to be discovered. The ability of a service to be discovered is assured by providing a uniformly interpretable set of service metadata that can be accessed by a service consumer through a retrieval mechanism (e.g., a service registry). Such a set of metadata (commonly referred to as a service description) has been defined by FAA and EUROCONTROL and formalized in a Service Description Conceptual Model (SDCM). The SDCM is currently used in standard service description documents and service registries by both FAA and EUROCONTROL. As part of the effort of enhancing service discovery, both organizations also use a number of categories that can be associated with all services and are generally referred to as taxonomies. The current set of taxonomies used by both EUROCONTROL and FAA categorizes (tags) services based on their availability status, interface model, data product, etc. However, despite the increasing role of OGC-compliant services in the SWIM environment, no taxonomies for categorizing services based on geographical coverage or other geospatial characteristics have been defined.

Requirements

The following figure illustrates the work items and requirements in the context of Taxonomies in the Aviation Domain.

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

Summary: Testbed-13 shall investigate updates to OGC Web service interface specifications (WMTS, WCS, WFS, etc.) to allow a user to specify a “purpose” in the query requests rather than explicitly having to provide specific filter attributes. This would be valuable for end users that do not understand or know all the associated metrics, or even when they do understand them we continue to have the problem that providers do not use consistent metadata standards. This “purpose” abstracts the filter requirements away from the end user. The “purpose” would in essence be a reference to one of a set of predefined profiles which drive the selection criteria. Associated with this would be the need for a new OGC service operation to discover the available profiles. Within the testbed it shall be demonstrated how a user could discover available profiles and access data via these profiles within a client application. Ideally, Testbed-13 would show how these profiles can utilize metrics (like A3C quality metadata from Testbed-12) to allow clients to get more focused data responses using these profiles to better assess a true “Fit for Purpose” (FfP) response from the provider.

Background: End users likely understand that the use of imagery, imagery analytics or other forms of geospatial data may be used to address their specific problem space. Currently, it requires someone with geospatial expertise to know what geospatial products may be used, and how to discover and access this data. This is particularly difficult given inconsistency in the use of metadata standards across providers. OGC services currently help with the discovery and access of data, but we are still limited to the assumption that the client and client systems must explicitly provide the filter criteria to the servers in the discovery process. In order to open up geospatial data to broader markets, we need to reduce the level of complexity. Unfortunately the industry is actually moving in the opposite direction and has in fact become more complex for several reasons:

The goal of this testbed is to simplify the process for non-geospatial experts by standardizing a way that provider services can create and present predefined profiles (defined by the service provider) which are tailored to address specific use cases. By using the profiles the end user can be unaware of the actual details required by the backend system to perform the desired functions.

The following use case, focused on Testbed-13 mass population migration scenario, shall help directing the Testbed-13 developments on "Fit for Purpose" parameters.

A user is trying to understand and monitor refugee migration across several countries following a civil war in a neighboring country. The user is trying to determine the following:

The user is a non-geospatial user, but knows recent satellite imagery and other geospatial data should provide the information he needs. What the user needs is for the discovery and analysis tools to provide him access to the information based on his desired result. The ideal use case for the first question would look something like this:

Conceptual Implementation Example

Below is another example with some sample data for further clarification of the profile concept. An EO imagery provider defines several profiles for WFS as illustrated in Figure 2. Each attribute should be annotated with an optional description.

The key point here is that the provider, who knows and understands the metadata, can more effectively identify the best filter criteria for a certain function, but still provide via the overridable fields the ability to tailor the response.

Now imagine accessing the provider service through a client application. The user isn’t geospatial savvy so he navigates in the client system GUI to the point where he can access the predefined profile available for querying. The client system accesses the providers GetProfiles operation and retrieves a list of profiles. At this point the response includes all the profiles tagged as public:

The client system may categorize them by class or provide the full list without classes as defined by the client system code. Alternatively the user could supply a class filter “Land Use” in the GetProfiles query and get the following response:

The user is interested in the “Agriculture Land Registry” Profile and selects an option to retrieve additional details on that profile. The client system accesses the details via the GetProfileDetails operation and receives the following:

Some filters are fixed, while others allow the user to override the default parameter settings. This may be useful if the user wants to further restrict a parameter such as cloud cover to a smaller percentage than foreseen by the default settings. There are various reasons why certain parameters cannot be overwritten. They are still listed to allow the profile provider side to have a complete set of filter criteria, for documentation, or for provenance reasons.

In our little example, the user decides to use the “Agriculture Land Registry” profile, selects an area of interest, and initiates the query. In this case the user doesn’t intend to override any default values. The client system issues a WFS query that includes the geometry and reference to the desired profile. The WFS system returns several raw or finished products for the user to review:

Since the response may includes a large amount of data, even with the defined profile filtering, the client system can also use the defined profile as a way to prioritize and present the results. For instance, agriculture land use profiles may prioritize and list imagery which is the most consistent in age, whereas road detection would simply prioritize based on most current imagery first.

Summary

Today, we are trusting end users to properly query and find data that supports their particular use case. This means customer satisfaction is based on the knowledge of the user, of both the problem space and the provider metadata. The definition and use of profiles would move this need for knowledge back to the service provider, and provide a much easier interface experience for many users. The use of profiles would also insure that both the customer and the provider can be confident that the provided data will fit the purpose as defined by the profile – ultimately resulting in higher customer satisfaction.

Requirements

The following figure illustrates the work items and requirements in the context of Adding “Fit for Purpose” as a user parameter into OGC services.

The Testbed-13 deliverables shall meet the following requirements:

General Note: It is assumed that Testbed-13 would specify how to accept and use profiles, but not define what actual profiles should ultimately be supported, except to define some specific examples for use within the demonstration itself. The data providers would best know their data (both actual data and metadata) to know what profiles they can support and how.

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

Testbed-12 experimented with USGS Topo Map Vector Data Products being stored in GeoPackages. The results are documented in OGC 16-037. The focus of the Testbed-12 research was on generation of GeoPackages by combining USGS Topo Map Vector Data Products and the Topo TNM Style Template.

The resulting GeoPackages contain both features and instructions for styling of these features as well as orthoimagery, shaded relief raster tile sets, national wetlands raster tile sets and elevation data derived from USGS provide 1/9 arc second elevation imagery. OGC 16-037 explains the GeoPackage generation process, discusses problems and obstacles encountered decoding the source product and styles and converting these artifacts to a GeoPackage, and provides recommendations for improvements.

Requirements

Testbed-13 shall build on the Testbed-12 results and continue to investigate the OGC GeoPackage as a single alternative delivery format for the USGS Topo Combined Vector Product and the Topo TNM Style Template. The following figure illustrates the work items and requirements in the context of USGS Topo Combined Vector Product data to GeoPackage.

This work shall include:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

The Map Markup Language (MapML) format was created by Natural Resources Canada, and is managed in an open, collaborative process by the Maps for HTML Community Group.

Map Markup Language is a text format for encoding map information for the World Wide Web. The objective of MapML is to allow Web-based user agent software (browsers and others) to interact with web servers by relying only on publicly defined Web standards (URI, HTTP, MapML specification), and not on URL recipes/templates, with the goal of displaying modern interactive Web maps.

The MapML specification describes MapML as follows: MapML is needed because while Web browsers implement HTML and SVG, including the <map> element, those implementations do not meet the requirements of the broader Web mapping community. On the one hand, the semantics of maps are quite different from those of Scalable Vector Graphics, while on the other hand, the semantics of the HTML map element are incomplete or insufficient relative to modern Web maps and mapping in general. Robust web maps are implemented by a variety of non-standard technologies. Web maps do not work without script support, making their creation a job beyond the realm of beginners' skill sets. In order to improve collaboration and integration of the mapping and Web communities, it is desirable to enhance or augment the functionality of the <map> element in HTML to include the accessible user interface functions of modern web maps (e.g. panning, zooming, searching for, and zooming to, styling, identifying features’ properties, etc.), while maintaining a simple, declarative, accessible interface for HTML authors. At the same time, the HTML interface should provide low-level programmable mapping hooks in the style of the Web. While we’re at it, maybe we can improve the state of Web mapping by adopting and incorporating the core values of the Web, namely federation by virtue of hyperlinks and standardized media types.

MapML is a proposal to the Web and Mapping communities. The intention is to define a new hypertext format (MapML) which encodes map semantics directly, but which leverages existing standards where possible and desirable, such as Cascading Style Sheets, for example. MapML will provide an essential part of the contract between Web user agents and Web servers when map features are exchanged, in a manner based on the architectural style of the Web, in a similar way to how HTML provides (part of) the contract for documents.

A MapML tile servlet maven Java project is available on Github. A number of OGC compliant Web services that could be used to serve maps as part of the Testbed-13 implementations are available also here.

Related to the MapML specification is the <web-map> HTML Element proposal. The standard HTML <map> element allows the HTML author to designate sub-areas of an image to be used as hyperlinks, creating an "image map". This functionality while useful, is limited to the simplest of mapping applications. A more generally useful <map> element would enable (functions like) zooming and panning of the map in a traditional Web mapping way, while simultaneously being equally simple and declarative for an HTML author to include on their Web page. The HTML Element proposal specification proposes the syntax and semantics of such an element. Examples of how the web-map custom element works are provided by the Maps4HTML community. In addition, when an SVG document is included in an HTML document via the <img src=”….svg”> element, JavaScript embedded in the SVG document does not run, it is an inert picture, under the control of the HTML author, which is as it should be. But when it is the principal target of a browser request, and if it has internal links to JavaScript resources, those scripts are executed, just as they would be for an HTML document. Currently, MapML is only conceived as a somewhat non-static application executed in the context of a <map> element. But if a MapML document was the principal target of a request by a browser, could scripts linked by the MapML document work some magic? What would that magic look like? Would a MapML document need a DOM model that is analogous to the SVG DOM, which is effectively a JavaScript API? If this was the case, a web of maps might be useful even independent of the Web of HTML documents. This aspect is covered in requirement number 5 below and shall be investigated in Testbed-13.

The applications of Web maps are diverse. The wide scope of use of Web maps appears similarly broad to that of other Web media types, such as video or audio. In other words, there are a multitude of reasons for wanting to include a map on your Web page. The HTML <web-map> element proposed by this document should be provider-agnostic, and should only depend on Web standards, including Uniform Resource Identifiers, Document Object Model, Cascading Style Sheets and media types. To that end, the present specification is a sibling to another related specification proposal, that of Map Markup Language.

Requirements

The following figure illustrates the work items and requirements in the context of Map Markup Language.

The following requirements shall be met by the MapML Engineering Report and implementation:

The authors of MapML have tried their best to keep the definition of MapML, its schema and the implementation in sync, so as to try the best to eliminate cognitive dissonance from the mind of the reader (keeping it real). As a result there are things that could be added to address simple use cases, and possibly fixes or clarifications may be needed for existing things. In addition to these clarifications, Testbed-13 welcomes the imagination of the community to help realize some useful things using MapML!

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

A fundamental goal of this Mass Migration Source Integration work is to understand and document how information sharing and safeguarding interoperability tools and practices, including open geospatial standards, can enable cross-domain interoperability on an international level for structured, communication exchange and border surveillance for law enforcement and humanitarian aid including a Maritime context.

Testbed 13 will focus on addressing challenges related to the coordination of multi-regional / multi-national operations and messaging related to the displacement and mass movement of populations in response to conflict. The current exodus of people from the Middle East to multiple nations in Europe and other countries around the world will be used as a scenario for this discussion.

Testbed 13 supports the NASA Earth Science Data System (ESDS) Vision: "Make NASA’s free and open earth science data interactive, interoperable and accessible for research and societal benefit today and tomorrow". The Earth Science Data System (ESDS) Program oversees the lifecycle of earth science data with the principle goal of maximizing the scientific return from NASA’s missions and experiments for research and applied scientists, decision makers and society at large.

Testbed 13 results will be applicable to this ESDS Goal: Ensure access to data and services that are useful and useable by a wide community of users. To meet this goal, Testbed 13 will:

The first two elements are described in more detail further below.

To meet these goals, a pre-Testbed-13 concept development study, executed by OGC, will identify a number of data sets, portals, data centers, simulation models, and other Web services that can be used for the implementation of the demonstration scenarios around NASA ESDS data. OGC will issue a Request for Information (RFI) to its membership to solicit interest, experiences, and data and model availability. In this context, OGC will closely cooperate with ESIP to ensure close cooperation with ESIP partners. ESIP is an open, networked community that brings together science, data and information technology practitioners with the mission to support the networking and data dissemination needs of ESIP members and the global Earth science data community by linking the functional sectors of observation, research, application, education and use of Earth science. The OGC and ESIP have an Memorandum of Understanding (MoU) that promotes coordination between the two organizations on topics of common interest.

In addition, Testbed-13 participants are requested to help completing the set of available material. The overall goal is to gain experiences in the integration process, develop best practices and recommendations back to NASA on potential improvements that will further simplify the integration process, understand potential interoperability issues arising from different formats, interfaces, protocols, and access policies. The Climate Data Accessibility for Adaptation Planning work package shall be implemented as part of the mass migration scenario.

Improved climate data accessibility for the scientist and non-scientist

To broaden distribution access and formats of climate reanalysis, climate model data, and climate based observational data for ease of system-to-system ingest, access (EG: API, WCS, other), and data delivery formats (File: HDF, NetCDF, Shapefile, GEOTIF) for ingest by the scientist and non-climate scientist. Basis of requirements is that many needing climate reanalysis and climate model data (some cases observational data) do not have effective system-to-system access to climate model data and do not understand HDF, NetCDF, GRIB, or other data formats, nor do they want to learn to read these file formats, and are not climate scientists yet still need climate data for their work. The following use-cases shall be considered:

Broadening Climate Adaptation Essentials

Similar to the Testbed-11 activity focused to understand impacts of sea level rise, Testbed-13 shall broaden focus to understanding impacts to climate change by inland “drought and flooding” via climate prediction models (single model, ensemble, reanalysis, other) against global population centers. In support of the overall Testbed-13 theme of mass migration, predictions of drought that lead to mass migration can be a focus.

Requirements The following figure illustrates the work items and requirements in the context of Climate Data Accessibility for Adaptation Planning.

The Testbed-13 deliverables shall meet the following requirements:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables. Some of the work items are used in other work packages as well.

The public but proprietary Vector Tile Specification from Mapbox is becoming more widely adopted. It continuously develops towards advanced capabilities for client-side styling and interrogation of data combined with the benefits of caching and optimized encoding and transmission protocols. Whilst the specification explicitly defines that vector tiles should not contain information about the bounds and projection of the data within the vector tile, the projection of reference used is Web Mercator (EPSG:3857) with the Google tile scheme as the tile extent convention of reference.   For many use cases these will provide enough accuracy. However for many of the scenarios within a mass migration theme (for example emergency response at sea), other projections and a standards based approach to tile schemes may be required for interoperability and/or accuracy. Furthermore, the Mapbox Vector Tile Specification does not currently provide good support for moving features, likely to be of high interest in a mass migration scenario, where moving features (whether humans or resources) may require some form of continued communication and update into clients whilst still utilizing the benefits of caching and optimized encoding within the vector tiles themselves.

With respect to usage of Vector Map tiles, it has been shown that they are increasingly being considered as a method for providing geospatial data to users via optimized vector web services, (such as MVT.PBF services, e.g. Mapzen) over both enterprise and low bandwidth environments. However, current vector tiling implementations are focused on the tiling and styling of vector data. As such, specific concepts provided by current OGC Standards are not fully addressed. The goal is to develop a "best of breed" solution to cover vector tiling using key characteristics from existing services. These include:

As such there are several limitations associated with these implementations. These include:

Providing map tiles to users via optimized Web services or over low bandwidth networks enables users to integrate features, whilst benefiting from compression and generalization approaches. OGC 16-021 and 16-055 explored compression techniques, low bandwidth, generalization techniques and created implementation(s).

In OGC Testbed-12 two Engineering Reports, 16-067 and 16-068, examined vector tiling and documented an implementation. OGC Engineering Report 16-068 stated the different elements that incorporate vector tiling, these include:

Developing a standardized approach through an implementation would allow the demonstration of best practice approaches to these different elements. Vector tiling is incorporated into various existing OGC Standards, OGC GeoPackage, OGC Web Services, and OGC CDB (OGC Engineering Report OGC 16-067 explores this further). The goal is the optimization of OGC geospatial Web services to deliver faster, lighter and more robust services.

Requirements

The following figure illustrates the work items and requirements in the context of Vector Tiling.

Testbed-13 shall implement the following requirements:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

OGC recently approved the Common Database (CDB) Standards. The CDB standard was brought into the OGC at the request of United States Special Operations Command (US SOCOM), it is widely used in the Modeling and Simulation community. The standard, as currently approved, utilizes the old FACC format for Feature and Attribute encoding. The CDB Standards Working Group (SWG) has agreed to bring the standard current with the NSG Application Schema (NAS) Feature and Attribute encoding as part of a revised version. NGA has provided the NAS to the SWG for consideration. The CDB SWG has also agreed to engage with the CityGML SWG to support 3-D integration. The objective of this effort would be to build on the work of the SWG within the Testbed through in-depth analysis, rapid development and prototyping of data models and supporting services integrating NAS, CityGML and CDB.

The work on CDB is structured in three phases and shall include a feasibility study, the implementation of data models and schemas that are based on the study results, and a set of services that implement the data models and schemas in the form of OGC WFS and WCS. It is emphasized that these phases built on each other. Therefore, special timing requirements have to be met in order to allow all three phases to be implemented.

Requirements

The following figure illustrates the work items and requirements in the context of CDB.

This work shall include:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

The OGC has approved two new work items and the start of the review and approval process on independent Community Standards related to 3D capabilities with Streaming: 3D Tiles and Indexed 3d Scene Layer (I3S). NGA seeks to test the interoperability between the two specifications, formats and streaming capabilities.

The 3DTiles and i3s: Interoperability & Performance work package is organized in three phases. The objective of phase-1 is to conduct and document the results of a thorough feasibility study to investigate whether both specifications (3D Tiles and i3s) support interoperable data content, determine if the current software will support data based on the CDB/CityGML, and identify enhancements as needed.

The 3DTiles and i3s: Interoperability & Performance analysis in Testbed-13 shall provide a demonstration of all examined test scenarios. The demonstration shall include 3D data streaming capabilities supporting CDB and CityGML data streamed according to the 3D Tiles and i3s Community Standards. Ideally, this work takes the results from the CDB Feasibility Study as described in section CDB into consideration. As timing of this work is largely dependent upon the work of the CDB and NAS Profiling work described there, it is expected that preliminary work would utilize a non-specialized CDB/CityGML data set served through an i3s and a 3D Tiles server.

While the intent is to stream NAS based CDB and CityGML in their native formats, the results of the study may lead to recommendations for alternative solutions involving conversions into a common format. Testbed-13 is encouraged to evaluate all risks and potential payoffs of the innovative technology options that are investigated and recommend the option that best achieves the software interoperability objective of this technology pursuit.

The following picture illustrates the general setup of the performance and interoperability study.

Phase-2 builds on the results of the first phase and develops 3D Tiles and i3s enhancements as necessary to solve all interoperability issues resulting from the phase-1 study.

Phase-3 implements the urban centric scenario and a demonstration of i3s and 3D Tiles visualizations.

Requirements

The following figure illustrates the work items and requirements in the context of 3DTiles and i3s Performance. It is emphasized that the figures does not show all realization arrows to improve readability.

This work shall include:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

NGA utilizes the open source ShapeChange software tool as an integral piece in NAS development. This tool is used to take NAS based UML models and create XML and RDF based schemas. Testbed-12 began development of capabilities for extracting profiles supporting specific mission functions from the full NAS content in the previous testbed. Testbed-13 shall further refine this NAS Profiling by incorporating those capabilities previously defined for the purpose of developing a Urban Military Profile. This profile shall define the vector contents requirements for the CDB and CityGML urban centric profiles from the NAS described in section CDB. This profile shall be capable of being used to define the data model requirements for an Urban Military CDB and simultaneously an Urban Military Application Domain Extension (ADE) for use in CityGML.

The participant may require transforming the NAS Platform Independent Model to Platform Specific Models (PSM). This will require a flattening of the NAS to support Geodatabase and CDB/CityGML Platform Specific Models. This “backed in/flattening” for a PSM is necessary to assure interoperability of disparate developments/implementations. As an example, these are two of many effects of a “flattening transformation” (further details are given in the Testbed-12 ShapeChange Engineering Report (OGC 16-020)):

There are numerous other transformations that need to be performed, most generally that of transforming a multi-geometry entity into a set of single-geometry entities, and that of “migrating” selected attributes of selected associated-entities to the applicable geometry-centric entities.

The NAS Profiling work is organized in three phases. During the first phase, Testbed-13 shall conduct and document the results of a thorough feasibility study to investigate whether a strict subset of the NAS is capable of supporting an urban centric profile or whether additional content is required. This study shall identify any gaps in the CityGML standard towards supporting the development of a Urban Military Profile. Further the study shall make recommendations to overcome those shortfalls. The study shall outline the requirements to develop a NAS based Urban Military ADE for CityGML and an Urban Military Profile for a NAS based CDB.

During the second phase, Testbed-13 shall enhance ShapeChange to develop data models that meet the requirements for an Urban Military Profile. In addition, ShapeChange shall be enhanced to provide a user interface with the ability to generate profiles from the NAS. This user interface shall be able to present already produced profiles which can be edited to delete and add content from the NAS. The user interface shall also be able to generate profiles from scratch based on user input.

During the last phase, Testbed-13 shall provide models supporting the tailored urban centric scenario as described in the CDB work package.

Requirements

The following figure illustrates the work items and requirements in the context of NAS Profiling.

This work shall include:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

Not all systems reside on the World Wide Web. Many are hosted on Denied, Degraded, Intermittent, or Limited bandwidth (DDIL) communications environments. Testbed-13 will examine how OGC Services can be adapted to accommodate two properties which are common to many DDIL environments.

During the Testbed-11, portrayal ontology was introduced that was focused on point-based symbology (icons for Emergency Management). Testbed-12 has extended this work by providing a richer symbolizer and graphics ontology that can accommodate line and area-based symbols along with graphic attributes applicable to these symbols. The Testbed-12 work is described in the OGC 16-059: Semantic Portrayal, Registry, Mediation Services Engineering Report, which documents the findings of the activities related to the Semantic Portrayal, Registry and Mediation components implemented during the OGC Testbed-12. This effort is a continuation of efforts initiated in the OGC Testbed-11.

For Testbed-13, the intent is to extend the ontology to accommodate more complex symbols such as composite symbols and symbol templates to describe more advanced symbology standards such as the family of MIL2525 symbols. Testbed-12 work rendered a symbol legend based on their definition; however, more work is needed to develop a renderer based on data in the portrayal ontology and producing SVG.

Requirements

The following figure illustrates the work items and requirements in the context of Workflows.

This work shall include:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

This section has been merged with section Semantic Registry.

Web Services are built around a request response message exchange model. However, there are many times when the response cannot be delivered in a timely fashion. For example, RESTful operations are synchronous meaning once a request is issued, the client should wait for a reply. This is fine for normal Web surfing. It will not work for standing queries. In those cases the client may have to wait hours, days, or even weeks for a response. Testbed-13 shall explore two potential use cases with the goal of extending asynchronous capabilities for OGC services. The first use case relates to DDIL environments where users are constrained by their network capabilities and require a full update of their mission specific data over a temporary local area network as they come in proximity of this LAN. The second use case is one where a user issues a standing query to a service requesting notification of new or updated data as it becomes available over their area of interest.

The work shall take results from Testbed-12 into consideration: The Implementing Asynchronous Services Response Engineering Report (OGC 16-023) summarizes and compares the results from asynchronous communication experiments executed in Testbed-12. Testbed-12 implemented the WPS façade approach against WFS and WCS service instances, added support for asynchronous communication to a WFS using additional request parameters, and added Publish/Subscribe support to catalogs. Further details on the implementation of the Publish/Subscribe Interface Standard using catalogs are provided in the PubSub / Catalog Engineering Report (OGC 16-137).

It is envisioned that in the future analytic environment, analysts will no-longer have to search for content. Rather than a query-response model, analysts should be able to post their data requirements, then receive a notification whenever data is acquired which meets those requirements. The basic technology to do this is called publish-subscribe (pub-sub). However, pub-sub systems traditionally have been based on topics. Analysts will need a much more complex query language similar to the OGC Filter language.

The OGC Publish Subscribe Core Standard provides an overarching model to extend OGC services with Publish/Subscribe capabilities. The Publish/Subscribe model is distinguished from the request/reply and client/server models by the asynchronous delivery of messages and the ability for a Subscriber to specify an ongoing or persistent expression of interest (Standing Query). This model is particularly applicable to the DDIL environment because there is very little coupling between the service provider and consumer. Once a request has been issued, the results can be retrieved at a very different place and time.

The Testbed-12 PubSub / Catalog ER (OGC 16-137) provided a model for extending OGC services to support PubSub. It also applies that model to extend CS-W. Testbed-13 shall build on that work by applying the PubSub extension model to the Web Feature Service.

Requirements

The following figure illustrates the work items and requirements in the context of Asynchronous Services.

This work shall include:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

Testbed-13 shall develop CITE tests for NSG profiles. The work can build on previous work as documented on the CITE website. .

Requirements

The following figure illustrates the work items and requirements in the context of Compliance Testing.

This work shall include:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

The Testbed-12 WMS/WMTS Enhanced Engineering Report (OGC 16-042) describes requirements, challenges, and solutions to improve multidimensional Earth Observation (EO) discovery, data access, and visualization through WMS, WMTS, and corresponding extensions.

In the context of WMS, the Engineering Report provides solutions to better support NetCDF-CF data visualization and exploration, which is done by enhancing the GetMap operation to enrich map rendering options, and by improved Capabilities for long layer lists.

In the context of WMTS, enhancements have been developed to reduce semantic ambiguities when querying time-varying layers (i.e. layers with data that varies over time). This has been achieved by means of an enhanced time-query semantic and encoding model. Extensions to the Capabilities model now allow for more efficient data exploration even for long list of layers, and improvements to the WMTS client-server communication now reduce empty tile requests. These improvements are based on three operations to support efficient inspection of all layers and the discovery of relationships among multidimensional layers. The operation include DescribeDomain for compact domain inspection, GetHistogram for domain distribution inspection, and GetFeature for detailed value inspection.

Testbed-12 developed an initial version of a streaming LiDAR service. That service was limited to LAS formatted data and LAZ compression. Testbed-13 shall build on that work by introducing more complex point cloud data such as Geiger Mode collections encoded in SIPC format. In addition, Testbed-13 shall explore the suitability of this service for use in DDIL environments. In particular, it shall investigate:

Requirements

The following figure illustrates the work items and requirements in the context of Point Cloud Streaming.

This work shall include:

Deliverables

The following list identifies the work items assignment to requirements. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.