flowsa
flowsa copied to clipboard
USEPA
Library that attributes resource use, waste, emissions, and loss to economic sectors
Some datasets contain time series data from a single source. Current approach requires that for every year of FBA desired, the data source must be called and parsed in a...
- Updates EPA_GHGI through 2022 from draft csv files (2012-2022) - New BEA data for 2017-2022 (Summary & Gross Output), 2017 Detail (using 2017 BEA schema) - BEA_Detail FBS for...
Need details on use including; - loading local or remote datasets or regenerating them -
Option to append material codes to sectors in FBS was dropped with v2.0.0 release. Re-add this ability.
Add option to generate FBS that are mapped to: - International Standard of Industrial Classification (ISIC) codes, which are used by the UN - BEA codes, as NAICS are mapped...
FBS method files that are heavy with `!include` are slow to load. e.g., [GHG_national_2020_m2.yaml](https://github.com/USEPA/flowsa/blob/8e7970fb7adb2cd618fafe85f9e29717705ebdd4/flowsa/methods/flowbysectormethods/GHG_national_2020_m2.yaml). Relatedly, even when just accessing an FBS, the method file must be loaded [here](https://github.com/USEPA/flowsa/blob/state_GHGI_v2/flowsa/flowbysector.py#L95-L105), which I...
Due to the way `esupy.processed_data_mgmt.write_df_to_file()` is written and how it is used in `flowsa.flowbysector.FlowBySector.generateFlowbySector()`, setting `flowsa.settings.fbsoutputpath` does not affect where the FBS ends up getting saved.
When I generate an FBS using an external method, the metadata for the generated FBS contains a fictitious link to the `yaml` file on the USEPA github.
Methods have become increasingly complex and split across multiple files. It would be nice to have a function in the API that can grab the full combined method, e.g., what...