Skip to content
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

merge_cubes and overlap resolver #23

Open
clausmichele opened this issue Jul 29, 2020 · 4 comments
Open

merge_cubes and overlap resolver #23

clausmichele opened this issue Jul 29, 2020 · 4 comments

Comments

@clausmichele
Copy link
Member

Parsing a process graph containing a merge_cubes process with an overlap resolver doesn't work properly, or at least I can't understand why it is giving the current output. For example, parsing the following process graph, for the subtract process (overlap resolver of merge_cubes):
{'process_id': 'subtract', 'arguments': {'x': [{'from_node': '3_2'}, {'from_node': '4_4'}], 'y': [{'from_node': '3_2'}, {'from_node': '4_4'}]}, 'result': True}
which is confusing, since I can't understand which parameter is x and which is y. If I revert the parameter in the code:

              "process_id": "subtract",
              "arguments": {
                "x": {
                  "from_parameter": "y"
                },
                "y": {
                  "from_parameter": "x"
                }
              },

I get the same output.
Could you please check this?

{
  "process_graph": {
    "1": {
      "process_id": "load_collection",
      "arguments": {
        "id": "WETSNOW2",
        "spatial_extent": {
          "east": 11.416511535644531,
          "south": 46.406617041056165,
          "north": 46.550361051816196,
          "west": 11.257896423339844
        },
        "temporal_extent": [
          "2015-11-06T00:00:00.000Z",
          "2016-09-25T00:00:00.000Z"
        ]
      }
    },
    "2": {
      "process_id": "filter_bands",
      "arguments": {
        "data": {
          "from_node": "1"
        },
        "bands": [
          "VH"
        ],
        "common_names": [],
        "wavelengths": []
      }
    },
    "3": {
      "process_id": "reduce_dimension",
      "arguments": {
        "data": {
          "from_node": "2"
        },
        "dimension": "t",
        "reducer": {
          "process_graph": {
            "max1": {
              "process_id": "max",
              "arguments": {
                "data": {
                  "from_parameter": "data"
                }
              },
              "result": true
            }
          },
          "parameters": [
            {
              "name": "data",
              "description": "",
              "schema": {}
            }
          ]
        }
      }
    },
    "4": {
      "process_id": "filter_bands",
      "arguments": {
        "data": {
          "from_node": "1"
        },
        "bands": [
          "VH"
        ],
        "common_names": [],
        "wavelengths": []
      }
    },
    "6": {
      "process_id": "save_result",
      "arguments": {
        "data": {
          "from_node": "7"
        },
        "format": "NETCDF",
        "options": {}
      },
      "result": true
    },
    "7": {
      "process_id": "merge_cubes",
      "arguments": {
        "cube1": {
          "from_node": "3"
        },
        "cube2": {
          "from_node": "4"
        },
        "overlap_resolver": {
          "process_graph": {
            "1": {
              "process_id": "subtract",
              "arguments": {
                "x": {
                  "from_parameter": "x"
                },
                "y": {
                  "from_parameter": "y"
                }
              },
              "result": true
            }
          }
        }
      }
    }
  }
}
@clausmichele
Copy link
Member Author

In my opinion, the merge_cubes definition in the API https://processes.openeo.org/#merge_cubes is not clear enough, since it does not clarify what the x and y of the overlap resolver are, if they are cube1 and cube2 or what else.
I encountered a confusing behavior also in the GEE backend Open-EO/openeo-earthengine-driver#47

claxn pushed a commit that referenced this issue Aug 4, 2020
@claxn
Copy link
Collaborator

claxn commented Aug 4, 2020

Thanks for reporting this, the general behaviour for such processes is still not clear to me. I have implemented the following solution for the time being:
Open-EO/openeo-processes#184 (comment)
But I hope we can clarify this and make it more transparent. Please try it again with the branch bug_fixes.

@claxn
Copy link
Collaborator

claxn commented Aug 4, 2020

@clausmichele : maybe it is better to revert this behaviour again. Please have a look at: Open-EO/openeo-processes#184 (comment)

@claxn
Copy link
Collaborator

claxn commented Oct 17, 2020

@clausmichele The current output from bug_fixes for this process graph is:

Node ID: 1_0 
Node Name: 1 
{'arguments': {'id': 'WETSNOW2',
               'spatial_extent': {'east': 11.416511535644531,
                                  'north': 46.550361051816196,
                                  'south': 46.406617041056165,
                                  'west': 11.257896423339844},
               'temporal_extent': ['2015-11-06T00:00:00.000Z',
                                   '2016-09-25T00:00:00.000Z']},
 'process_id': 'load_collection'}

Node ID: 2_1 
Node Name: 2 
{'arguments': {'bands': ['VH'],
               'common_names': [],
               'data': {'from_node': '1_0'},
               'wavelengths': []},
 'process_id': 'filter_bands'}

Node ID: 3_2 
Node Name: 3 
{'arguments': {'data': {'from_node': '2_1'},
               'dimension': 't',
               'reducer': {'from_node': 'max1_3'}},
 'process_id': 'reduce_dimension'}

Node ID: max1_3 
Node Name: max1 
{'arguments': {'data': {'from_parameter': 'data'}},
 'process_id': 'max',
 'result': True}

Node ID: 4_4 
Node Name: 4 
{'arguments': {'bands': ['VH'],
               'common_names': [],
               'data': {'from_node': '1_0'},
               'wavelengths': []},
 'process_id': 'filter_bands'}

Node ID: 6_5 
Node Name: 6 
{'arguments': {'data': {'from_node': '7_6'}, 'format': 'NETCDF', 'options': {}},
 'process_id': 'save_result',
 'result': True}

Node ID: 7_6 
Node Name: 7 
{'arguments': {'cube1': {'from_node': '3_2'},
               'cube2': {'from_node': '4_4'},
               'overlap_resolver': {'from_node': '1_7'}},
 'process_id': 'merge_cubes'}

Node ID: 1_7 
Node Name: 1 
{'arguments': {'x': {'from_parameter': 'x'}, 'y': {'from_parameter': 'y'}},
 'process_id': 'subtract',
 'result': True}

So all 'from_parameter' statements need now to be resolved by the back-end. But I have added a few more functions, which could be useful to resolve the relationships in a fluent manner (updated docs will follow soon, please track #29). Please close this issue if you are happy with the result, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants