-
Notifications
You must be signed in to change notification settings - Fork 17
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
Give users the full process instead of just the graph #54
Comments
I think, I had implemented something like that. Just use |
Thank you, I'll look into it tomorrow, I just saw again that someone using the R client exported it "incorrectly" again. Wasn't there a graph or toJson function or something like that that may still export the old version? |
Okay, the issue is the following code used in many examples (e.g. GEE + EURAC):
The graph outputted is just the "graph" (example 2), not a complete process (example 1). Such behavior should either be changed or not be promoted in examples. |
Yes, it is as I imagined, you wan't to have an openEO process (JSON) from this graph. But as the name difference suggests you have to create a process by adding metadata to the graph using |
@m-mohr Can you point me to the examples where it is promoted, that you can 1:1 copy the graph into the Webeditor? Then I can change this. |
I found it here, I'm not sure whether I found them all:
Would it make sense to implement as(..., "Process") instead of as(..., "Graph") or is create_user_process more reasonable? |
Actually, |
I see the point, and
and this is the result:
then I used additional step to visualize the json in a web editor to get the following:
|
As my main purpose was to present how a graph could look like, I find
|
No, print() is also giving the imcomplete process (can't be visualized in the Web Editor for example), so yet another place that should be fixed. |
@m-mohr, @flahn:
|
I'm working towards having the process visualizations standalone as a component that it can be integrated like the Collections component for example, but it's not an easy task as it has quite a lot of dependencies so it will take a bit more time... |
I'm coming a bit late to the discussion, sorry. "Graph" and "Process" (user defined or predefined) are different concepts. The graph as such is just the part of the process that tells the back-end what it has to do. Process is more, it contains also meta data about the graph like name, description, etc. |
How is the python client handling this at the moment? @m-mohr @clausmichele |
I've opened an issue a couple of days ago exactly about this for the python client Open-EO/openeo-python-client#209 |
Both R client and Python client still work a bit like in API v0.4 and it seems both never fully adopted the new process schema internally. In 0.4 there was only process graphs without metadata, but a process graph without any metadata and without the wrapper is pretty much useless in API 1.0, so the clients should adopt that structure. |
Just an update on this topic to pick up when we continue. On the Process graph definition:
|
@przell, you can use the parameter |
As for now, I have implemented the As a deprecation note: now that we can obtained a simple UDP on the client by coercion, we don't necessarily need the parameter |
Great! Could we also deprecate (and print a warning?) for |
I advise against it, because i use this internally to coerce into the process graph part of a UDP. I cannot differentiate if the user called the function explicitly or if it was called from an internal function, which would be annoying to read. However, I removed examples in the code documentation which used as(x,"Graph") and pointed out that this might be revoked from the function export of the package (087c9f3). |
Okay, then a warning is not a good idea, but you could still deprecate it in the docs, right? |
Kind of. I haven't found any option to denote deprecation in the documentation. That is, what I did openeo-r-client/man/as.Graph.Rd Line 29 in 087c9f3
|
I removed printing the process graph in UDPs and services. Instead I advertise / encourage the user to coerce it into a Process. Printing the process will then of course show a valid process graph. I hope that I have eliminated now all potential misuses. If not feel free to open this issue again or create a new one ;) |
In general, but especially also in the QGIS plugin and the Web Editor, openEO processes in JSON need to be fully defined including their potential metadata (see example 1), i.e. it is not enough to just list the graph nodes (see example 2). Unfortunately, the R client and Python client export the graphs without their metadata. This leads reportedly to some confusion when users try to copy/paste the "incomplete" processes into the Web Editor, QGIS Plugin or the Hub for example, which then can't handle them properly. Therefore, I'd really like to see that the R and Python clients print out the full process (see example 1).
Example 1:
Example 2:
The text was updated successfully, but these errors were encountered: