What Is Our Carbon Footprint?
Demystifying CO2 Emissions Across Canada via a Developed API and Demo App
Summary
Many have seen images of the Earth that identify and display CO2 and greenhouse gas emission across the globe. However, the data that underlie these images can often lie outside the reach of non-scientists. Our goal is to demystify this data and make them accessible to the public. We used data provided by GOSAT to develop an API and an app demo that display CO2 emission from fossil fuels and other sources across Canada for all months and years between 2015 and 2018, inclusive. By bringing this data to their fingertips through our app, both curiosity and awareness about the world’s greenhouse gas emission can be sparked in the public – which can also spark communal action and wider change.
How We Addressed This Challenge
We developed two products: an application programming interface (API) and an app demo. These products use data provided by GOSAT (specifically, the ODIAC fossil fuel emission dataset provided by the Center for Global Environmental Research) in order to map the CO2 emission from a variety of sources (fossil fuels, gas flaring, international aviation, and so on). In particular, our API focuses on Canada and provides CO2 emission values for "tiles" that roughly correspond to 100 km x 100 km areas. These emission values are provided for every month in the years 2015 to 2018, inclusive. As well, a feature to compare CO2 emissions in surrounding areas is also provided, in which the user can select a "search radius" to view the CO2 emissions for all tiles within that radius. Our app demo accesses this API and displays these features and data visually, graphing the CO2 emissions for all months in a selected year and at a selected location. This shows how our API can be used to make the ODIAC fossil fuel emission data easily accessible to the public.
Our hope is that fossil fuel emission data from GOSAT can be more readily available to the public. Rather than letting this data only be deciphered and analyzed by scientists and specialists, our API and app demo act as a "middle ground" to bring the data of GOSAT to a general audience. In this way, any person can familiarize themselves with fossil fuel emission data and patterns in their own regions or others of interest. This may spark awareness about alarming emission trends, curiosity about emission sources and patterns, increased public knowledge about rising fossil fuel emission rates, and -- most importantly -- a desire, effort, and motivation from the public to act for change regarding fossil fuel emission.
How We Developed This Project
Our team consists of three brothers: Douglas, Darren, and Dylan Pereira (hence, ThreeDee Mobile). Douglas is an Android app developer; Darren is a scientist; Dylan is a maker and graphic designer. We therefore realized that this challenge would optimize our diverse skillset, by combining atmospheric science, data analysis, app development, and graphic / app design.
Seeing the breadth of our experience and talents, we immediately realized that creating an API and app that deciphered and displayed CO2 emissions data would be both doable and meaningful. We planned two major features: providing the CO2 emission at a given location (across some time scale) and providing the CO2 emission near a given location (within some radius and across some time scale). This would be available in a data format through our API, and in a visual format (graphs, coloured data points on geographical maps) in our app. This would also employ the diverse toolkit we had at our disposal: Python (as well as its libraries like netCDF4 and NumPy) could be used to decipher and analyze the data; Python could generate .json files that could be manipulated in Java to produce the API; Kotlin could be used to create an Android app that accessed the API; and Figma could be used to generate an app design and visually display the data from the API.
We therefore set out on this challenge and looked for the most suitable dataset for analyzing and providing this information to the public. We started with the OCO2 dataset, but realized halfway through the hackathon that the data was provided in an incredibly variable format: the satellites recorded "streaks" of data across the globe, over geographical areas that varied as the satellite moved, and over time scales that would need to be manually averaged over. Our initial plan was complicated by the variability in this data format, to the point of impossibility.
However, after researching other datasets, we found that the ODIAC emissions dataset did not suffer the same problems. To the contrary, its measurements were extremely consistent in geographical area, and the averaging over various time scales of measurement was already handled. Rather than abandoning our work thus far, we picked up all of the functions and features developed for the OCO2 dataset and reshaped them to fit the ODIAC dataset -- thereby producing our final product and salvaging a plan that seemed almost doomed to fail.
How We Used Space Agency Data in This Project
Earlier versions of our app and API made use of the OCO2 emissions data, as provided at https://disc.gsfc.nasa.gov/datasets/OCO2_L2_Lite_FP_9r/summary?keywords=OCO-2. We took the longitude, latitude, CO2 emission, and CO2 uncertainty data from the .nc files that had a sounding near the Toronto region. We then averaged this data over a month or year to provide an emissions profile of a selected location, as well as providing such averages for any radius away from a selected location. As mentioned earlier, however, these functions were complicated by the variability between and within datasets, so we decided to turn our attention to the ODIAC emissions dataset. Given its more consistent spatial resolution within and across datafiles, we believed the ODIAC datasets will therefore provide a more consistent and complete API for our users.
Our final product uses the ODIAC fossil fuel emission dataset for the years 2015 to 2018, inclusive, as provided at http://db.cger.nies.go.jp/dataset/ODIAC/DL_odiac2019.html. We used the .nc datafiles from 2019 that provide a 1 degree x 1 degree resolution (roughly 100 km x 100 km resolution). We implemented the same functionality as mentioned above for the OCO2 dataset, except this time with considerable less trouble given the consistency of the ODIAC datasets.
Project Demo
Demo slides:
https://drive.google.com/drive/folders/1DNEsz02_mjf13MvY7BL4wCljNCbbGD_H?usp=sharing
API documentation, demo Android app, and mobile app concept design:
https://github.com/threedee-mobile/coco-api/blob/develop/README.md
https://drive.google.com/drive/folders/1BIEQQc3PxifazeUGHMtfh8xQC7cT-Cp8?usp=sharing
Project Code
Data & Resources
Programming languages used: Python, Javascript, Kotlin
Other technologies: Firebase Cloud Functions, Firebase Database, NetCDF Python Module, Android Studio, Figma, Swagger Hub, GitHub, Trello
- https://disc.gsfc.nasa.gov/datasets/OCO2_L2_Lite_FP_9r/summary?keywords=OCO-2 (for the early version of our API and app, specifically focusing on the year 2019 and any data files that contained soundings near the Toronto region)
- http://db.cger.nies.go.jp/dataset/ODIAC/DL_odiac2019.html (for the final version of our API and app, restricted to Canada and for every month from 2015 to 2018, inclusive; the .nc files were used in order to establish a 1 degree x 1 degree, or 100 km x 100 km, spatial resolution)