Should we provide configuration for required tiling parameters?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- typescript
- Domain
- backend-api-design
Research direction
Start by reviewing the render extension and example collections containing datetime, variable, and collection_concept_id. Compare the requirements of titiler-cmr and titiler-pgstac, then resolve whether parameters and tiler endpoints belong in the extension. Done means the project has an agreed configuration shape and documented behavior.
Written by the indexing model from the issue text.
Description
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?
- Dominant language
- TypeScript
- Stars
- 4
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from developmentseed/stac-explorer
-
Difficulty 5/5 Over a week Newbie friendliness 28/100
developmentseed/stac-explorer#31 · 3 comments · 3 reactions ·
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
-
Issue 1Openissue-1
Difficulty 5/5 Over a week Newbie friendliness 20/100
All issues in developmentseed/stac-explorer
Similar issues
-
calcite-ui-icons enhancement impact - p3 - not time sensitive needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Esri/calcite-design-system#15467 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
diegosouzapw/OmniRoute#18390 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 1/5 1-3 hours Newbie friendliness 86/100
guilhermerodz/input-otp#157 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
davidjerleke/embla-carousel#1414 ·
Maintainers usually reply within 4 days