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

openEO is not returning all bands after UDF execution #92

Closed
JanssenBrm opened this issue Jul 18, 2023 · 5 comments
Closed

openEO is not returning all bands after UDF execution #92

JanssenBrm opened this issue Jul 18, 2023 · 5 comments
Labels

Comments

@JanssenBrm
Copy link
Collaborator

On the openeo-publish branch we are currently integrating the different FuseTS services into openEO. One of the services we are curently working on is the Phenology service. In the following file, you can find a function that tests the Phenology UDF through openEO:

https://github.com/Open-EO/FuseTS/blob/openeo_publish/src/fusets/openeo/services/publish_phenology.py#L34

When the UDF is executed, the result seems to be valid datacube that contains 18 bands (see log entry with Phenology result . Each of these bands represent one of the phenology metrics that are calculated.

MicrosoftTeams-image

However, after downloading the result, there is only 1 band left. It looks like some of the band information gets lost.

image

@JanssenBrm JanssenBrm added bug Something isn't working WP5 WP5 labels Jul 18, 2023
@JanssenBrm
Copy link
Collaborator Author

I'm wondering if this is caused by using the apply_dimension as the data variable of the downloaded netcdf looks pretty strange:

var        (phenology, y, x) float64 0.8873 0.8689 0.8909 ... 0.8858 0.9385

I've also tried the following paths, but without success:

  • Using the reduce_dimension, but no improvements there, with or without the t dimension (on which I reduce the data cube).
  • Manually updating the metadata of the datacube using the following code. This gives the same result.
metadata = CollectionMetadata({})
metadata = metadata.add_dimension('var', '', 'bands')\
    .rename_labels(dimension='var', target=phenology_bands)
phenology.metadata = metadata
  • Updating the dimensions using the openEO functions, as demonstrated below. Executing this will result in an error that a band called bands already exists. When removing the add_dimension statement, another error is thrown (ValueError: Invalid dimension 'bands'. Should be one of ['t', 'x', 'y'] )
phenology = phenology.add_dimension('bands', phenology_bands[0], 'bands')
phenology = phenology.rename_labels(dimension='bands', target=phenology_bands)

@JanssenBrm
Copy link
Collaborator Author

@soxofaan / @jdries - FYI

@JanssenBrm
Copy link
Collaborator Author

JanssenBrm commented Jul 18, 2023

I've also tried using the apply_neighborhood function with the following code:

size = 125
phenology = base_ndvi.apply_neighborhood(process=lambda x: run_udf(x, udf=load_phenology_udf(), runtime="Python"),
                                              size=[
                                             {'dimension': 'x', 'value': size, 'unit': 'px'},
                                             {'dimension': 'y', 'value': size, 'unit': 'px'}
                                         ], overlap=[])

However this results in an error that is also reported in Open-EO/openeo-geopyspark-driver#434

@JanssenBrm
Copy link
Collaborator Author

It looks like summarizing your experiments really help with resolving the issue 😄 . After looking at the screenshots I noticed that the resulting band from the UDF is called var. Applying the following code did the trick:

phenology = phenology.add_dimension('var', phenology_bands[0], 'bands')
phenology = phenology.rename_labels(dimension='var', target=phenology_bands)

@soxofaan
Copy link
Member

🦆

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

No branches or pull requests

2 participants