Comments (5)
But how should we handle it when some of the scientific sources we use have higher precision?
Good point - I think this could be an exception.
from electricitymaps-contrib.
I don't think these need to be rounded in the config file if they're just intermediate results from some calculation like the ETS/ENTSO-E mapping. Otherwise, you could argue that before starting the emission factor calculation, total emissions and total electricity generation of each plant should be rounded as well, and then round those intermediate emission factors of power plants before combining them for the country factor. So IMHO, intermediate values should be stored in high precision. (Of course we don't really need 7 decimal places, but I wouldn't say that's something that needs fixing either.)
When emission factors are displayed in the app / website for public consumption though, they should always be rounded in some way of course, to avoid the misleading impression. I believe that's already implemented everywhere?
from electricitymaps-contrib.
I don't think these need to be rounded in the config file if they're just intermediate results from some calculation like the ETS/ENTSO-E mapping. Otherwise, you could argue that before starting the emission factor calculation, total emissions and total electricity generation of each plant should be rounded as well, and then round those intermediate emission factors of power plants before combining them for the country factor. So IMHO, intermediate values should be stored in high precision. (Of course we don't really need 7 decimal places, but I wouldn't say that's something that needs fixing either.)
When emission factors are displayed in the app / website for public consumption though, they should always be rounded in some way of course, to avoid the misleading impression. I believe that's already implemented everywhere?
Thanks for your view and insights, and yes they are already rounded in the frontend.
And I suppose an argument could be made that these values are actually highly accurate (not accounting for floating point errors) but are missing some source data (not all plants have emissions reported and vice versa) which makes the derived value "wrong" but accurate.
from electricitymaps-contrib.
I think rounding to the whole number makes the most sense, at least for our calculated numbers, otherwise things might be even weirder since nuclear currently is below 10g for most of Europe.
But how should we handle it when some of the scientific sources we use have higher precision?
from electricitymaps-contrib.
Related Issues (20)
- aggregated view CO2 sum seems strange, yearly CO2 sum probably not updated after emission factor correction HOT 8
- [Data Issue]: Upstream emissions for gas in Europe are not specified. HOT 10
- Nova Scotia (CA-NS): Near real-time data on e.g. load, wind, and imports (not lumped together!) and exports HOT 1
- ElectricityMaps crashes after switching to another tab while the app is loading HOT 1
- Consumption of imported nuclear missing from US-SW-PNM (and nearby zones) HOT 7
- Errors in SW USA zone boundaries
- [Data Issue]: CZ solar installed capacity
- [Data Issue]: Difference between production and consumption implies unexpectedly high electricity imports for Germany HOT 5
- Add an option to not show the nuclear energy in green HOT 4
- Potential issues with solar and wind layers on Android devices HOT 1
- [Data Issue]: IT-* zones are not getting parser data anymore HOT 1
- Battery capacity in Belgium
- Imports emissions doesn't account for zone vs country
- Net exchange is not translated HOT 2
- Create easily citable SoMe replies to ideological debates
- AU-TAS-KI production parser down HOT 3
- Getting data for middle of Atlantic Ocean using API. HOT 3
- ENTSO-E parser is failing for GB-NIR price data HOT 4
- Germany's solar load factor bug ? HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from electricitymaps-contrib.