An instantiation of a ProductClass for a specific period of time (e. g. one orbit) and of a specific version. It is allowed to generate multiple products for the same ProductClass and time period, since equality of products is defined based on their attribute values.

Products are considered equal if either of the following alternatives holds:

• The database IDs are equal (inherited from PersistentObject)

• The UUIDs are equal or at least one of the UUIDs is null (i.e. they do not have different UUIDs)

• All of the following attributes are equal:

  • Product class

  • Configured processor

  • Sensing start/stop times

  • Processing mode

  • File class

  • Product quality

  • Production type

• All product parameters present in both products (additional parameters on either product will be ignored)

Note that the generation time is not considered relevant for product equality, because two processings with the same set of attributes as listed above are expected to produce the same output.

If a product is associated to an orbit, its validity period may still differ from the orbit times, but its validity end time must not extend further than into the following orbit (e. g. a near-realtime time slice beginning in one orbit, but also including some data from the subsequent orbit).

The root class of all persistent objects. It provides an ID, a version and a set of mission-specific parameters for the object.

This class allows to add mission-specific parameters to any persistent object. A parameter consists of a type (of the enum ParameterType) and a value with a class that corresponds to the type.
Example: Parameters for S5P include "collectionNumber", "revision" etc.

The Java data type of the parameter

An Earth Observation mission (currently only Sentinel-5P).

A spacecraft used for a specific Mission. A Mission may operate more than one spacecraft.

The payload of a spacecraft, e. g. the TROPOMI instrument of Sentinel-5P. A spacecraft may have multiple payloads.

The description of an orbit identified by its start and stop times (e. g. the "spacecraft midnight" events of the Sentinel-5P satellite). There must be no time gap between subsequent orbits of the same spacecraft.

Orbit times (and all derived times in prosEO) are given in UTC-STS (leap seconds spread evenly over the last 1000 seconds of the day) and to a microsecond precision. The public static variable orbitTimeFormatter gives a standard format for parsing and formatting orbit times.

Available archive locations for input products or auxiliary files. Product archives are by design mission-neutral, but the credentials may actually restrict an archive to a specific mission. In such a case, if the same endpoint shall be used for multiple missions, the product archives must be differentiated in their short codes.

Interface protocol to use for a Product Archive

A class of products pertaining to a specific Mission, e. g. the L2_O3 products of Sentinel-5P. A ProductClass can describe final (deliverable) products as well as intermediate products. For a ProductClass its dependency on base products can be described using SelectionRules. Alternatively a ProductClass may be composed of other product classes (e. g. the S5P NPP products consist of three separate single-band NPP sub-products).

Visibility of products to external users (internally all products are visible at all times)

Processing level, usually indicating the number of processing steps required to create a product of this class from unprocessed ("level 0") data. The enumeration values have been derived from a number of sources (listed below).

Justification: Informational attribute requested in ESA's Sentinel-5P Product Unit Definition and Metadata ICD (ESA-EOPG-EOPGC-SP-4, issue 1.4; a similar attribute will probably be requested for other Sentinel missions). In the framework of the Sentinel missions at least the following processing levels are used: L0, L1, L1A, L1B, L1C, L2, L2A, L2C. Processing of L3 products is planned for Sentinel-5P.

Sources:
[1] https://science.nasa.gov/earth-science/earth-science-data/data-processing-levels-for-eosdis-data-products/
[2] https://cera-www.dkrz.de/docs/PostprocessingLevelDescriptions_for_CERA.pdf (based on [1])
[3] http://uregina.ca/piwowarj/Think/ProcessingLevels.html
[4] https://sentinel.esa.int/web/sentinel/sentinel-technical-guides

A rule defining the required input ProductTypes for a certain output ProductType using an ordered list of SelectionPolicys. When selecting applicable Products for a JobStep the matching SelectionPolicy defines whether a Product satisfies a ProductQuery. Simple Selection Rules may be restricted to be applicable for only a well-defined set of Configured Processors.

A product retrieval policy consisting of a retrieval mode and a time interval with delta times as defined in Annex B of ESA's Generic IPF Interface Specifications.
Note: As a future extension selection policies based on spatial coverage are envisioned.

Class representing a single overlapping time period

Available policy types as defined in ESA's Generic IPF Interface Specifications.
Note: For Sentinel-5P only the policies LatestValCover, LatestValIntersect, ValIntersect, LatestValidityClosest, LatestValidity are used.

An instantiation of a ProductClass for a specific period of time (e. g. one orbit) and of a specific version. It is allowed to generate multiple products for the same ProductClass and time period, since equality of products is defined based on their attribute values.

Products are considered equal if either of the following alternatives holds:

• The database IDs are equal (inherited from PersistentObject)

• The UUIDs are equal or at least one of the UUIDs is null (i.e. they do not have different UUIDs)

• All of the following attributes are equal:

  • Product class

  • Configured processor

  • Sensing start/stop times

  • Processing mode

  • File class

  • Product quality

  • Production type

• All product parameters present in both products (additional parameters on either product will be ignored)

Note that the generation time is not considered relevant for product equality, because two processings with the same set of attributes as listed above are expected to produce the same output.

If a product is associated to an orbit, its validity period may still differ from the orbit times, but its validity end time must not extend further than into the following orbit (e. g. a near-realtime time slice beginning in one orbit, but also including some data from the subsequent orbit).

Quality annotation for products (determined by processor configuration)

Production context for the generation of a product (from the ESA PRIP API specification, ESA-EOPG-EOPGC-IF-3, issue 1.4, sec. 3.2)

History of product downloads; while originially bound to a ProductFile, the entry persists even after deletion of the ProductFile to give a full history of the Product downloads

The data file and pertinent auxiliary files for a product at a given processing facility. Each product has at most one data file representation at each of the processing facilities.

The available storage types

A type of processor capable of generating products of a specific set of ProductClasses. There can be only one ProcessorClass capable of generating products of any one ProductClass.

A specific version of a ProcessorClass. Each permissible combination of a specific Processor with a specific Configuration is modelled as a ConfiguredProcessor. A Processor can consist of multiple tasks (note: for Sentinel-5P only one task per Processor is expected).

A single, separately adressable execution step of a Processor. Tasks may be flagged as "external", in which case the input data products are forwarded to an external entity for processing, and the output products are retrieved from that external entity. (Level 4 "Task" from Generic IPF Interface Specifications, sec. 4.1.3)

A specific processor configuration, tied to a specific ConfiguredProcessor object. It mainly consists of a set of configuration files and template information for creating Job Order files for the associated processor.

A processor configuration file; configuration files must be provided statically to the processor container and will not be stored in the Storage Manager

Input files for inclusion in generated Job Order Files; these files will be stored in the Storage Manager and provided from there, if they have the file name type "Physical".

A specific version of a Processor combined with a specific Configuration object (i. e. a specific set of configuration data for the given processor version). A ConfiguredProcessor is what must be specified for the generation of the products of a prosEO order.

A Workflow is a template for a processing order. For On-demand processing it allows to select a suitable ConfiguredProcessor based on a given input product type (and possibly also an output product type). For Systematic Production it supports automatic generation of processing orders based on incoming lower-level products. Within a given mission, the combination of workflow name and version must be unique.

This class must not be confused with the generic concept of a "workflow" in the sense of chained processing steps, since such a concept does not exist in prosEO. The class name is derived from ESA's On-Demand Production Interface Delivery Point (ODPRIP) API.

Description of possible options, which can be set as "Dynamic Processing Parameters" in Job Orders created using the embedding Workflow

Allowed types for workflow options

A customer order to process a specific set of ProductClasses for a specific period of time using a specific set of ConfiguredProcessors. An order may have properties like a product quality indicator (test vs operational), specific product delivery endpoints, specific (potentially mission-dependent) product generation attributes (e. g. a Copernicus collection number) etc.

Filter conditions to apply to an input product of a specific product class in addition to filter conditions contained in the applicable selection rule

Set of parameters to apply to a generated product of the referenced product class replacing the general output parameters

Identification of the input product to use for On-Demand Production; its intention is to be unambiguous (as per ODPRIP ICD), however this is not guaranteed given the limited number of specification options (uniqueness may be guaranteed when specifying a file name, but it is not, when only specifying a sensing time range). The input product will be retrieved from some LTA, if it is not readily available in prosEO.

If only the "ContentDate" is given and multiple products fulfilling the criteria are found in the LTA or in prosEO, the product with the most recent generation time will be used. In the (unlikely) case of several products having the same generation time, the product with the greatest file name (alphanumeric string comparison) will be used. Duplicate file names are not allowed on any LTA or PRIP (and hence not in prosEO).

At least either the input file name or the sensing time interval must be specified.

The endpoint to send order completion notifications to

Possible states for a processing order; recommended state transitions:

• INITIAL -> APPROVED: Customer approved order parameters and/or committed budget

• APPROVED -> PLANNED: Jobs for the processing order have been generated

• APPROVED/PLANNED -> INITIAL: Reset order to initial state, deleting all existing jobs and job steps

• PLANNED -> RELEASED: The order is released for running as planned

• RELEASED -> RUNNING: The first jobs have started, further jobs can be started

• RUNNING -> SUSPENDING: Order execution halted, no further jobs will be started (started jobs will be completed, if they are not halted themselves)

• SUSPENDING -> PLANNED: All jobs for the order are either completed or halted (after suspending the order)

• RUNNING -> COMPLETED: All jobs have been completed successfully

• RUNNING -> FAILED: All jobs have been completed, but at least one of them failed

• PLANNED -> FAILED: The order was cancelled by the operator

• COMPLETED/FAILED ->; CLOSED: Delivery/failure has been acknowledged by customer and/or order fee has been paid

Possible methods for partitioning the order time period into individual job time periods for product generation

A collection of job steps required to fulfil an order for a specific period of time (e. g. one orbit).
Note: As a future extension a selection by geographical area in addition to or instead of a period of time is envisioned.

Enumeration describing possible job states.

A single processor execution to produce a defined output product based on a defined set of required input product (modelled as ProductQuery objects). A JobStep can be executed as soon as all its ProductQuerys are satisfied.

The possible processing states for a job step

A ProductQuery models the need of a JobStep to use a Product of a certain ProductClass for a specific time period. The time period can be defined by conditions, and a Product is said to satisfy a ProductQuery, if it matches the given conditions. A JobStep can be executed as soon as all its ProductQuerys are satisfied.

A processing facility for running prosEO jobs and storing prosEO product files, e. g. at a cloud service provider.

For the user as well as for planning and product access purposes it is important to know, whether a processing facility is operational or not. To this end the enumeration FacilityState provides the following values:

• DISABLED

• STOPPED

• STARTING

• RUNNING

• STOPPING

Allowed state transitions are DISABLED <--> STOPPED --> STARTING --> RUNNING --> STOPPING --> STOPPED.
Justification: Processing facilities may be taken down for maintenance, and processing facilities may be defined before they actually become available in the Cloud. Introducing a facility state prevents failing requests to unavailable facilities and creates transparency for the user.

A prosEO user (actually the user's credentials).

An authority (also called a "privilege") is an atomic entitlement for a user to access a prosEO method or domain object.

A group of users

A group authority (also called a "privilege") is an atomic entitlement for a group of users to access a prosEO method or domain object.

Low-level user roles, which can be bundled for user groups.

In Spring Security, the user role values are prefixed with "ROLE_" to create authority strings for the Authority and GroupAuthority classes.

Monthly data volume granted to and actually used by a user