[gdal-dev] gdal mdim convert and grib2

[Scott]

Even,

While a --band-description would be helpful, it doesn't solve the 
problem with this data set. Here's the .idx and all occurrences of 'APCP':

71:52927388:d=2025110401:APCP:surface:53-59 hour acc fcst:prob 
 >0.254:prob fcst 255/255
72:53775635:d=2025110401:APCP:surface:47-59 hour acc fcst:prob 
 >0.254:prob fcst 255/255
82:62041284:d=2025110401:APCP:surface:58-59 hour acc fcst:
83:62794128:d=2025110401:APCP:surface:53-59 hour acc fcst:

With a --band-description, I still wouldn't know what the QPF06 
array/band equivalent is. Right now, I'm reading the .idx file, 
selecting lines with APCP, without the string 'prob' and doing the math 
on ':53-59 hour acc fcst:' to determine if it's a 6 hour or 1 hour qpf, 
and saving the band number, then using 'gdal raster select' to download 
. It's fast, but a total hack. Not cool.

In a perfect world, the .idx would have the same keys as the array names.

Thanks for the quick response and feedback!
Scott


On 11/4/25 12:21, Even Rouault wrote:
> Scott,
> 
> is the band description (the one that is used in the classic data model, 
> and populated from the content of the .idx) somewhat predictable / 
> usable as an user input ? ("APCP:surface:53-59 hour acc fcst" in your 
> example). If so, gdal  raster select could potentially be extended to 
> accept a --band-description switch to select a band from its description.
> 
> Even
> 
> Le 04/11/2025 à 20:35, Scott via gdal-dev a écrit :
>> Using:
>> GDAL 3.12.0 "Chicoutimi", released 2025/11/03
>>
>> The following returns almost immediately, if you know the band number. 
>> Unfortunately, with this data set, the bands and arrays aren't 
>> consistent across model runs, so I can't rely on a fixed band. A 
>> grib2.idx does exist on S3 (which is why using band works so fast):
>>
>> gdal raster select -i /vsis3/noaa-nbm-para-pds/blend.20251104/01/core/ 
>> blend.t01z.core.f059.co.grib2 -o blend.t01z.core.f059.co.tif --band 
>> 132 --co COMPRESS=DEFLATE --overwrite
>>
>> The following takes over 4 minutes to complete. Downloading the file 
>> locally only takes about 20 seconds.
>>
>> time gdal mdim convert -i /vsis3/noaa-nbm-para-pds/blend.20251104/01/ 
>> core/blend.t01z.core.f059.co.grib2 -o blend.t01z.core.f059.co.tif -- 
>> array "QPF06_0-SFC" --co COMPRESS=DEFLATE --overwrite
>>
>> If I download the file first, so it's local, then it completes 
>> immediately.
>>
>> Any thoughts on speeding this up? Ideally, I don't want to download 
>> the file first.
>>
>> Thanks!
>> Scott
>>
>>