Add process graph examples

[m-mohr]

Many processes lack examples as it wasn't really possible to find small, self-contained examples yet. Due to the changes for Open-EO/openeo-api#161 we can do that much better now and collect and add more examples.

[soxofaan]

Agreed. While working on 1.0.0 support on python client, this was one of the things that I missed from current docs.

[m-mohr]

That's the task of the whole consortium. We started from scratch so there are not a lot of process graphs and we - University of Münster - don't have the strongest background in remote sensing and data processing. So we depend on the real world use cases and process graphs all of you come up with. If you have anything to share, please post them at https://openeo.org/documentation/1.0/developers/examples/ or do PRs against this repo for individual processes. With 1.0 there are some general examples and/or "alias" process graphs in some of the processes already (see #137).

[soxofaan]

For what it's worth: we have a couple of examples for the unit tests of the python client at
https://github.com/Open-EO/openeo-python-client/tree/master/tests/data/1.0.0

Note however, the current version in master is not fully 1.0.0 valid. I'm working on better 1.0.0 support in a feature branch at the moment, but I hope to merge this somewhere this week:
https://github.com/soxofaan/openeo-python-client/tree/EP-3251-graph-building/tests/data/1.0.0

[m-mohr]

That's a good resource, but I'm not going through the repos and scrap examples from there as I'm not sure what helps and what doesn't. For example, the eq examples are probably not needed, there are good non-process-graph examples in the json. merge_cubes might be interesting, but I'd like to encourage you that you do PRs or more concrete requests once there are open questions so that we can add only what really needs to be improved for the sake of time. Also, I'd usually shorten the examples to not always contain all the redundant loading and saving tasks...

[m-mohr]

There's an examples folder where we can add additional examples. All the examples there should be referenced from at least one process. I'd appreciate PRs.

[soxofaan]

openeo-processes/array_apply.json

Lines 88 to 101 in 1645b97

	"links": [
	{
	"rel": "example",
	"type": "application/json",
	"href": "https://processes.openeo.org/draft/examples/array_find_nodata.json",
	"title": "Find no-data values in arrays"
	},
	{
	"rel": "example",
	"type": "application/json",
	"href": "https://processes.openeo.org/draft/examples/array_contains_nodata.json",
	"title": "Check for no-data values in arrays"
	}
	]

These references have ../draft/.. in their href, isn't that going to cause issues/confusion once that is merged in master? Or are you planning to rewrite all these urls after merging in master?
Wouldn't it be better to use a version instead of a branch name? e.g. ../1.0.0/... or even without patch component: 1.0.

[m-mohr]

Before merging, I replace all version numbers (here: draft). Even with a version number you still need to rename them later so there's no real win. Unfortunately, GitHub doesn't allow us easily to use other version numbers than the patch versions...

[soxofaan]

so there's no real win

a slight improvement would be that version numbers carry a meaning on the level of the API itself, while branch names are just implementation details.

[m-mohr]

I don't understand what you are saying.
Draft versions are not meant to be exposed via API anyway and I don't know what the next version number is (rc2? final?). And it may break the draft docs.

[m-mohr]

The examples are not really bound to a release and can be added later, too.