You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
/validation: let back-ends report empty data selections (e.g. NoDataAvailable) #601
Interactive clients (web editors, XYZ/WMTS services) find empty data selections only when processing fails. For example, a load_collection with a spatial/temporal extent that has no items. With secondary web services, each tile request fails. The client then has to infer from many tile failures that the process graph selects no data.
The current text of POST /validation says that "checking whether the arguments are adequate in the context of data is OPTIONAL" and that "errors that usually occur during processing MAY NOT get reported". So clients cannot rely on validation for this case. In practice, back-ends do not check it. For example, titiler-openeo raises NoDataAvailable (HTTP 404) only at tile time.
Proposal
Add a standard error code NoDataAvailable to errors.json for "the data selection of the process graph has no data". Some back-ends already use this code.
In the /validation description, RECOMMEND (but do not require) that back-ends do a light availability check for load_collection (spatial_extent, temporal_extent, properties) when this is cheap to do. For example, a catalog search with limit=1.
Let back-ends report this result as a non-blocking warning, not as an error, because data can become available later. One option is a warnings array next to errors in the response, or a level field on each item. A client could also ask for the check with a parameter, because the check costs a catalog search.
Related
Process graph simulation #243 (process graph simulation / /explore). That issue would also let clients find empty cubes before they execute a graph.
Activity