Conversation
| The openEO API aligns with OGC APIs (especially Common) and STAC. The openEO API standard fits well within the OGC API roadmap. | ||
| The openEO API aligns with the OGC APIs Standard baseline (especially Common) and STAC. The openEO API standard fits well within the OGC API roadmap. | ||
|
|
||
| OGC API - Processes and the openEO API complement each other and cater for different user audiences. |
There was a problem hiding this comment.
Comment:
I read the comment about possible overlaps. I would strongly encourage the development of a openEO/Processes API crosswalk similar to the STAC/Records API done for Testbed 19. Such a cross walk would be really helpful.
Response:
Available at Open-EO/openeo-api#494
| == Relationship to other OGC Standards | ||
|
|
||
| The openEO API builds on top of other standards and specifications an reuses other standards whenever possible. | ||
| The openEO API builds on top of other standards and specifications and reuses other standards whenever possible. |
There was a problem hiding this comment.
Comment:
All or parts (requirements classes)?
| Multiple organizations agreed to define and implement such an API. Its development was driven by the need to overcome the challenges associated with different tools, APIs, and data formats in geospatial technology. openEO was developed bottom-up and each version was backed by implementations. | ||
|
|
||
| The primary use case is to simplify and unify the data processing using a common API with a set of pre-defined processes. It is beneficial for users as they can still work in their favored programming language without worrying about data organization and pre-processing. They can avoid vendor lock-in as the generated process descriptions can be executed at multiple providers and as such also allows to compare and reproduce processing results more easily between different providers. | ||
| The primary use case for developing openEO was to simplify and unify the data processing using a common API specification with a set of pre-defined processes. As such, users can still work in their favored programming language without worrying about data organization and pre-processing. Users can avoid vendor lock-in as the generated process descriptions can be executed at multiple provider endpoints supporting comparing and reproducing processing results more easily between different providers. |
There was a problem hiding this comment.
Comment:
Simplify the data processing or accessing processing services in some processing chain??
|
A general comment the last chapter:
Example provided:
|
1 participant
Updated the document according to the document that was attached to the comment, see #29