imagecollection vs datacube

[m-mohr]

From what I see in examples, the Python client currently uses "imagecollection" to create processing instructions. Wouldn't it be more aligned with what we do to call this datacube? So to replace con.imagecollection("s2", ...) with something like con.datacube("s2", ...)? I got to think about this when updating https://openeo.org/documentation/draft/developers/clients/library-guidelines.html

[soxofaan]

FYI: in 6fc4cee I already sort of deprecated Connection.imagecollection and added the method Connection.load_collection to be more in line with the API.
But there is indeed a lot of example code floating around using old approaches (there have already been a lot of API changes of course)

[soxofaan]

However, what we could also put up for discussion is renaming the class ImageCollection (and related) to DataCube

To me it sounds indeed better because the thing acts more like a homogeneous cube than a collection of images. However it would require quite a large "diff" to address this, and I'm not sure if it is worth that trouble. A normal user should not use the class directly to create an instance anyway (but Connection.load_collection instead).

On the other hand, when using the documentation of the python client, the user is still confronted with this ImageCollection class name (ImageCollectionClient actually, which is quite a mouth full to be honest).

what do you think @jdries ?

[jdries]

This all makes a lot of sense, especially now that the API is supposed to be stable.
I propose to align the renaming of classes with the new code that we'll need anyway to support 1.0.0, and a new approach to building process graphs, which should solve some issues with the implementation we have for 0.4.0.

[soxofaan]

the just merged PR #126 introduced new DataCube class meant to handle API 1.0 usage
The old 0.4 style logic is still under ImageCollectionClient (to be removed when support for 0.4 API is not necessary anymore)