[gdal-dev] HDF5 and identified fields / primary dimension

[Michael Sumner]

well actually, I think what I'm asking for is the intended behaviour, but
there's an error.

Is it meant to detect sets of variables on 1D dimensions and present them
as layers? That's what would make sense to me.

Still exploring.

Cheers, Mike



On Tue, Apr 2, 2024 at 5:36 AM Michael Sumner <mdsumner at gmail.com> wrote:

> This source has an array on 'feature_id' with 2729077 values, with various
> fields
>
> elevation, longitude, latitude, qBtmVertRunoff, qBucket, etc
>
>
> '/vsis3/noaa-nwm-retro-v2.0-pds/full_physics/2017/201704010000.CHRTOUT_DOMAIN1.comp'
>
> It is accessible via the mdim api.
>
> Structurally it is basically a table with rows per feature_id and  columns
> per fields, but it has a length-1 pair of fields "time" and
> "reference_time" defined on dimension time, this is like a single time step
> per file (like an unlimited dimension in the classic 2D case).
>
> Accessing with the vector API reports that it can't treat this as a table
> because of those time values that don't match the feature_id dimension:
>
> ogrinfo
> NETCDF:'/vsis3/noaa-nwm-retro-v2.0-pds/full_physics/2017/201704010000.CHRTOUT_DOMAIN1.comp'
> -ro
>
> Warning 1: The dataset has several variables that could be identified as
> vector fields, but not all share the same primary dimension. Consequently
> they will be ignored.
>
> I've seen similar cases in other files. I presume the driver could be
> updated to 1) choose the primary dimension and read the values while ignore
> others 2) user-specify the dimension to include, or 3) user-specify the
> fields to exclude
>
> So:
>
> - is there a workaround to enable the vector driver to focus on the
> primary dimension?
> - would a PR along those lines have to consider greater difficulties than
> applying the proposed updates to arrays using the primary dimension only?
>  I'd only consider this for strictly 1D arrays.
> - degenerate dimensions could be used to copy-out the value of the other
> dims (I'd consider this an optional extra)
>
> (It's a bit special-case-y, you wouldn't want to go to multi-arrays and
> have them flatten out multi-dims in a general way, I think, but degenerate
> dimensions might be worth consideration )
>
> Appreciate any thoughts, thanks! I'd quite like to have the
> vector-approach work as well as the mdim approach, I think they are nicely
> complementary and provide different pros and cons.
>
> Cheers, Mike
>
> --
> Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> Hobart, Australia
> e-mail: mdsumner at gmail.com
>


-- 
Michael Sumner
Software and Database Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsumner at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240402/d15c011d/attachment.htm>