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 the source of the caron intensity factors.
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 the source of the caron intensity factors.
Alternatives
Additional context or elements