width and height parameters

[jerstlouis]

Could we add width and height parameters as part of Scaling requirement class?

These would be equivalent to using scale-size=Lat(height),Lon(width) for a geographic CRS or scale-size=E(width),N(height) for a projected CRS with axis names E and N (or corresponding horizontal and vertical axes), and would only be supported in cases where there is such a correspondence.

A major advantage of this is that it would provide a common ground syntax with OGC API - Maps (which already supports subset=) with the only difference being that /coverage returns the raw data whereas /map returns a visualization of the data.

There is a related mention of OGC API - Coverages in 6.4.2. Implementing OGC API - Maps within a Web API .

[chris-little]

@jerstlouis Are you missing an opportunity to future proof the API here, in the cause of backward compatibility? I discussed the same issue with @cnreediii in the tiling model.

When maps/images are displayed on a screen, which is usually, but not always, nearly vertical, or even a teletype/printer, it makes sense to use the terms height and width for the extent of the viewing space. But for maps displayed horizontally, on a table, or in a VR/AR environment, or in 3D, other terms may be more useful.

What if the coverage is a vertical one? E.g. (z,t) or (x,z).

[jerstlouis]

@chris-little We can think of these width and height as convenience parameters, which only apply for coverages with Lat/Lon and/or Easting/Northing dimensions, which is a common use case.

The objective is to have at least "some" overlap between the OGC API - Coverages and OGC API - Maps Scaling (resolution of interest), while currently there is none.

• OGC API - Maps defines scale-denominator, width and height
• OGC API - Coverages defines scale-factor, scale-axes and scale-size

An alternative would be to bring scale-size over to OGC API - Maps -- this would provide a mechanism to independently control the scaling of vertical maps etc.

In Maps, width and height correspond to the width and height of the viewport on which the data is being rendered, which normally does not exclude the (z,t) or (x,z) cases, but in those cases it is not as obvious which dimension width and height map to.

The intent is definitely not to exclude anything, but to have an easy way to switch between retrieving raw data vs. visualization of same data (i.e., Common parameters building blocks between Maps & Coverages).

cc. @joanma747

[jerstlouis]

February 2024 OGC API - Coverages Sprint: we agreed that this alignment would be very useful, and that in cases where there is an unambiguous correspondence between width and/or height and the coverage dimensions, this functionality can easily be mapped to the scale-size requirements.