If the transformation is impossible the server may give an error...
From the standard: "Requirement 38 /req/core/getCoverage-response-trimming:
The response to a successful GetCoverage request on coverage identifier id of admissible
type containing no slicing and exactly one trimming operation with dimension name dname,
lower bound parameter evaluating to low, and upper bound parameter evaluating to high
shall be a coverage identical to c, but containing all points of c with location inside B, and
no other points.
NOTE This requirement does not specify the actual extent of the coverage returned. Possible options include: the minimal bounding box of the coverage returned, or the request bounding box. Servers are strongly encouraged to deliver the minimal bounding box."
The response to a successful GetCoverage request on coverage identifier id of admissible
type containing no slicing and exactly one trimming operation with dimension name dname,
lower bound parameter evaluating to low, and upper bound parameter evaluating to high
shall be a coverage identical to c, but containing all points of c with location inside B, and
no other points.
NOTE This requirement does not specify the actual extent of the coverage returned. Possible options include: the minimal bounding box of the coverage returned, or the request bounding box. Servers are strongly encouraged to deliver the minimal bounding box."
@jratike80 yes it seems to imply padding with no data. anyways coverages always have no data right if their data extent does not match the CRS axis
But from the developers point of view such wording is probably a nightmare. Some servers may apply padding, others don't, and the only way to know is to try. Or to play a detective "by this sort of capabilities response the server is probably MapServer, and those tend to behave this way"
Seems to be exactly like that. See for example https://github.com/OSGeo/gdal/blob/master/gdal/frmts/wcs/wcsdataset201.cpp with comments like // if axis_order_swap
// the offset order should be swapped
// Rasdaman does it
// MapServer and GeoServer not
though that is order axis :)
I have updated CubeWerx's handling of the bbox parameter at the coverage endpoint such that if it extends beyond the extent of the coverage, the full requested area will be returned (i.e., not trimmed to the coverage's extent). I have not yet adjusted the behaviour likewise for the subset behaviour, nor have I added width or height parameters. These things will come in time, but not likely within the timeframe of the sprint.
I think I have isolated the problem with the API definition (yaml file) of OGC API - Coverages. The issue that prevents compilation appears to be the JSON Schema files that are imported from http://schemas.opengis.net/cis/1.1/json/coverage-schema.json
if the media type is properly geo-referenced those nodata don't really add much value.
it's great for e.g. 16-bit PNG which cannot carry that georeferencing, or for using BBOX with rangeset for example.
(and also for use together with width / height, where width height are relative to the requested bbox... if the server is trimming the bbox to the data extent then the client will receive less cells than the specified width / height)
I was remembering that I have faced the problem with no-data fill sometimes. I found the issue but it was a bit different https://osgeo-org.atlassian.net/browse/GEOS-8893. We had some missing mapsheets in between the Finnish false-color aerial photo coverage and Geoserver was trimming the output raster to smaller extent. That might be a good test case for server developers. Just delete one image from the middle of your image mosaic or what ever you call it, make a request that partially hits the hole and see what happens.
the reocmmendation being the "current result"
Image-focused clients really might be expecting the BBOX to be filled up, and that may include GeoTIFF as an extension to a fundamentally image-based TIFF format.
however I think for very coverage-oriented foramt, the minimum data might actually be preferable.
@jratike80 right
ahh maybe not
if there is no data, is that a point of c?
If we consider data stored as a point cloud for example, there really is no concept of 'no data'.
@jerstlouis wrote:
@pomakis cool thank you! do you know offhand what width and height would map to for scalesize ?
Are you asking how a client would request a specific with and height via
the scalesize parameter? If so, the answer (four our two coverages) is scalesize=Long(640),Lat(480)
E.g.:
This should work fine in conjunction with the new behaviour of the bbox parameter.
thank you @pomakis !
@pomakis i'm curious , does the 640x480 map to the extended, or cropped extent? And did this behavior change with the new implementation?
will try to get some implementation going in the morning
good night!
(it does map to the extended extent now... so I wonder what it did before)
@jerstlouis wrote:
@pomakis i'm curious , does the 640x480 map to the extended, or cropped extent? And did this behavior change with the new implementation?
You get the requested bbox at the requested size, so pretty much exactly like a WMS request (except for the point-versus-area interpretation of the bounding box - still an item to be resolved).
Back when the requested bbox was trimmed to the extent of the coverage, you got back the requested size, but not necessarily the requested bbox.