Skip to content

Eliminate wrong assumptions about "terminal" nodes  #583

Open

Description

@soxofaan

The process graph building logic in Python client quite heavily works from assumption about the equivalence

"end node" = "result node" = "save_result"

which works for most use cases, but that's not fully in line with full openEO API.

also see Open-EO/openeo-geopyspark-driver#424 (comment):

Some more insights from Open-EO/openeo-processes#279 and Open-EO/openeo-api#427 about different kinds of terminal nodes in the openEO API

  • a process graph can have multiple "end nodes": leaf nodes that are not input to another node
  • a process graph must have one "result node": node with "result": True.
    • The result node is actually just important in the the context of a "callback" (in a "parent" process like apply, reduce_dimension, ...) to determine the value that has to be used by the parent process
    • The "result" property has little meaning for "top-level" graphs
  • the result node does not have to be an "end node". Result nodes can be input to subsequent nodes
  • a "save_result" node neither has to be "end node" or "result node" to be executed

Activity

  1. added 9 commits that reference this issue on Sep 24, 2024
  2. m-mohr commented on Nov 7, 2024

    @m-mohr
    Member

    Just a short note regarding "The "result" property has little meaning for "top-level" graphs": This is only true when submitted for execution. If stored as a UDP, it actually has a meaning as it's the return value of the UDP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions