opengeospatial/OGC-API-Sprint-August-2020

jratike80

@jratike80

If the actual extent of the coverage returned = request bounding box, how it can be possible without having missing samples filled with nodata?

Jerome St-Louis

@jerstlouis

map tile at https://maps.ecere.com/ogcapi/collections/SRTM_ViewFinderPanorama/map/tiles/GNOSISGlobalGrid/2/2/8

@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

jratike80

@jratike80

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"

Jerome St-Louis

@jerstlouis

particularyl problematic if you're asking for a PNG with no geospatial referencing!

jratike80

@jratike80

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

Jerome St-Louis

@jerstlouis

@jratike80 !! :)

though that is order axis :)

Keith Pomakis

@pomakis

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.

ghobona

@ghobona

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

Jerome St-Louis

@jerstlouis

@pomakis cool thank you! do you know offhand what width and height would map to for scalesize ?

Jerome St-Louis

@jerstlouis

So I am wondering if this 'extend' behavior couldn't actually be dependent on the representation...

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)

jratike80

@jratike80

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.

Jerome St-Louis

@jerstlouis

@jratike80 it would seem that the issue description is not accurate based on what you pasted earlier?

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

@jratike80

You mean the description of the old Geoserver issue, or?

Jerome St-Louis

@jerstlouis

in those there really isn't anye expectation of a canvas of a certain size on which data was returned

@jratike80 right

ahh maybe not

jratike80

@jratike80

it was a long time ago but obviously Andrea Aime considered that it was a bug according to WCS 2.0 because he filed the bug and resolved it

Jerome St-Louis

@jerstlouis

"all point of c"

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'.

jratike80

@jratike80

Oh, but in theory coverages probably don't have holes. This was real world dataset and we did not have a tiff in the hole telling that the area is nodata. There were just missing data.

Keith Pomakis

@pomakis

@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.:

https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections/Daraa_mosaic_2019/coverage?scalesize=Long(640),Lat(480)

This should work fine in conjunction with the new behaviour of the bbox parameter.

Jerome St-Louis

@jerstlouis

but thats the irregular coverage thing right when it can have holes

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?

jratike80

@jratike80

We are getting to the topics for the late night discussions really. What's the difference of having no-data and having no data at all!

Jerome St-Louis

@jerstlouis

@jratike80 yes I need to get some sleep ;)

will try to get some implementation going in the morning

jratike80

@jratike80

You are damn right, it is 02.02 local time. Bye!

Jerome St-Louis

@jerstlouis

@jratike80 I was referring to e.g. the time dimension in particular, where some geographic areas might have pictures on a certain dates, but not all dates

good night!

(it does map to the extended extent now... so I wonder what it did before)

Keith Pomakis

@pomakis

@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.

Jerome St-Louis

@jerstlouis

@pomakis so that would mean you would receive a different 'scaling factor' tahn you asked for!

(before)

I like that this is potentially addressed, but I think we should consider for a very coverage-native format like netCDF whether introducing NODATA values make any sense... I think this resolved a scaling behavior confusion when specifying a desired target size with scalesize...

(potentially this could be addressed by something like "if the requested representation is a format which may be used by applications not aware of geo-referencing, such as TIFF (incl. GeoTIFF) or PNG , or when doing subsetting on the range set (consisting of raw data values without any referencing), the data shall be extended to match the requested bbox...") Regardless of the representation, the scaling behavior for specifying a target size shall always be based on the requested bbox (whether scalesize or width&height).

Keith Pomakis

@pomakis

@jerstlouis wrote:

@pomakis so that would mean you would receive a different 'scaling factor' tahn you asked for!

Not really. You'd receive an image of the requested size, covering the portion of the coverage that intersects the specified bounding box. (Not as nice as what we have now, I admit, but still reasonably well defined.) There's a separate scalingFactor parameter (e.g., scalingFactor=0.1), but as an alternative to specifying an exact width and height.

Jerome St-Louis

@jerstlouis

@pomakis but presumably you specified that subset and scalesize based on an expected target resolution (especially if you are coming from the more popular WMS standard) and were surprised and confused by the results :)

the odds are if you specify a target size for an area, that's the number of cells you wanted for that whole area.

I would argue it was not well defined, as the server was not required to trim to the cropped extent

Keith Pomakis

@pomakis

@jerstlouis Since we're making these requirements up as we go along, the server was as required to trim to the coverage's extent as it is now required not to. :-)

Where communities thrive

People

Repo info

Activity