On Thursday 16th of May at 12 o’clock the team presented the EOEPCA initiative in the Agora Metallica room.

Richard Conway, the EOEPCA Senior Software Architect, presented to the attendees the following points:

• EOEPCA context
• Process
• Use Cases
• System Architecture
• Processing and changing
• Resource Management
• User Management
• Conclusion

If you would like to see the full presentation, please click in the link below:

https://eoepca.github.io/resources/LPS19-EOEPCA-Workshop.pdf

The presentation went well and the number of attendees was over 30 people. Different companies participated in the event and in the QA session afterwards such as AirBus, Deimos, Solinex, Terradue, Atos, GMV, JNCC, Capgemini, Telespazio France, SISTEMA GmbH, T-Systems.

The presentation was followed by a QA session where the attendees had the opportunity to interact with the EOEPCA team and debate about the different aspects/challenges of the project. Please see below some of the very interesting questions asked:

Q1. Could the Common Architecture address other aspects of an exploitation platform such as high-performance computing?

A1. Ref. workshop slide 26 (Parallel Processing): The work of the OGC testbeds 13/14 only considers serial processing jobs running in a single Docker container. However, within the existing design there is a possible approach in which the Dockerized processor makes subordinate invocations to exploit some specific data processing compute cluster within the platform, e.g. processor is some python code that invokes a dask or SLURM cluster to perform its work. This would only work if the Platform to which the processor was deployed provided the expected compute service. Thus there would need to be a ‘contract’ through which the Platform declares the services it ‘Provides’, and the Processor declares the services it ‘Requires’. The orchestrator would rely on these declarations to ensure that processors are only deployed/executed on platforms that can support them.

Q2. It was stated that EO data must be FAIR (Findable, Accessible, Interoperable, Reproducible) and will not stay within the EO community

A2. The concept of ‘Reusable Research Objects’ is known to the EOEPCA team, and are seen as an approach in support of the FAIR principals. The Common Architecture will take the FAIR needs into account – see use case ‘Consumer performs Open Science’ (https://eoepca.github.io/use-case-analysis).

Q3. Confirm that UCs are open to community recommendations

A3. Yes. The Use Case document (draft) is published on GitHub (https://eoepca.github.io/use-case-analysis) and we encourage/welcome review and feedback – plus additional use cases that are not currently covered.

Q4. Note CEOS best practice, be wary of emerging standards that are not mature eg JSON LDs as deter take up

A4. The recommendation to follow the CEOS Best Practise is well noted. The JSON-LD approaches are being explored through current Testbed-15 – which we follow with interest. We are committed to follow a standards-based approach – including the evolution of standards where necessary. Our approach will be incremental to take account of such evolving standards.

Q5. Is the Common Architecture closed to companies that are not directly involved in its conception?

A5. No, quite the opposite. All technical documentation and implementation will be open source and available on GitHub. The Domain Experts will be ‘procured’ – specifically from companies across industry external to the system team. And we will continue to engage with the wider community to ensure a consensus-based approach is adopted.

Q6. Will data encryption to supported, particularly across platforms. Change of ownership of data?

A6. End-to-end data encryption has not previously been considered, but will be added as a use case for future consideration.

Q7. Are the OGC standards for interfaces at a level of maturity to be adopted?

A7. Standards will need to be evolved in partnership with OGC.  WPS is a standard and trusted. WPS-T is not yet a standard – it is being explored through the OGC Innovation Programme and is the subject of an OGC Software Working Group. Where the functionality required of the Common Architecture is not yet met by a standard, then it is necessary to evolve the standards. This is the approach being taken by working closely with the OGC.

Q8. Request for terminology clarification between standards and proposed standards, as proposed standards are not standards.

A8. Any suggestions?

Q9. Who are the stakeholders of this project?

A9. ESA through its technical officer Cristiano Lopes in the sponsor. There are many stakeholders in that this is intended to be an open architecture freely available to the EO community. Thus, stakeholders include existing and future platform providers, as well as their end-users.

Q10. What does the Common Architecture mean for existing deployment, such as TEPs?

A10. EOEPCA is not intended to immediately replace current EPs, but could offer an attractive evolutionary path where value is seen to be had. The idea is to try to create a digital market for interoperability, and lower the barrier to users coming to the market to access EO data.

Q11. Could you say more about Billing and Accounting features

A11. Based upon the ‘Platform Architectures’ session (Weds morning) – it is clear from the questions/discussion that billing is an important topic – and also a complex one. The current Common Architecture design has not yet considered the area of Accounting & Billing – except to recognise that it is a crucial problem to solve in the architecture. This topic may be left to the Domain Experts to advance. Some work on this topic has been made in the OGC testbed – the engineering reports will provide a useful input to the EOEPCA design.

Q12. Are block chains under consideration?

A12. Not specifically – but no technology is yet ruled out. In particular, if they can offer an approach to distributed accounting/billing, then this would be of interest.

Q13. Where do DIAS fit in to accounting and billing?

A13. DIAS are platforms a lower layers of the reference model, they are free to adopt the standards and interfaces offered by EOEPCA for their own market places.

Q14. Timeline for ITT and architecture implementation

A14. Domain expects ITT expected June, architecture will begin by refining architecture for 2-3 months, then begin incremental implementation, whilst continually reviewing it evolution

Q15. Architecture useful as well as reusable reference implementation components?

A15. Yes. There is re-use at (at least) two levels:- the architecture can be re-used as building-blocks/interfaces against which 3^rd-party implementations can be made; the reference implementation can be re-used as ready-made components to be adapted for platform deployments. All docs/software will be available on GitHub. In addition, we will provide support to developers in the re-use of these components.

Q16. How do you define success of this project?

A16. Success is related to achieving consensus and measured according to uptake by existing and future platforms.

Q17. When does funding project end?

A17. Funding for phase 1 ends Nov 2020. There is provision in the contract for a follow on phase (2).

The European Space Agency Living Planet Symposium is an event held every three years. This event focuses on how Earth Observation contributes to science and society, and how disruptive technologies and actors are changing the traditional Earth Observation landscape, which is also creating new opportunities for public and private sector interactions.

One of the themes of the Living Planet Symposium was the Space 4.0 and Earth Observation which aims to understand the technologies that impact on Earth Observation missions, data analysis and applications. Here is where EOEPCA comes to place as the initiative intends to become a widely adopted reference architecture and implementation for the future exploitation of distributed Earth Observation data and services.

The main objective of the EOEPCA team was to promote within the community and participants of the Symposium the Common Architecture benefits and how the process is intended to be run. The aim was to gather as much interest from the community (applications users, experts, platform providers, etc) as possible norder to collaborate together to build a consensus solution. 

The feedback of the community into the process is key in order to build this Common Architecture and to make sure that will be used by current and future EO Exploitation Platforms. Currently we are aiming to consolidate the use cases analysis to cover all the different cases. Feedback is really important for us, please find in our GitHub repository the following documents that need to be reviewed. 

• Use Case Analysis: https://eoepca.github.io/use-case-analysis/
• Master System Design: https://eoepca.github.io/master-system-design/

Collaborate with us in order to cover your use case!

Discovery is an art, at least if the desired object is more complex than a simple blog web-page such as this one. Here we are talking about discovery of Earth Observation (EO) products, services providing on-demand processing capabilities, and applications that are not deployed yet but waiting in an application store for their ad-hoc deployment and execution. The OGC Innovation Program has developed an architecture that allows the containerization of any type of application. These applications can be deployed on demand and executed in cloud environments close to the physical location of the data. Instead of processing ever-increasing amounts of data locally, the applications are transferred to where the data resides. But how to discover these applications? How to understand what data an application can be applied to? How to chain applications? How to combine applications with already deployed services that provide data and data processing capabilities? All these aspects are now in focus of OGC Testbed-15.

Discovery has been addressed in OGC for more than two decades. Several OGC and ISO specifications have been developed, such as ISO19115 Geographic Information: Metadata with its XML serializations and extensions defined in ISO19139 and ISO19139-2. Though proven to be powerful, recent developments prefer approaches that are based on OpenSearch formats and JSON encodings.

Let’s explore the current situation: we have a conceptual model for EO products and service discovery that is defined in OGC 11-035r1, the EO Product Collection, Service and Sensor Discovery using the CS-W ebRIM Catalogue. This specification is based on the previously mentioned ISO standards 19115 and 19139/-2, and serves as basis for modern metadata encodings defined in OGC 17-084, the GeoJSON(-LD) metadata encoding for EO collections. Figure 1 illustrates this composition of metadata models and encodings. OGC 17-084 re-uses GeoJSON and OWS Context properties but is designed towards ease of use. It minimizes redesign of properties by re-using properties from several existing namespaces, including Data Catalog Vocabulary (dcat), Friends of a Friend (foaf), Location Core Vocabulary (locn), PROV Data Model (prov), Resource Description Format (rdf), Simple Knowledge Organization System (skos), vCard Ontology (vcard), and several others.

Figure 1: Composition of modern metadata encodings (left) and OpenSearch response models (right)

The metadata side is complemented with OpenSearch response models as illustrated in figure 1. OGC 17-047, the OGC OpenSearch-EO GeoJSON(-LD) Response Encoding Standard, complements the OGC OpenSearch Extension for Earth Observation, OGC 13-026r8, which recommends the use of spatio-temporal filters defined in OGC 10-032r8, the OGC OpenSearch Geo and Time Extensions; and provides additional parameters to further constrain searches. The OGC OpenSearch Extension for Earth Observation uses the default response encoding Atom/XML. With GeoJSON and JSON-LD, OGC 17-047 provides alternative encodings. Using JSON-LD instead of GeoJSON allows to define each property explicitly as a URI, and thus increases the level of interoperability.

Testbed-15 will now explore first the capabilities of OGC 17-084 to express EO collection metadata, and OGC 17-047, to encode OpenSearch responses in GeoJSON(-LD). OpenSearch responses represent search results in containers with response entries as resources that may include hyperlinks. These allow further exploration of search result details by executing further searches, which allows multi-step discovery processes. In addition, Testbed-15 will experiment with faceted search as defined by OASIS. Applications will be handled as dcat:Data Services types. The challenge is to model the additional deployment information for each application. Other elements, such as access constraints and result access paths, are similar to already deployed applications that are made available in the form of Web services.

On the catalog side, substantial modifications to existing OGC Catalog Service - Web instances are foreseen. Any app-store depends on a (transactional) catalog that allows the registration of new apps, services, and deployment & execution environments. Testbed-15 will develop a Web-API based on the OpenAPI specification that gives both human users as well as machines full control over the registered items.

Further information on the current progress of Testbed-15 is available on the Testbed-15 webpage. While the deadline for responses to the Call for Participation (CFP) has passed, offers of in-kind contributions will still be considered. Anyone interested in shaping the direction of future OGC Initiatives, such as the upcoming Testbed-16, is urged to contact techdesk@opengeospatial.org or submit an idea to OGC’s Innovation Program Ideas GitHub Repository.