[gdal-dev] HDF5 and identified fields / primary dimension
Michael Sumner
mdsumner at gmail.com
Mon Apr 1 11:36:16 PDT 2024
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240402/836ba09f/attachment.htm>
More information about the gdal-dev
mailing list