Testbed-15 Call for Participation (CFP)

Clicking on the Propose link will navigate to the Bid Submission Form. The first time through, the user should complete all the organizational information fields and click Update and Continue.

This will navigate to an "Add Deliverable" page that will resemble the following:

The user should complete this form for each proposed deliverable.

On the far right, the Review link navigates to a page summarizing all the deliverables the Bidder is proposing. Note that this Review tab won’t appear until the user has actually submitted at least one deliverable under the Propose tab first.

Once a submission has been received, the system will send an email to the bidder and to OGC staff.

The user is afforded an opportunity under Done Adding Deliverables at the bottom of this page to attach an optional Attached Document of explanation. If this attachment is provided, it is limited to one per proposal and there is a 5Mb file size limitation.

This document could conceivably contain any specialized information that wasn’t suitable for entry into a Proposed Contribution field under an individual deliverable. It should be noted, however, that this additional documentation will only be read on a best-effort basis. There is no guarantee it will be used during evaluation to make selection decisions; rather, it could optionally be examined if the evaluation team feels that it might help in understanding any specialized (and particularly promising) contributions.

The Propose link takes the user to the first page of the proposal entry form. This form contains fields to be completed once per proposal such as names and contact information.

It also contains an optional Organizational Background field where Bidders (particularly those with no experience participating in an OGC initiative) may provide a description of their organization. It also contains a click-through check box where each Bidder will be required (before entering any data for individual deliverables) to acknowledge its understanding and acceptance of the requirements described in this appendix.

Clicking the Update and Continue button then navigates to the form for submitting deliverable-by-deliverable bids. On this page, existing deliverable bids can be modified or deleted by clicking the appropriate icon next to the deliverable name. Any attempt to delete a proposed deliverable will require scrolling down to click a Confirm Deletion button.

To add a new deliverable, the user would scroll down to the Add Deliverable section and click the Deliverable drop-down list to select the particular deliverable of interest.

The user would then enter the required information for each of the following fields (for this deliverable only). Required fields are indicated by an asterisk ("*"):

Cost-sharing funds may only be used for the purpose of offsetting burdened labor costs of development, engineering, and demonstration of initiative outcomes related to the Participant’s assigned deliverables. By contrast, the costs used to formulate the Bidder’s in-kind contribution may be much broader, including supporting labor, travel, software licenses, data, IT infrastructure, etc.

Theoretically there is no limit on the size of the Proposed Contribution for each deliverable (beyond the raw capacity of the underlying hardware and software). But bidders are encouraged to incorporate content by reference where possible (rather than inline copying and pasting) to avoid overloading the amount of material to be read in each proposal. There is also a textbox on a separate page of the submission form for inclusion of Organizational Background information, so there is no need to provide this information for each deliverable.

A Bidder proposing to deliver a Service Component Implementation should use the Proposed Contribution (Please include any proposed datasets) field to identify what suitable datasets would be contributed (or what data should be acquired from another identified source) to support the proposed service. Additional guidelines for this requirement can be found under Data Requirements.

This field Proposed Contribution (Please include any proposed datasets) could also be used to provide a succinct description of what the Bidder intends to deliver for this work item to meet the requirements expressed in Appendix B Technical Architecture. This language could potentially include a brief elaboration on how the proposed deliverable will contribute to advancing the OGC standards baseline (also see Standards Baseline), or how implementations enabled by the specification embodied in this deliverable could add specific value to end-user experiences.

However, to help maintain a manageable process, Bidders are advised to avoid attempts to use the initiative as a platform for introducing new requirements not included in the Technical Architecture. Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in initiative scope or not. Items deemed out-of-scope might be more appropriate for inclusion in another OGC-IP initiative.

The statements of work (SOWs) in the Participation Agreement (PA) contracts will ultimately require performance during initiative execution against the deliverables as described in the Technical Architecture plus any subsequent Corrigenda.

A single bid may propose deliverables arising from any number of threads. To ensure that the full set of sponsored deliverables are made, OGC might negotiate with individual Bidders to drop and/or add certain deliverables from their proposals.

Each cost-share request (i.e., a bid on a funded deliverable) is required to provide at least some level of in-kind contribution (i.e., activities requesting no cost-share compensation). As a rough guideline, a proposed deliverable should include at least one dollar of in-kind contribution for every dollar of cost-sharing compensation requested. All else being equal, higher levels of in-kind contributions will be considered more favorably during evaluation.

Some participation may be fully in-kind. However, to help maintain a manageable process, Bidders are advised to avoid attempts to use the initiative as a platform for introducing new requirements not included in the Technical Architecture. Any additional in-kind scope should be offered outside of the formal bidding process, where an independent determination can be made as to whether it should be included in initiative scope or not. Items deemed out-of-initiative-scope might be deemed more appropriate for inclusion in another OGC-IP initiative.

Any item proposed as a purely in-kind contribution to meet a requirement already included in the Technical Architecture will likely be accepted if it meets all the other evaluation criteria.

Assuming that this in-kind requirement has been met for every proposed deliverable, a Bidder must also meet the following conditions in order to enter a PA contract:

Please note that although the bid submission form requires labor-hour estimates for each deliverable, the Participation Agreement (PA) will almost never be a time-and-materials contract to reimburse labor-hours. Instead, each PA will be a fixed-price contract with a particular Statement of Work (SOW) listing the required deliverable(s). A payment schedule will be established so that Participants may submit invoices at various milestones.

Each selected Participant should designate a primary point of contact ("Primary POC") who must remain available throughout initiative execution for communications regarding status. The POC should identify at least one alternative point of contact to support the Primary POC as needed. The POCs should provide contact information including their e-mail addresses and phone numbers.

All proposals should include a statement attesting to the POCs’ understanding and acceptance of the duties described herein. This statement will be enabled by a simple check-box in the Bid Submission Form.

Selected Participants should provide a one-time Kickoff Status Report that includes a list of personnel assigned to support the initiative and assurance that the Participants understand the schedule for all of its deliverables. This report should be submitted in electronic form to a designated email address no later than the last day of the Kickoff event.

Participant Business and Technical POCs should provide, respectively, monthly business and technical progress and status reports due on the 3rd of each month (or the first working day thereafter) and covering the previous month.

Monthly Technical Reports will be accessible to all Stakeholders and should contain no confidential information (e.g., labor rates). Monthly Business Reports may contain confidential information and should be shared only with identified OGC POCs.

Any Participant who has a reliable forecast of what will take place in the remaining days of any particular reported month may submit its report early and subsequently report any urgent, last-minute updates via a follow-on email.

Detailed monthly reporting requirements and procedures will be provided during PA contract negotiation. It is likely that the Portal-based Actions feature will continue to be used for monthly technical reporting.

The IP Team Thread Architects will review action item status on a weekly basis with assigned Participants, who should be available for these contacts to be made. Additional details regarding project management activities during initiative execution can be found at Project Monitoring and Control.

As a preview, monthly technical reports will likely require the following information for each deliverable:

Participants should provide a Final Summary Report near the end of initiative execution. Detailed requirements and procedures will be provided during PA contract negotiation. These reports will likely require the following information:

Any timely Participant who is up-to-date with all the Monthly Technical Status Reports in the Portal will likely be permitted to optionally satisfy the first "in detail" requirement by merely referencing the detail already contained in the Monthly Technical Reports. Timely Participants may also be permitted choose to build their Final Summary Report in the body of an email if desired (or, alternatively, submitted as a document attachment).

At least one of Participant Technical POC should be available for regularly scheduled telecons for each thread in which it is participating. Weekly thread telecons will be conducted and recorded, (with occasional exceptions for events such as for OGC Technical Committee Meetings).

These telecons are intended to accelerate understanding and action regarding relevant initiative activities, particularly status of any risks or issues that might block or are blocking progress toward timely delivery.

Participants assigned as ER Editors may, with permission from the relevant Thread Architect, lead the substantive discussions during any ad hoc or regularly scheduled sub-thread telecons.

Participants should be able to utilize the following correspondence and collaboration tools:

The primary acceptance criterion for a document deliverable (e.g., an ER) will be approval from a Thread Architect to post the document to an OGC (members-only) folder called the OGC Pending directory. Permission to post will not be granted until the full OGC Testbed ER Development Process has been followed, including the step to request a review from an OGC SWG or DWG. All appropriate tooling should also have been utilized (ER Template, Asciidoc, GitHub), and the document should have achieved a satisfactory level of consensus among all assigned Participants.

In general, prototype component implementation deliverables (including services, clients, datasets, and tools) will be provided by methods suitable to its type and stated requirements. A service (e.g. a WFS instance or even an intermediary component) will be delivered by deployment for use in the initiative via an accessible URL. A client will be used to exercise a service to test and demonstrate interoperability. Components will be developed and deployed in all threads for integration and interoperability testing in support of agreed-upon thread scenario(s) and technical architecture. The Kickoff will provide the opportunity to establish many of the agreed-upon details. These technical artifacts could also be utilized for cross-thread scenarios in demonstration events.

More specifically, the first acceptance criterion for any component implementation deliverable will be a successful demonstration of capability in a Technology Integration Experiment ("TIE") test.

The next acceptance criterion will be assurance that the work-package ER Editor has access to sufficient documentation material to record all findings and recommendations in the ER and associated CRs.

Another criterion will be evidence that the implementer has directly authored full ER content for any relevant Abstract Test Suite (ER Template Annex A), XML Schema Document (ER Template Annex B), or UML Model (ER Template Annex C).

A Participant assigned to deliver a client component implementation should, in addition, record TIE test execution (as evidence of delivery).

A Participant assigned to deliver a service component implementation should, in addition, provide assurance that the service endpoint will remain available to OGC and Sponsors for a period of no less than one year after initiative execution. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

A Participant assigned to deliver a service component implementation should, in addition, identify of one or more particular datasets that would be suitable for the proposed service. Details are provided under Data Requirements for Proposing Service Component Implementation Deliverables.

Some requirements might request delivery of a packaged prototype component (e.g., using a virtual machine or container). Consult the specific language in the Appendix B Technical Architecture for details regarding these requirements.

Under the CFP, all selected component implementers will be required to contribute "Demo Assets". These Demo Assets will be used to help compose outreach and communication artifacts toward the end of the initiative. There may also be other demonstration opportunities such as during an ER Editor’s presentation to a Working Group (e.g., the target SWG/DWG that agreed to review the ER). It might also appear in a focused event such as an ESIP Meeting.

These Demo Assets are not required to be professional-grade videos (which are not easily produced and can consume a lot of time and effort). Here a representative example of a Demo Asset from Testbed-13.

Also, some component implementers may seek permission to simply point to another Participant’s Demo Asset (e.g., a video recording of a client interacting with a back-end service that was delivered by that Participant).

Component implementers will also be permitted to create more intricate demo assets that will be considered for upload to the OGC YouTube channel. But these additional videos will be optional, not mandatory.

There will be no independent dedicated initiative "Demo Event" as has taken place in some prior initiatives.

A Bidder proposing to deliver a prototype service component implementation should provide detailed information regarding what data would be contributed (or what data should be acquired from another identified source) to support the proposed service. Some initiative Sponsors might provide data, but it might also be necessary to complement these with additional datasets.

A Bidder may propose any option that would be suitable to meet the technical requirement stated in the Appendix B Technical Architecture. Here are some examples to illustrate what options might be suitable:

Any datasets that are not intended to be made public can be protected by a click-through license which restricts access solely for use in support of the initiative and which proscribes any additional release, reproduction, or use.

OGC Testbed threads require several types of deliverables. Deliverable indications "funded" or "unfunded" are provided in the CFP Main Body. Please make sure you understand your tasks and provision requirements according to Annex A.

The OGC Reference Model (ORM) version 2.1, provides an architecture framework for the ongoing work of the OGC. Further, the ORM provides a framework for the OGC Standards Baseline. The OGC Standards Baseline consists of the member-approved Implementation/Abstract Specifications as well as for a number of candidate specifications that are currently in progress.

The structure of the ORM is based on the Reference Model for Open Distributed Processing (RM-ODP), also identified as ISO 10746. This is a multi-dimensional approach well suited to describing complex information systems.

The ORM is a living document that is revised on a regular basis to continually and accurately reflect the ongoing work of the Consortium. We encourage respondents to this CFP to learn and understand the concepts that are presented in the ORM.

This Annex B refers to the RM-ODP approach and will provide information on some of the viewpoints, in particular the Enterprise Viewpoint, which is used here to provide the general characterization of work items in the context of the OGC Standards portfolio and standardization process, i.e. the enterprise perspective from an OGC insider.

The Information Viewpoint considers the information models and encodings that will make up the content of the services and exchanges to be extended or developed to support this Testbed. Here, we mainly refer to the OGC Standards Baseline, see section Standards Baseline.

The Computational Viewpoint is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution. It captures component and interface details without regard to distribution and describes an interaction framework including application objects, service support objects and infrastructure objects. The development of the computational viewpoint models is one of the first tasks of the Testbed, usually addressed at the kick-off meeting.

The Engineering Viewpoint is concerned with the infrastructure required to support system distribution. It focuses on the mechanisms and functions required to:

It exposes the distributed nature of the system, describing the infrastructure, mechanisms and functions for object distribution, distribution transparency and constraints, bindings and interactions. The engineering viewpoint will be developed during the Testbed, usually in the form of TIEs, where Testbed participants define the communication infrastructure and assign elements from the computational viewpoint to physical machines used for demonstrating the Testbed results.

The OGC Standards Baseline is the complete set of member approved Abstract Specifications, Standards including Profiles and Extensions, and Community Standards.

OGC standards are technical documents that detail interfaces or encodings. Software developers use these documents to build open interfaces and encodings into their products and services. These standards are the main "products" of the Open Geospatial Consortium and have been developed by the membership to address specific interoperability challenges. Ideally, when OGC standards are implemented in products or online services by two different software engineers working independently, the resulting components plug and play, that is, they work together without further debugging. OGC standards and supporting documents are available to the public at no cost. OGC Web Services (OWS) are OGC standards created for use in World Wide Web applications. For this Testbed, it is emphasized that all OGC members have access to the latest versions of all standards. If not otherwise agreed with the Testbed architects, these shall be used in conjunction with - in particular - Engineering Reports resulting from previous Testbeds.

Any Schemas (xsd, xslt, etc.) that support an approved OGC standard can be found in the official OGC Schema Repository.

The OGC Testing Facility Web page provides online executable tests for some OGC standards. The facility helps organizations to better implement service interfaces, encodings and clients that adhere to OGC standards.

OGC also maintains other documents relevant to Innovation Program initiatives, including Engineering Reports, Best Practice Documents, Discussion Papers, and White Papers.

All participants are encouraged to provide data that can used to implement the various scenarios that will be developed during the Testbed. A number of Testbed sponsors will provide data, but it might be necessary to complement these with additional data sets. Please provide detailed information if you plan to contribute data to this Testbed. Additional guidelines can be found under Data Requirements.

Participants are encouraged to provide data or services hosted in the cloud. There is an overarching requirement to provide cloud-hosting capabilities to allow thread participants to move services and/or data to the cloud.

Dependencies between threads have been minimized. In some rare cases one thread uses components from another thread. In this case, the thread providing components used by another thread need to provide the relevant components in time. No cross-thread dependencies exist where component developers from disjunct threads need to agree on a common interface. The interface is always defined within a single thread exclusively.

Recent advancement in Artificial Intelligence (AI) has demonstrated the value of using Machine Learning (ML) approaches for automated image and vector data processing. However, the availability of data to efficiently train ML models is still an issue. A large variety of geospatial data are available through standardized OGC interfaces that could facilitate the discovery and access to datasets used to feed ML tools.

The Testbed-15 Machine Learning (ML) task will help to explore the utility of existing OGC Web services (OWS) to support a large scope of ML tools including EO data processing, image classification, feature extraction and vector attribution. The key research question is how these various ML models can be integrated best within standards-based infrastructures. These infrastructures include OGC Web services that interface any kind of data repository from rather stable image archives to Big data sensor data archives or real time systems.

It is expected that this task approaches the machine learning model development in a holistic way, focusing on the models itself as well as their integration into OGC Spatial Data Infrastructures equivalently.

All machine learning models shall provide WPS interfaces, ideally of the latest WPS generation that provide OpenAPI-type resource-oriented interfaces. Though the full implementation of Web services providing the access to the results of the ML models is not expected in this Testbed, the design of standardized ML interfaces shall explore how ML tools would access and publish their input and outputs using OWS. This research may also suggest a path for the development of future OWS.

Develop a set of machine learning models and explore their usage within OWS Web service based environments. Though the various machine learning models are in focus of this task, their integration within OWS Web service infrastructures, usage of catalogs and dynamic binding of data and services are equally important. It is emphasized that this task is expected to approach the machine learning model usage in a holistic way.

The interface component of machine learning models development should focus on inputs and outputs based on standards including OGC standards. This testbed should demonstrate and describe how OGC Web Services available in the list of CGDI Web services and elsewhere can be utilized; it should also inform how OGC standards can be used and advise whether they should be amended to better support Machine Learning and Linked Data environments. Other existing and emerging standards and open platforms from ISO, IHO, W3C, WMO, Global Biodiversity Information Facility, Arctic SDI and others should also be leveraged.

The following reports serve as a baseline for this task:

This task has five different scenarios. Each scenario focuses on a different machine learning challenge and needs to be implemented as an individual demonstration scenario. Nevertheless, all five scenarios shall cooperate on the integration challenge mentioned above. It is emphasized that the fourth model, the Richelieu Hydro Linked Data Harvest, focuses more on the Semantic Web link building and triplet generation aspects, whereas the fifths model, Arctic web services discovery, focuses on discovery and cataloguing aspects.

Each model shall be integrated with different types of OGC Web service instances for training and execution. Partly, these instances are provided by the sponsor, partly the participants shall access other resources available online. One option that shall be explored in Testbed-15 is feeding services provided by the CGDI as potential data sources to all machine learning models to fill data gaps and to reduce the need for new data acquisition that will lead to more application development eventually. For sure, all participants are invited to setup additional Web service instances.

All work items have been illustrated above. The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

Engineering Reports

Components

Dissemination of GeoINT data in a Denied, Degraded, Intermittent and Limited (DDIL) Bandwidth environment is a challenging problem. Providing prioritised delta updates can be a good approach to resolve this problem.

A delta update is defined as an update that only requires the system to download the new changes and not the whole database. Depending on DDIL conditions (or other constraints), the server might decide to further reduce the amount of update data. Depending on the applied classification schema, the server may only send top priority updates in bad DDIL conditions and further updates once conditions improve. This is important as it significantly saves time and bandwidth.

Emerging OGC interface specifications that use OpenAPI provide the ability for OGC standards to incorporate delta updates utilizing the Feature ID and Timestamp elements of OpenAPI. This allows for raster or vector data to be updated while still reflecting the changes in the original version.

The key research question is how to implement reliable and secure delta update mechanisms with OGC next generation Web Services such as WFS 3.0 and WPS 3.0. The research shall include different mechanisms that either require enhancements to existing WFS 3.0 instances, or use to be developed WPS 3.0 instances to realize similar functionality without touching existing data access services.

Describe and demonstrate how OGC standards can be used to provide delta updates to data using services in a Denied, Degraded, Intermitted or Limited Bandwidth (DDIL) environment.

The following reports serve as a baseline for this task:

The diagram below shows different scenarios that shall be all considered in Testbed-15. In the first scenario (interactions (1) and (2)), the Client node requests an initial set of data directly at the Data Server. Two alternatives shall be considered: First, the server stores references to all initially synchronized features and provides a set identifier (SetID) that can be used by the client in future calls. This requires the server to handle some form of state to manage the sets. The client then requests updates to these sets: “Provide me all top priority updates for SetID-1 since 2018-11-26T12:00:00”.

Alternatively, the data server does not provide any set identifiers. Then, client nodes need to use feature identifiers in future calls to identify interesting features, e.g. “Provide me all top priority updates for the following features since 2018-11-26T12:00:00; featureID-1, featureID-2,…​”.

To leave existing data servers untouched, an alternative scenario two exists that makes use of a WPS instance to handle the synchronization between the client and the server node (steps 3-5). Here, the client identifies the initial synchronization set and the WPS instance handles all delta updates.

Testbed-15 shall research the different options as illustrated in the two scenarios. Further on, it shall address interrupted communication situations where synchronization messages are interrupted or lost. Clients as well as servers shall be able to handle prioritization of delta updates. Based on some sort of classification system, delta updates will be prioritised by the client and or the server. The client may indicate bad communication ahead and requests only top priority data, or the server has knowledge about the client’s context and reduces delta updates autonomously. Once DDIL conditions improve, delta updates shall ensure fully synchronized client and server nodes again.

Prioritization can depend on different classification schemas. Either data is already tagged as e.g. normal, priority, and top priority; or depends on the client’s context. An example of context could be the client is an autonomous vehicle and it requires the latest transport updates relevant to its route.

Testbed-15 shall implement the scenarios using a WFS 3.0 and a WPS 3.0. The implementation

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

In Testbed-15, it is of interest how security works at a Feature Level as well as its implications as a data burden on the network. With focus on the actual interactions and general workflows, Testbed-15 shall answer the question how data centric security can be applied to OGC standards based architectures:

The Testbed-15 work on data centric security is considered being a first step towards fully exploited data centric security in standardized geospatial data infrastructures. This work in Testbed-15 shall lay the foundation for those future activities by clearly describing the challenges and opportunities of data centric security and provide a critical inventory of existing OGC specifications and approaches.

Testbed-15 shall capture and discuss security aspects of the full data lifecycle as illustrated below.

One important aspect is how existing OGC solutions, such as GeoXACML and security framework elements such as context handlers, policy administration points, or policy information points can be mapped to data centric security terminology. For example, data centric security terms such as Identity and Access Management (IdAM), Key Management, or Object Release are used in the scenario description below.

Implement a Data Centric Security approach using existing OGC standards and emerging OGC standards (such as WFS 3.0 or WPS 3.0 that make use of OpenAPI) as being documented in Testbed-14. Demonstrate how data centric security can be implemented for a scenario described below. Provide a detailed discussion that can be considered as foundational work for future OGC IP activities that discusses the research questions posted above.

The following reports serve as a baseline for this task:

Data Centric Security in the Testbed-15 scenario has separated the feature and the metadata as separate entities, both of which shall be separately encrypted with different encryption keys. The scenario in the diagram below shows a number of different clients. All are viewing the same map, but due to the sensitivity of the data, each client can only see the features on the map that the client is authorized to see. This is reducing complexity of the map, while protecting the sensitivity of the different data features. The general interaction between client and cloud based server is illustrated in the figure below.

Testbed-15 shall develop an implementation of WFS 3.0 with support for data centric security. This implementation is to learn from recent OGC Security work in OGC Testbed - 14: Security Engineering Report (18-026) and OGC Web Services Security Standard (17-007r1). Where necessary also reference previous Security work in other OGC Innovation Initiatives. This work will also reference STANAG 4774 – Metadata Confidentiality Label Syntax and STANAG 4778 – Metadata Binding Mechanism. Geospatial eXtensible Access Control Markup Language should be referenced.

Testbed-15 shall implement the scenario using a WFS 3.0 with tagged data and metadata, both encrypted with different encryption keys. The implementation

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

Previous OGC Testbeds have addressed a number of issues related to supporting analytic workflows where the data and analytics are hosted or deployed in an ad-hoc manner on multiple heterogeneous clouds that belong to different administrative domains. It is time for the OGC to assess the sufficiency of that body of work and identify areas were additional work is needed. This assessment should be performed through a proof of concept executing a non-trivial analytic mission leveraging data and analytics hosted on two or more clouds.

Of particular interest in this context are three aspects. Firstly, the handling of security in federations. Second, how the Testbed-13 and Testbed-14 research results of "bringing applications to the data" relate to SCALE and SEED. SCALE is an open source system that provides management and scheduling of automated processing on a cluster of machines. It uses the SEED specification to aid in the discovery and consumption of processes packaged in a Docker containers. Third, the role of blockchain and distributed ledger technologies in the context of handling provenance in federations.

This task is organized in four separate sub-tasks. The following research questions shall be addressed:

The aim of this task is to understand how emerging technologies and architectures featuring distributed cloud environments can be successfully integrated with OGC standards to support non-trivial analytic missions.

The following reports serve as a baseline for this task:

This task has four different sub-tasks. Each sub-task focuses on a different federated cloud challenge and needs to be implemented as an individual demonstration scenario. The list of sub-tasks includes:

All work items have been illustrated above. The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

Engineering Reports

Components

Despite the previous efforts referenced above, what is still missing in OGC is a robust conceptual model and APIs capable of supporting multiple style encodings and the style encodings themselves. This task will develop an Open Portrayal Framework (OPF) to address this issue. The OPF will leverage recent OGC portrayal efforts including Testbed-14 and the Vector Tiles Pilot. It will also address methods to style tiled vector data, Elevation Data, Routes and Points of Interest (online and - equally important - offline; including GeoPackage) to increase real-world utility, i.e. it clearly extends beyond tiled vector data. The result of the Open Portrayal Framework initiative will be a candidate international and NSG standard for geospatial portrayal, aligned with modern Style encoding, tools and approaches. The OPF shall be exercised in various ways, featuring GeoPackage, WFS, and WMTS technologies.

This task also recognizes that WMTS is one of the most implemented OGC technologies within geospatial enterprises and essential to online/offline display environments - and future Open Portrayal Frameworks. Its tile-based operations are also used by major data providers including satellite imagery organizations. Therefore, the second goal of this task is the definition of an OpenAPI based WMTS, following principles set by WFS 3.0.

Finally, this task recognizes that Portrayal display environments must have the latest satellite and aerial imagery – which will be challenging as hundreds of new commercial satellites and other sources are deployed. To meet this challenge a Transactional WMTS (WMTS-T) will be defined.

The aim of this task is to create an Open Portrayal Framework, to advance WMTS to support OpenAPI, and to add transactional capabilities to WMTS. the Open Portrayal Framework shall be exercised in various ways to strengthen the robustness of the conceptual and metadata models and to ensure robust interoperability in real world situations.

The following reports serve as a baseline for this task:

The Portrayal scenarios integrate the three topics introduced below, the Open Portrayal Framework, the WMTS 2.0 with OpenAPI support, and its transactional extension. It is emphasized that all groups participate in the development of the conceptual model and the metadata model as well as implementation tests. The list of tasks provided below provides additional requirements for the various teams to work together.

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

Engineering Reports

Components

Describe and demonstrate how OGC standards can be used or have to be extended to provide for discovery and use of EO data processing applications that can be deployed and executed by the user or are already deployed and available behind standardized OGC interfaces. Demonstrate how existing and emerging systems as deployed by e.g. NASA (e.g. NASA DAACs and NASA DASS), ESA (ESA TEPs) or systems that have already integrated various nodes such as the Earth System Grid Federation (ESGF) can be federated to allow for cross-platform analysis and visualization of data.

The following reports serve as a baseline for this task (not all of these reports are publicly available yet, as the OGC voting and release process is currently ongoing. They can be made available upon request):

The discovery solution in principle comprise the following building blocks:

It is important to recognize that the Catalogue Service must serve the needs of browser-based users requiring a user interface for their catalogue interactions, as well as the machine-to-machine interface that can be exploited for scripted and automated interactions.

It should also be considered that Discovery is not simply limited to a single cloud platform, but should also consider the requirement to catalogue external services – for example, a catalogue that federates the offering of multiple platforms by crawling their contents or query them in real time. The Testbed-15 solution will be tested with platforms provided by NASA, ESA, and ideally the ESGF.

A Data Model should be defined that provides:

The application packaging strategies devised in Testbed 13/14 go some way to describe aspects of this model. These should be analyzed as a starting point, potentially re-using any useful concepts and thus maintaining consistency.

The Service (Management) Interface should provide the following capabilities:

Many possible approaches to this problem are possible and the participants should be ready to analyze as many as possible, weight Pros and Cons and decide on an approach that reduces as much as possible the burden to future end-users and service operators. The following are existing standards, concepts and/or models that should be taken into consideration:

Special emphasis is put on schema.org, which was recently discussed in several presentations at the AGU Fall meeting, December 2018, in Washington DC for science data discovery or as a baseline for JSON-Based Structured Data for Discovery, Access, and Usability of Earth observation data and products (see link)

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.

OGC CFP Work Items:

ESA ITT Work Items: