Should we provide configuration for required tiling parameters?

[oliverroick]

There are query parameters that tiling backends expect or accept but which aren’t specified in the collection document. In the example collections so far, we have datetime, variable or collection_concept_id.

There is no way for a client to tell, which of these parameters need to be passed to the tiler in addition to those specified in the render extension. For example, datetime can be a single date or a range, depending on the tiler. variable and concept_id are only required for titiler-cmr implementations but not for titiler-pgstac.

Should these parameters be advertised the render extension? There could be an addition block called parameters that indicates what parameters the tile expects and accepts in addition to those defined in the each render object.

{
  "renders": {
    "parameters": {
      "variable": {
        "type": "string",
        "required": true
      },
      "concept_id": {
        "type": "string",
        "required": true
      },
      "datetime": {
        "type": "datetime",
        "required": true,
        "extent": "range"
      }
    }
  }
}

Likewise, if these parameters are tiler-specific, should the tiler endpoint be advertised in the render extension as well?

[abarciauskas-bgse]

• I think datetime make sense if its the range of valid values, but then I wonder if the specification should also indicate periodicity
• variable also makes sense, to me, since I know we are tiling from netCDF4/HDF5/zarr, but there may be some concern this should just be "assets"
• concept_id is specific to our CMR integration so I'm not sure that would make it into the renders extension specification, but I would be happy to hear other opinions.

@oliverroick do you want to open an issue in the renders extension github repo and tag Saadiq and Emmanuel?