Process graph documentation and improvements (#160)

docs/glossary.md

@@ -39,7 +39,9 @@ Examples:
 
 Note that for the first example, the aggregation function not only requires time series values, but also their time stamps.
 
-***Resampling*** (also called _scaling_) is a broader term where we have data at one resolution, and need values at another. In case we have values at a 100 m x 100 m grid and need values at a 10 m x 10 m grid, the original values will be reused many times, and may be simply assigned to the nearest high resolution grid cells (nearest neighbor method), or may be interpolated using various methods (e.g. by bilinear interpolation). Resampling from finer to coarser grid may again be a special case of aggregation.
+***Resampling*** (also called _scaling_) is a broader term where we have data at one resolution, and need values at another. In case we have values at a 100 m x 100 m grid and need values at a 10 m x 10 m grid, the original values will be reused many times, and may be simply assigned to the nearest high resolution grid cells (nearest neighbor method), or may be interpolated using various methods (e.g. by bilinear interpolation). This is often called _upsampling_ or _upscaling_.
+
+Resampling from finer to coarser grid is a special case of aggregation often called _downsampling_ or _downscaling_.
 
 When the target grid or time series has a lower resolution (larger grid cells) or lower frequency (longer time intervals) than the source grid, aggregation might be used for resampling. For example, if the resolutions are similar, (e.g. the source collection provides 10 day intervals and the target needs values for 16 day intervals), then some form of interpolation may be more appropriate than aggregation as defined here.
 

docs/guidelines-clients.md

@@ -56,7 +56,7 @@ Method names of scopes in the *Content* category may collide with method names o
 
 ### Parameters
 
-The parameters usually follow the request schemas in the openAPI specification. The parameters should follow their characteristics, for example regarding the default values.
+The parameters usually follow the request schemes in the openAPI specification. The parameters should follow their characteristics, for example regarding the default values.
 
 Some methods have a long list of (optional) parameters. This is easy to implement in languages that support named parameters such as R. For example, creating a job in R with a budget would lead to this method call:
 

docs/processes.md

@@ -12,23 +12,24 @@ See the **[process reference](processreference.md)** for pre-defined processes.
 
 Any back-end provider can either implement a set of pre-defined processes (STRONGLY RECOMMENDED) or define new processes for their domain.
 
-To define new processes, back-end providers should consider:
+To define new processes, back-end providers MUST follow the `process` schema in the API specification. This includes:
 
-* The name is the identifier for the process and MUST only contain a forward slash `/`. 
-* Each parameter has a name and the content follows a schema.
-* The content returned by a process also follows a schema.
-* The schema usually defines the data type and a format according to JSON schema. There are openEO specific formats defined below.
+* Choosing a intuitive and ideally unique process name consisting of only letters (a-z), numbers and underscores.
+* Defining the parameters and their exacts (JSON) schemes.
+* Specifying the return value of a process also with a (JSON) schema.
+* Providing examples or compliance tests.
+* Trying to make the process universially usable so that other back-end providers or openEO can adopt it.
 
 ## openEO specific formats
 
 In addition to the native data formats specified by JSON schema, openEO defines a set of specific formats that should be re-used in process schema definitions:
 
 | Format Name   | Description |
 | ------------- | ----------- |
-| `callback`    | An openEO process graph that is passed as an argument and is expected to be execute by the process. |
+| `callback`    | An openEO process graph that is passed as an argument and is expected to be executed by the process. |
 | `date`        | Date only representation, as defined for `full-date` by [RFC 3339 in section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6). The time zone is UTC. |
 | `date-time`   | Date and time representation, as defined for `date-time` by [RFC 3339 in section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6). |
-| `geojson`     | GeoJSON as defined by [RFC 7946](https://tools.ietf.org/html/rfc7946). [JSON Schemas for validation are available.](https://github.com/geojson/schema) |
+| `geojson`     | GeoJSON as defined by [RFC 7946](https://tools.ietf.org/html/rfc7946). [JSON Schemes for validation are available.](https://github.com/geojson/schema) |
 | `raster-cube` | A raster data cube, an image collection stored at the back-end. Different back-ends have different internal representations for this data structure. |
 | `temporal-intervals` | An array of two-element arrays, which contains temporal left-closed intervals. For more information see the parameter `intervals` in the process `aggregate_temporal`. |
 | `time`        | Time only representation, as defined for `full-time` by [RFC 3339 in section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6). Although [RFC 3339 prohibits the hour to be '24'](https://tools.ietf.org/html/rfc3339#section-5.7), this definition allows the value '24' for the hour as end time in an interval in order to make it possible that left-closed time intervals can fully cover the day. |