Skip to content

Conversation

m-mohr
Copy link
Member

@m-mohr m-mohr commented Oct 12, 2023

See the README for details.

This PR includes the changes from PR #490.

@m-mohr m-mohr force-pushed the add-tests branch 3 times, most recently from f7affe8 to dafc6d9 Compare October 13, 2023 16:39
@soxofaan
Copy link
Member

soxofaan commented Jan 5, 2024

I have the impression a lot of changes in the diff come from PR #490
Is that intended?

@m-mohr
Copy link
Member Author

m-mohr commented Aug 7, 2025

Thank you @soxofaan. I've rebased and the diff looks significantly cleaner now.

Copy link
Member

@soxofaan soxofaan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is too large to give it a full in-depth review, but here are some random notes.

I guess it's more important to get this merged as "good enough" so that implementations can start integrate it, than to reach perfection.

@@ -1,7 +1,7 @@
{
"id": "apply_kernel",
"summary": "Apply a spatial convolution with a kernel",
"description": "Applies a 2D convolution (i.e. a focal operation with a weighted kernel) on the horizontal spatial dimensions (axes `x` and `y`) of a raster data cube.\n\nEach value in the kernel is multiplied with the corresponding pixel value and all products are summed up afterwards. The sum is then multiplied with the factor.\n\nThe process can't handle non-numerical or infinite numerical values in the data cube. Boolean values are converted to integers (`false` = 0, `true` = 1), but all other non-numerical or infinite values are replaced with zeroes by default (see parameter `replace_invalid`).\n\nFor cases requiring more generic focal operations or non-numerical values, see ``apply_neighborhood()``.",
"description": "Applies a 2D convolution (i.e. a focal operation with a weighted kernel) on the horizontal spatial dimensions (axes `x` and `y`) of a raster data cube.\n\nEach value in the kernel is multiplied with the corresponding pixel value and all products are summed up afterwards. The sum is then multiplied with the factor.\n\nThe process can't handle non-numerical or infinite numerical values in the data cube. Boolean values are converted to integers (`false` = 0, `true` = 1), but all other non-numerical, NaN, no-data, or infinite values are replaced with zeroes by default (see parameter `replace_invalid`).\n\nFor cases requiring more generic focal operations or non-numerical values, see ``apply_neighborhood()``.",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these changes look unrelated to the scope of this PR, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, they were spotted when creating the tests. They should've been in #490, but it seems I didn't catch them all.

- The input and output values for no-data values are `null` by default unless otherwise specified by a runner.
- Input that is not valid according to the schemas, will be rejected upfront and will not be checked on. For example, the absolute process only tests against the data types `number` and `null`. There are no tests for a boolean or string input.
- Numerical data types such as uint8 don't matter, i.e. tests don't check for overflows etc. This suite can't provide such tests as the underlying data type is not known.
- If not otherwise specified for numbers, a precision of 10 decimals is checked so return values should have at least 11 decimals.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the goal of this. If only up to 10 decimals must be checked, why care about the 11th decimal?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For whatever reaons I sometimes ran into rounding errors or imprecisions, so the 11th number was there to ensure that's actually happening in the 11th digit, not the 10th.

},
"experimental": {
"type": "boolean",
"description": "Declares that the process is experimental, tests may fail.",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why attaching this "experimental" label to the tests, if we already label the processes directly as "experimental".
Or is it to label the test suite as experimental?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To keep them for the tests self-contained. The test-suite reads only the test files if I remember correctly and makes use of the flag (warning vs error, I think).

"arguments": {
"data": []
},
"returns": {"type": "nodata"}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI:

Suggested change
"returns": {"type": "nodata"}
"returns": false

per #494

Copy link
Member Author

@m-mohr m-mohr Aug 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but #550 has not been merged yet. We need to merge it first.

"arguments": {
"data": []
},
"returns": {"type": "nodata"}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI:

Suggested change
"returns": {"type": "nodata"}
"returns": true

per #494

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Waiting for #550.

m-mohr and others added 4 commits August 22, 2025 17:24
Co-authored-by: Stefaan Lippens <soxofaan@users.noreply.github.com>
Co-authored-by: Stefaan Lippens <soxofaan@users.noreply.github.com>
@m-mohr
Copy link
Member Author

m-mohr commented Aug 22, 2025

I merged in from draft, but the tests still need some updates to reflect the latest changes in there. Need to go through the changes and adapt the tests. And also add tests for text_find.

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

Successfully merging this pull request may close these issues.

OpenEO processes validation suite
2 participants