We're updating the issue view to help you get more done. 

Multidimensional coverage files with more than 32 bands

Description

I am trying to display a Grib file with more than 32 bands in Geoserver. Creating a coverage store works, however, creating a layer from it fails with a stacktrace which ends with this:
=======================
...
Caused by: ucar.ma2.InvalidRangeException: Illegal Range for dimension 1:
last requested 32 > max 0
at ucar.ma2.Section.fill(Section.java:179)
at ucar.nc2.Variable.read(Variable.java:709)
at
org.geotools.imageio.netcdf.NetCDFImageReader.readSection(NetCDFImageReader.java:919)
... 137 more
=======================

This file can be used to demonstrate the problem:
https://tgftp.nws.noaa.gov/SL.us008001/ST.opnl/DF.gr2/DC.ndfd/AR.conus/VP.001-003/ds.rhm.bin

If I subset the file to 32 bands, it works as expected.

Upon further inspection, I traced the problem to the index in getImageIndex
in GeoSpatialImageReader.java is returned unsorted, like this:
*[32 33 34 ... n 0 1 2 3 ... 31] *, where n is the number of bands

The granule list returned by slicesCatalog is not sorted for files with more than 32 bands.

Sorting the index prior to returing it resolves the issue:

1 2 3 4 5 6 7 8 9 10 11 12 public List<Integer> getImageIndex(Query filterQuery) throws IOException { List<CoverageSlice> descs = slicesCatalog.getGranules(filterQuery); List<Integer> indexes = new ArrayList<Integer>(); for (CoverageSlice desc : descs) { Integer index = (Integer) desc.getOriginator().getAttribute(CoverageSlice.Attributes.INDEX); indexes.add(index); } Collections.sort(indexes); return indexes; }

Environment

None

Status

Assignee

Unassigned

Reporter

Alexander Petkov

Triage

Components

Priority

Medium