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
We currently rely on carbon instensity factors from BoaviztAPI which might be outdated, too broad geographically (#550) or time-wise (annual averages).
Solution
We could get real time carbon intensity factors instead of relying on those returned by the API. Ideally, we should cater for a number of configurable sources (watttime, electricitymaps, GB grid) and provide generic API for doing so. CarbonD does something similar.
This would give us far more accurate estimates by taking into account the day/night/seasonal variations in carbon intensities for a specific area.
This generic layer for accessing carbon intensity factors could later live as a top level project but for now could simply by added to CloudScanner.
Of course, since we know the AWS region for each datapoint, we could also do the mapping to the most accurate geographical location automatically. The users would just need to declare and configure the access to their data source.
Alternatives
Additional context or elements
The text was updated successfully, but these errors were encountered:
Problem
We currently rely on carbon instensity factors from BoaviztAPI which might be outdated, too broad geographically (#550) or time-wise (annual averages).
Solution
We could get real time carbon intensity factors instead of relying on those returned by the API. Ideally, we should cater for a number of configurable sources (watttime, electricitymaps, GB grid) and provide generic API for doing so. CarbonD does something similar.
This would give us far more accurate estimates by taking into account the day/night/seasonal variations in carbon intensities for a specific area.
This generic layer for accessing carbon intensity factors could later live as a top level project but for now could simply by added to CloudScanner.
Of course, since we know the AWS region for each datapoint, we could also do the mapping to the most accurate geographical location automatically. The users would just need to declare and configure the access to their data source.
Alternatives
Additional context or elements
The text was updated successfully, but these errors were encountered: