fix 330

[Yuvraj198920]

ROOT CAUSE ANALYSIS:
The issue occurs due to the architectural design of apply_dimension:

1. apply_dimension Process: Uses xr.apply_ufunc which extracts underlying dask arrays
   when calling process functions (this is by design, not a bug)
2. run_udf Function: Receives raw dask.array.core.Array instead of xr.DataArray
3. Dimension Loss: When creating xr.DataArray(data) from raw arrays, dimension
   metadata was lost because the original dimension information was not available
4. Result: UDFs received DataArrays with generic dimension names

CHANGES MADE:

1. apply.py: Enhanced apply_dimension to pass explicit dimension metadata through context
2. udf.py: Enhanced run_udf to use explicit dimension metadata when available
3. Fallback Support: Maintains intelligent dimension naming for cases without context
4. Backward Compatibility: Existing code continues to work unchanged

[Yuvraj198920]

cc @@jzvolensky @clausmichele

[Yuvraj198920]

Hi @clausmichele,

Problem: UDFs were receiving generic dimension names (dim_0, dim_1, etc.) instead of semantic names, making it difficult to access dimension labels internally.

Solution: Created a small helper function that re-assigns dimension names and labels at the beginning of UDFs using metadata from the context.

Usage:

from openeo_processes_dask.process_implementations.udf.dimension_helper import restore_semantic_dimensions

def apply_datacube(cube: xr.DataArray, context: dict) -> xr.DataArray:
    # Re-assign dimension names and labels at the beginning
    cube = restore_semantic_dimensions(cube, context)
    
    # Now you can access labels internally using semantic names
    return cube.sel(bands='B02')  # Works with real band names!

Key Benefits:

• Converts ('dim_0', 'dim_1', 'dim_2', 'dim_3') → ('time', 'y', 'x', 'bands')
• Restores real coordinate labels (band names, timestamps, spatial coords)
• Metadata-driven (no hardcoded patterns)

cc @jzvolensky