You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: applications/capability_integration.md
+14-5Lines changed: 14 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,10 @@
1
1
# Integration Requirements for Argo Workflows on EOxHub
2
2
3
-
This document outlines the minimum requirements for integrating a new process into the Argo Workflow system on EOxHub. This includes input definitions, expected Docker image standards, and output formats.
3
+
This document is intended as support material to describe how to best provide a capability implementation and its description in order to allow EOX to integrate it as a workflow inside of an EOxHub Workspace. This includes input definitions, expected Docker image standards, and output formats.
4
4
5
5
## Input Requirements
6
6
7
-
If your service should be integrated into the eodash processing widget docker input fields must correspond to our supported options. Beside this we expect to get information regarding:
7
+
To ensure compatibility with various interfaces (e.g. OGC Process API) to allow on demand execution of the capability some input requirements need to be considered. Furthermore information providing more context is needed regarding following points:
8
8
9
9
- Description of expected input data - does the service expect data already present or data are downloaded as part of the dockerized algorithm?
10
10
- Description of expected argument and parameters
@@ -15,18 +15,27 @@ If your service should be integrated into the eodash processing widget docker in
15
15
16
16
eodash processing widget support multiple ways how to pass input.
17
17
- Area/location - process can take as input drawn point or polygon from the eodash user interface. For this integration, input field must accept eather coorinates directly or geoJSON as a string. File input is not accepted.
18
-
- Date - standard date formats are supported. eodash also supports start and end time to create range.
18
+
- Example GeoJSON Feature String '{"type":"Feature","geometry":{"type":"Polygon" "coordinates":[[[30,10],[40,40],[20,40],[10,20],[30,10]]]},"properties":{}}'
19
+
- Date - standard HTML Format date formats are supported. eodash also supports start and end time to create range.
20
+
- "YYYY-MM-DD" e.g. 2015-05-30 for date.
21
+
- "YYYY-MM-DDThh:mm" for datetime 2025-07-02T06:33
19
22
- Numeric fields - integer or float values
20
23
- Text fields
21
24
- Dropdowns with limited options
22
25
23
-
26
+
24
27
All fields can have default value
25
28
26
29
27
30
## Docker Image Requirements
28
31
29
-
Your process must be encapsulated in a Docker image without the strict limitations. It is helpful if the image is "slim" - only with required dependencies installed.
32
+
Your process must be encapsulated in a Docker image. There are no strict limitations of what can be done, but there are good practices that help integration:
33
+
34
+
- image is "slim" - only with required dependencies installed
35
+
- image is tagged with version based on [semantic versioning](https://semver.org/)
36
+
- algorithm logs to standard out (stdout) helping debug potential issues
37
+
- simpler if no sideloading/sidecars (docker in docker) and similar
38
+
- no special volumes, network expectations, ...
30
39
31
40
We expect to know resource usage estimation - RAM consumption and CPU estimates.
0 commit comments