[gdal-dev] Multidimensional raster support in GDAL

[Ari Jolma]

Even Rouault kirjoitti 21.11.2017 klo 16:06:
>
> > and different time steps as bands.
>
> My reading of the code and doc of the current driver is that time 
> steps are treated as subdatasets, and not bands.
>

Yes. My mistake.

> > I'm not sure if there are many people
>
> > using it since I believe the functionality is currently broken when used
>
> > together with MapServer. The brokenness seems to be so serious that when
>
> > making a gdal_translate call where the source is a WCS that has a field
>
> > with more than one band (and GDAL recognizes it as such) and the call
>
> > does not involve scaling, the call fails.
>
> Is it really an issue specific of time or something more general about 
> multiband support ?
>
> I've just spent some time looking at mapserver code & doc, and there's 
> some confusion regarding multiband support . In particular the WCS 2.0 
> code has a mode where it uses the WCS 1.x mapfile metadata item 
> "wcs_rangeset_axes" in a way not compatible with the WCS 1.x 
> implementation, see
>
> https://github.com/mapserver/mapserver/pull/5523
>
> However for WCS 1.0, I managed to make band subsetting work with the 
> following conf in the mapfile (no time component)
>
> "wcs_bandcount" "9"
>
> "wcs_rangeset_axes" "bands"
>
> "wcs_rangeset_name" "Landsat 5 TM Bands"
>
> "wcs_rangeset_label" "Bands"
>
> "wcs_rangeset_description" "Bands for Landsat 5 TM"
>
> DescribeCoverage reports:
>
> <rangeSet>
>
> <RangeSet>
>
> <description>Bands for Landsat 5 TM</description>
>
> <name>Landsat 5 TM Bands</name>
>
> <label>Bands</label>
>
> <axisDescription>
>
> <AxisDescription>
>
> <name>bands</name>
>
> <label>Bands/Channels/Samples</label>
>
> <values>
>
> <singleValue>1</singleValue>
>
> <singleValue>2</singleValue>
>
> <singleValue>3</singleValue>
>
> <singleValue>4</singleValue>
>
> <singleValue>5</singleValue>
>
> <singleValue>6</singleValue>
>
> <singleValue>7</singleValue>
>
> <singleValue>8</singleValue>
>
> <singleValue>9</singleValue>
>
> </values>
>
> </AxisDescription>
>
> </axisDescription>
>
> <nullValues>
>
> <singleValue>0</singleValue>
>
> </nullValues>
>
> </RangeSet>
>
> </rangeSet>
>
> And the following GetCoverage request succeeds and returns 3 bands
>
> SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCoverage&COVERAGE=multi&FORMAT=GEOTIFF_8&BBOX=15,48,16,49&bands=9,5,1&CRS=EPSG:4326&WIDTH=5&HEIGHT=5
>

So it's a misconfiguration at 194.66.252.155

http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=GetCoverage&VERSION=1.0.0&COVERAGE=BGS_EMODNET_CentralMed-MCol&FORMAT=GTiff&BBOX=9.83125,44.05624829,14.09792008,46.18958333&WIDTH=1024&HEIGHT=512&CRS=EPSG:4326&bands=1

returns 3 bands although the DescribeCoverage is similar.

> > The reason seems to be that
>
> > gdal_translate accesses the data band by band.
>
> gdal_translate (actually GDALDatasetCopyWholeRaster()) uses the 
> INTERLEAVE=PIXEL/BAND metadata item of the IMAGE_STRUCTURE domain as a 
> hint whether to read band by band or all bands together
>
> So if you add the following, it should request all bands :
>
> poDS->SetMetadataItem("INTERLEAVE", "PIXEL", "IMAGE_STRUCTURE")
>

ok, with that I can remove the need for the user option. And probably it 
is anyway usually better,

> >
>
> > I guess my point is here is that this is another difference between the
>
> > GDAL data model and the general coverage data model. The simple approach
>
> > to the data model mismatch is to allow GDAL datasets to be made from
>
> > coverage sources with queries. Also one thing I realized I need for the
>
> > new WCS driver is something which distinguishes different GDAL datasets
>
> > made from a single coverage.
>
> I'm not sure what you have in mind,
>

Somehow the user must be able to write

dataset_1 = GDAL.Open("WCS:URL?coverage=coverage_a")
dataset_2 = GDAL.Open("WCS:URL?coverage=coverage_a")

So that for example dataset_1 is band c from coverage_a and dataset_2 is 
band d from the same coverage (this example is stupid but I think this 
is a valid issue with more complex coverages). I guess that needs to be 
in the dataset name somehow since that is the key to to service file.

Ari

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171121/bb238cdc/attachment.html>