Minimal profile for backends

[jdries]

Porting over from: openEOPlatform/documentation#56
I think we need a minimal profile for 'raster' backends. This was originally triggered by a question from ESA to better indicate what an openEO backend has to implement to be listed as openEO backend in the NoR.

There's no general agreement yet on why we should 'raise the bar', so let me elaborate.
We can learn a lot from the history of 'enforcing' standards compliance in the earth observation and geospatial (OGC) communities. I'm specifically thinking about projects that required implementation of inspire and ogc standards. In various projects, contractors always claimed that they were going to be compliant, as otherwise their proposals would have to be dismissed. When we then go on to inspect the outcome, it turns out that the result is utterly useless.

One example: inspire compliance for EO data: you just put a file called 'inspire.xml' in every data product. In that file, you can just copy paste a basic inspire template, maybe actually fill in a few fields with actual product metadata. That's it, now you are compliant, just ignore the fact that 70% metadata fields contain default values or remain absent.

So now that we are aware that standards are effectively exploited in this way, we can look at openEO:

• Didn't try this, but it might be possible to effectively implement an openEO backend using static json files. Just put up a capabilities json online, and some static error messages for certain endpoints that you claim to implement.
• 'Backends' can just implement load_collection + save_result, but is this useful? In this case, an OGC WCS would do the same or more. None of the 'large scale processing' or 'data access & processing' claims that we often make would hold true. Users would get disillusioned by using such backends.

The key problem is that these minimalistic/erroneous backend seriously affect the credibility of a standard as a whole. Profiles are a good way to help users filter out the garbage. At the same time, this still allows anyone to get creative or to put a basic prototype online. Organizations like ESA then have a much better way to clearly indicate what level of compliance they seek.

[m-mohr]

I'd not limit this to raster processes (vector?) and also include API endpoints.

For API endpoints we have a starting point here: https://openeo.org/documentation/1.0/developers/backends/getting-started.html

For processes, we should compile a list that's useful for general data cube processing.
We could then say, you need at least one export file format. If it's a raster file format, implement the following processes a,b,c in addition. If it's vector, implement x,y,z in addition.

Based on openEOPlatform/documentation#56 we can probably get to a definition pretty quickly.

PS: moving to openeo.org as I think this belongs more into the general docs, not into the API.