Refactored to separate hardcoding of the data lake. Instead, you now have to send your "data environment" to the lambda, which includes all layers, their source URIs, grids, etc. You can also derive new layers from source layers using numpy expressions. The idea here is for data API to generate this from the assets table and send it to the lambda, so you lambda is automatically in sync with the available layers on the API.
Pull request checklist
Please check if your PR fulfills the following requirements:
[X] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). Don't request your master!
[ X] Make sure you are making a pull request against the develop branch (left side). Also you should start your branch off our develop.
[X] Check the commit's or even all commits' message styles matches our requested structure.
[X] Check your code additions will fail neither code linting checks nor unit test.
Pull request type
Please check the type of change your PR introduces:
[ ] Bugfix
[X] Feature
[X] Code style update (formatting, renaming)
[X] Refactoring (no functional changes, no api changes)
[X] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):
What is the current behavior?
All URIs to data lake are hardcoded, as well as layer metadata.
What is the new behavior?
Information about available layers are passed as a parameter, which the lambda will then execute against the query
Removed all hardcoding of data lake stuff
Added support for functions on selectors - the first one is "isoweek" to convert a date field to isoweek/year fields
Updated pre-commit to follow other repos
Does this introduce a breaking change?
[X] Yes
[ ] No
I will remove support for layers ending in "isoweek" from the SQL API - must now use "isoweek(date)"
@thomas-maschler fixed all your comments. I'll probably just keep this feature branch up while I work in on the gfw-data-api side, so I don't break staging.
Refactored to separate hardcoding of the data lake. Instead, you now have to send your "data environment" to the lambda, which includes all layers, their source URIs, grids, etc. You can also derive new layers from source layers using numpy expressions. The idea here is for data API to generate this from the assets table and send it to the lambda, so you lambda is automatically in sync with the available layers on the API.
Pull request checklist
Please check if your PR fulfills the following requirements:
Pull request type
Please check the type of change your PR introduces:
What is the current behavior?
All URIs to data lake are hardcoded, as well as layer metadata.
What is the new behavior?
Does this introduce a breaking change?
I will remove support for layers ending in "isoweek" from the SQL API - must now use "isoweek( date)"