-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review comments from C. Reed #30
Conversation
|
||
OGC API - Processes and the openEO API complement each other and cater for different user audiences. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -65,22 +65,23 @@ openEO is backed by various tools and resources that facilitate its use. These i | |||
|
|||
== 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment:
All or parts (requirements classes)?
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment:
Simplify the data processing or accessing processing services in some processing chain??
A general comment the last chapter:
Example provided:
|
Updated the document according to the document that was attached to the comment, see #29