[EPIC] Populate algorithm catalog

[jdries]

EPIC to add a first set of (existing) UDP's to the algorithm catalog.

Guidelines for creating examples will soon appear here:

https://esa-apex.github.io/apex_documentation/eo_service_usage.html

We currently consider these lists:

VITO:

• BAP composite #32
• FuseTS/AI4Food UDP's (cropsar, mogpr) #66
• BioPar (VITO version) #35
• WorldCereal first version
• Max-NDVI composite
• Sentinel-1 stats #33

Non-VITO:

• ESA WorldWater (DHI)
• GTIF Wind Turbine (DHI)
• PV farm detection (EURAC) #34
• Sen2Like (EODC)
• Biopar (EODC)

[jdries]

@Patrick1G This is the overview issue, allowing to easily maintain a list of UDP's we would aim for in the MVP.
@JeroenVerstraelen @HansVRP We'll want to consider this for planning.

[Patrick1G]

@jdries that looks like good starting point.
We could consider a couple of other examples from the community examples repo (also to have a good balance with non VITO workflows)... The parcel delineation algo would certainly also be interesting for users, yet developed by VITO...

[Patrick1G]

oh and PS; what's the point of having an EODC and VITO version of biopar?

[HansVRP]

@jdries what requirements do we have on the input parameters for the to be included openEO processes?

bbox and temporal range?

[jdries]

@HansVRP that's usually the minimum, but it actually depends on the UDP.
Now this is considered public API, so once a parameter is introduced, changing it is not backwards compatible.
So the general recommendation is to start out with a minimal set.

[HansVRP]

Good to know there are no restrictions.
Some of the listed probably also have some parameters related to the used ML network ect.

[Patrick1G]

@jdries @JanssenBrm to be true to the APEx vision, we would (or will eventually) also expose other algorithms hosted o other platforms. Below is a listing of EOXhub algorithms from the NOR.. Several of those use an Application Package implementation..
I wonder if we could aggregate a few of these early on...

[jdries]

@Patrick1G this indeed looks like a nice collection to integrate, especially also very mature with respect to having pricing and so on.
The only prerequisite from our side is that we need the OGC Processes API to invoke it (or openEO, but that doesn't seem to be applicable here). I checked the docs, which mention an api on this page:
https://eurodatacube.com/documentation/generate_data_on_demand
but it doesn't look like OGC Processes at first sight. Could you check with EDC if they can give us such an endpoint, or should we reach out?

[Patrick1G]

@p3dr0
Could you make sure we have all of those algos integrated into the catalogue early on..

[Patrick1G]

@Patrick1G this indeed looks like a nice collection to integrate, especially also very mature with respect to having pricing and so on. The only prerequisite from our side is that we need the OGC Processes API to invoke it (or openEO, but that doesn't seem to be applicable here). I checked the docs, which mention an api on this page: https://eurodatacube.com/documentation/generate_data_on_demand but it doesn't look like OGC Processes at first sight. Could you check with EDC if they can give us such an endpoint, or should we reach out?

I asked EOX to look into this, but have not heard anything back (purposefully hesitant?)

I have asked PLES team to look into this in the meantime..

[p3dr0]

added two examples on this pull request
#39
I'll add more after checking with @jdries the are ok

[Patrick1G]

@p3dr0 @JanssenBrm @psacra
For APEx to integrate the Elip and EDC/EOXhub services/algos above, APEx needs to have a valid subscription to all the relevant platforms, to be obtained from the NOR (now?). This should also cover testing requirements..

[p3dr0]

We'd need to size it according to the planned test scenarios (daily, hour) and the duration (next 6 months? )
I'll update the list of services on the PR, add the metadata element missing and draft a NoR request for it

[jdries]

@p3dr0 see my other comment for the sizing: please adjust the frequency depending on the scenario cost. I would start from weekly frequency for cheap scenarios. Higher frequency seems like overkill, and because we are likely to run multiple scenarios against the same platform, we will still have a pretty high per platform frequency that allows us to detect general issues in a timely manner.