openEO and API names harmonized

Author: m-mohr

README.md

@@ -1,8 +1,8 @@
-# OpenEO API prototype for proof of concept
+# openEO API prototype for proof of concept
 
 [![Status](https://img.shields.io/badge/Status-proof--of--concept-yellow.svg)]()
 
-This repository provides a draft [Swagger 2.0](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md) definition of the [OpenEO](http://openeo.org) API for rapid prototyping and a proof of concept. The complete API is described in `swagger.json`. An additional description of core ideas and concepts including the Core API specification itself can be found at **[https://open-eo.github.io/openeo-api](https://open-eo.github.io/openeo-api/)**. Since swagger 2.0 does not support JSON schema combinations with `oneOf` and `anyOf`, this definition lacks a formalization of process argument values. 
+This repository provides a draft [Swagger 2.0](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md) definition of the [openEO](http://openeo.org) API for rapid prototyping and a proof of concept. The complete API is described in `swagger.json`. An additional description of core ideas and concepts including the API specification itself can be found at **[https://open-eo.github.io/openeo-api](https://open-eo.github.io/openeo-api/)**. Since swagger 2.0 does not support JSON schema combinations with `oneOf` and `anyOf`, this definition lacks a formalization of process argument values. 
 
 ## Documentation and editing
 You can use [swagger-ui](https://github.com/swagger-api/swagger-ui) and [swagger-editor]() to

docs/README.md

@@ -1,10 +1,10 @@
 
-# Generation of OpenEO API documentation
+# Generation of openEO API documentation
 
 [![Status](https://img.shields.io/badge/Status-proof--of--concept-yellow.svg)]()
 
 
-This Docker image combines static and auto-generated API documentation of the [OpenEO API](https://github.com/Open-EO/openeo-api/). 
+This Docker image combines static and auto-generated API documentation of the [openEO API](https://github.com/Open-EO/openeo-api/). 
 You can see the resulting documentation at [https://open-eo.github.io/openeo-api](https://open-eo.github.io/openeo-api).
 
 ## Build documentation

docs/docs/arch.md

@@ -1,14 +1,14 @@
 # Architecture
 
-The OpenEO core API defines a language how clients communicate to back-ends in order to analyze large Earth observation datasets. The API will be implemented by drivers for specific back-ends. Some first architecture considerations are listed below.
+The openEO API defines a language how clients communicate to back-ends in order to analyze large Earth observation datasets. The API will be implemented by drivers for specific back-ends. Some first architecture considerations are listed below.
 
-1. The OpenEO core API is a contract between clients and back-ends that describes the communication only
-2. Each back-end runs its own API instance including the specific back-end driver. There is no core API instance that runs more than one driver.
-3. Clients in R, Python, and JavaScript connect directly to the back-ends and communicate with the back-ends over HTTP(s) according to the OpenEO core API specification.
+1. The openEO API is a contract between clients and back-ends that describes the communication only
+2. Each back-end runs its own API instance including the specific back-end driver. There is no API instance that runs more than one driver.
+3. Clients in R, Python, and JavaScript connect directly to the back-ends and communicate with the back-ends over HTTP(s) according to the openEO API specification.
 4. API instances can run on back-end servers or additional intermediate layers, which then communicate to back-ends in a back-end specific way.
-5. Back-ends may add functionality and extend the core API wherever there is need.
+5. Back-ends may add functionality and extend the API wherever there is need.
 6. There will be a central back-end registry service, to allow users to search for back-ends with specific functionality and or data. 
-7. The OpenEO core API will define _profiles_ in order group specific functionality.
+7. The openEO API will define _profiles_ in order group specific functionality.
 
 ![Architecture](arch.png)
 

docs/docs/glossary.md

@@ -38,11 +38,11 @@ The open geospatial consortium published a document on [OGC OpenSearch Geo and T
 
 ## Processes and Jobs
 
-The terms _process_, _process graph_ and _job_ have different meanings in the OpenEO API specification.
+The terms _process_, _process graph_ and _job_ have different meanings in the openEO API specification.
 
 A **process** is simply the description of an operation as provided by the back end, similar to a function definition in programming languages. 
 
-In this context OpenEO will:
+In this context openEO will:
 
 1. consider, or allow to consider, band as a dimension
 2. consider imagery (image collections) to consist of one _or more_ collections, as argument to functions; allow filtering on a particular collection, or joining them into a single collection

docs/docs/index.md

@@ -1,14 +1,14 @@
-# OpenEO - Core Concepts and API Reference
+# openEO - Concepts and API Reference
 
 _Work in progress, please contribute by adding [issues](https://github.com/Open-EO/openeo-api/issues)._
 
 openEO develops an open API that connects clients like R, Python and JavaScript to big Earth observation cloud back-ends in a simple and unified way.
 
 The following pages introduce the core concepts of the project. Make sure to introduce yourself to the major technical terms used in the openEO project by reading the [glossary](glossary.md).
 
-The OpenEO Core API defines a [RESTful API](apireference.md) that lets cloud back-ends with large Earth observation datasets communicate with front end analysis applications in an interoperable way. This documentation describes important API concepts and design decisions and gives a complete [API reference documentation](apireference.md).
+The openEO API defines a [RESTful API](apireference.md) that lets cloud back-ends with large Earth observation datasets communicate with front end analysis applications in an interoperable way. This documentation describes important API concepts and design decisions and gives a complete [API reference documentation](apireference.md).
 
-As an overview, the OpenEO API specifies how to
+As an overview, the openEO API specifies how to
 
 - discover which Earth observation data and processes are available at cloud back-ends,
 - execute (chained) processes on back-ends, 
@@ -22,6 +22,6 @@ The API is defined as an [OpenAPI 2.0](https://github.com/OAI/OpenAPI-Specificat
 
 
 
-![OpenEO logo](openeo_logo.png)	
+![openEO logo](openeo_logo.png)	
 
-_[OpenEO](https://openeo.org), A Common, Open Source Interface between Earth Observation Data Infrastructures and Front-End Applications is a H2020 project funded under call EO-2-2017: EO Big Data Shift, under proposal number 776242. It will run from Oct 2017 to Sept 2020._
+_[openEO](https://openeo.org), A Common, Open Source Interface between Earth Observation Data Infrastructures and Front-End Applications is a H2020 project funded under call EO-2-2017: EO Big Data Shift, under proposal number 776242. It will run from Oct 2017 to Sept 2020._

docs/docs/poc.md

@@ -1,6 +1,6 @@
 # Proof of Concept
 
-This page gives a detailed description of the OpenEO proof of concept and gives a list and specification of what needs to be implemented. The proof of concept will consist of
+This page gives a detailed description of the openEO proof of concept and gives a list and specification of what needs to be implemented. The proof of concept will consist of
 
 * at least three clearly defined example processes (see below),
 * a prototypical API specification including communication API call sequences of the processes (see below),

docs/docs/udfs.md

@@ -1,6 +1,6 @@
 # User-defined functions
 
-User-defined functions (UDFs) can be exposed to the data in different ways. This includes which parts of the data are passed to the function, how the function execution is parallelized, and how the expected output is structured. The OpenEO core API defines the following UDF types:
+User-defined functions (UDFs) can be exposed to the data in different ways. This includes which parts of the data are passed to the function, how the function execution is parallelized, and how the expected output is structured. The openEO API defines the following UDF types:
 
 - [apply_pixel](#apply_pixel)
 - [apply_scene](#apply_scene)
@@ -28,10 +28,10 @@ You can use UDFs in a process graph as shown in the [examples for proof-of-conce
 This type applies a simple function to one pixel of the input image or image collection. The function gets the value of one pixel (including all bands) as input and produces a single scalar or tuple output. The result has the same schema as the input image (collection) but different bands. Examples include the computation of vegetation indexes or filtering cloudy pixels. 
 
 #### apply_scene
-This low-level UDF type applies a function on individual scenes.  The function gets a single scene as input and produces a modified "scene" with the same spatial footprint. This UDF type will only be supported by OpenEO back-ends with a file-based data organization. Higher level data-cube oriented back-offices in general do not keep track of the scenes and hence will not be able to parallelize operations on scene level. The type is mostly useful for working with lower-level data products, e.g., to perform atmospheric correction or any other operation that needs scene metadata. 
+This low-level UDF type applies a function on individual scenes.  The function gets a single scene as input and produces a modified "scene" with the same spatial footprint. This UDF type will only be supported by openEO back-ends with a file-based data organization. Higher level data-cube oriented back-offices in general do not keep track of the scenes and hence will not be able to parallelize operations on scene level. The type is mostly useful for working with lower-level data products, e.g., to perform atmospheric correction or any other operation that needs scene metadata. 
 
 #### reduce_time
-This type applies a function to a single time series and produces a zero-dimensional output (scalar or tuple). Notice that the `view` parameter for OpenEO processes affects the resolution and window of the time series provided as input to UDFs of this type. 
+This type applies a function to a single time series and produces a zero-dimensional output (scalar or tuple). Notice that the `view` parameter for openEO processes affects the resolution and window of the time series provided as input to UDFs of this type. 
 
 #### reduce_space
 This type applies a function to a temporal snapshot of the data and produces a single value or multiband tuple per snapshot. The result is a time series. 

docs/docs/views.md

@@ -1,6 +1,6 @@
 # Data Views
 
-The OpenEO API supports to look at datasets from different `views`. Views describe at which resolution and for which spatial and temporal extent the original Earth observation data are processed and hence can be used to run processes interactively on small parts of the original data without need to wait for long-running processes. The idea is similar to what Google Earth Engine does by reducing computations only to pixels that are actually displayed.
+The openEO API supports to look at datasets from different `views`. Views describe at which resolution and for which spatial and temporal extent the original Earth observation data are processed and hence can be used to run processes interactively on small parts of the original data without need to wait for long-running processes. The idea is similar to what Google Earth Engine does by reducing computations only to pixels that are actually displayed.
 
 *Note: This feature is currently not described in the API specification. It will be added after delivering the proof-of-concept.*
 

docs/mkdocs.yml

@@ -1,4 +1,4 @@
-site_name: OpenEO - Core Concepts & API
+site_name: openEO - Concepts & API
 pages:
   - Home: index.md
   - Glossary: glossary.md