GetCapabilities response for non-2D coverages

[Piero Campalani]

The summary of coverages which are not 2D is wrong in the GetCapabilities response.

E.g., for 3D the reported dimensions are 2:

<CoverageSummary>
  <CoverageId>eobstest</CoverageId>
  <CoverageSubtype>RectifiedGridCoverage</CoverageSubtype>
  <BoundingBox xmlns="http://www.opengis.net/ows/2.0" crs="http://www.opengis.net/def/crs/EPSG/0/4326" dimensions="2">
    <LowerCorner>25.0 -40.0</LowerCorner>
    <UpperCorner>75.0 75.0</UpperCorner>
  </BoundingBox>
</CoverageSummary>

For 1D the bounding box is not reported:

<CoverageSummary>
  <CoverageId>OneD</CoverageId>
  <CoverageSubtype>GridCoverage</CoverageSubtype>
</CoverageSummary>

[Piero Campalani]

The ows:BoundingBox is not mandatory in a GetCapabilities::CoverageSummary, and the proposed solution would be to avoid listing unofficial compound crs URIs when possible.

Thus, we propose to remove this element from a GetCapabilities response while keeping the envelope information available in the DescribeCoverage::boundedBy element.

Future developments of CRS management will allow a more flexible management of mixed-CRSs coverages.

[abeccati]

Sounds good for 8.4 we might reintroduce that also in getCapabilities afterwards if needed to avoid a "special case" scenario. You then have probably to resubmit a patch for this and your previous one be reverted/rejected

[Piero Campalani]

The solution I implemented in the patch "Optional bounding box element in GetCapabilities response to be set for 2D single-CRS coverages (ticket #283)." is to show up additional bbox information in case of coverages that fit in the ps_crsdetails table, hence 2D and with no CRS compounding.

If that solution is not accetpable, and a fixed behaviour is required for all the offered coverages, then the patch can be rejected and I'll proceed to the removal of the BoundingBox instead.

[Piero Campalani]

Ticket addressed in 097dccc.