There's a difference between stating the coordinate system of the requested bounding box (bbox-crs) and the coordinate system of the response (crs). For raster maps these two must be the same, and there's no point in having two separate parameters, so they've chosen to stick with "bbox" dor consistency with WMS.
(for BBOX)
also regarding rastermap and bbox-crs, I still disagree they have to be the same. if I have some regional CRS that I want to return the data in, I might not really know the coordiantes well so want to use the familiar WGS84 BBOX. My returned image is a GeoTIFF still properly georeferenced.
@jratike80 a distinction in Features thouhg is that Features intersects rather than clip. so I suggest a ClipBBOX for Features.
and with this you have an easy way to cut out map, features or coverages tiles with a simple bbox (clipbox for Features), width & height.
(For tiles)
connecting all the main OGC APIs.
@jratike80 having both options as conformance classes allow people to implement their preferences :) hopefully servers implement both, so clients have their favorite choice available.
rangeset would surely be its own endpoint, yes
@jerstlouis Arbitrary-dimension width and height support are already provided through the WCS 2.0 SCALESIZE parameter, but I suppose specific WIDTH and HEIGHT parameters could also be added as companion parameters to the BBOX parameter. I'm hesitant, though, to provide so many alternate ways of making the same request. As for a BBOX request extending beyond the coverage's extent and returning NODATA values, we could easily implement it that way, perhaps based on a boolean request parameter, if it really is a desired option.
and I do feel that for consistency with Maps the NODATA should be default bbox behavior.
I have a feeling that different servers will re-project the bbox given in the default CRS:84 coordinates into the native BBOX with slightly different algorithms and therefore return slightly different results sometimes. That's OK if documentation encourages to use native subsetting if result needs to be accurate to last points and pixels.
if using BBOX with native CRS (e.g. with bbox-crs option), then SUBSET vs. BBOX is just a syntax thing
agreed the specification should make recommendation on how to transfer the data unaltered
if using BBOX with native CRS (e.g. with bbox-crs option), then SUBSET vs. BBOX is just a syntax thing
I have met cases when software is doing things which mean the same through different code paths. I bet I could find some unresolved bug reports as examples. But we are building new programs and we know to be careful. I am an optimistic person and I trust that things will go well.
@tomkralidis btw ease of server implementation (including simple static use cases) was why I made that embedded or linked suggestion, but in the end perhaps client-side interoperability concerns trumps that... I will let you and Keith and others chime in on what's best for that :)
if those are not there then one can look for link relations. Or vice-versa.
itemType is specific to the use of /items
and a collection may be offeres a both coverages & features.
if provided as a link, alternate representation (e.g. CovJSON) may also be defined, but the CIS JSON is required.