Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/import sector benchmarks #59

Merged
merged 18 commits into from
Sep 18, 2019
Merged

Conversation

tsubik
Copy link
Contributor

@tsubik tsubik commented Sep 17, 2019

  1. Changing the structure of CP::Benchmarks

Previously CP::Benchmark has benchmarks jsonb column with different scenarios and emissions values for them. I decided to flatten that structure to incorportate scenario in the model and emissions jsonb. Import/export and data management for single benchmark is easier now, it also makes more sense.

  1. Import/export of CP Benchmarks on the new admin page for benchmark management.

image

  1. Edit form for CP Benchmark with dynamic emissions table

image

To reimport existing benchmarks

bundle exec rake import:cp_benchmarks

@tsubik tsubik requested review from kowal and simaob September 17, 2019 09:24
@kowal
Copy link
Contributor

kowal commented Sep 17, 2019

When adding new emission values like this:
Zrzut ekranu 2019-09-17 o 12 20 50
.. no error is raised and the value is not added. I think we should either show an error or allow to update it without the emission.

@tsubik
Copy link
Contributor Author

tsubik commented Sep 17, 2019

Hmm, I think it worked without providing emission, let me check

@tsubik
Copy link
Contributor Author

tsubik commented Sep 17, 2019

Ok, @kowal I fixed that.

end

csv do
year_columns = collection.flat_map(&:emissions_all_years).uniq.sort
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be more readable to extract this somewhere. Maybe some decorator / helper?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, just this one line? not sure if that would help for me this is readable

table_for benchmark.benchmarks, class: 'cell-padding-sm cell-centered' do
column :name do |b|
b['name']
resource.cp_benchmarks.latest_first.group_by(&:release_date).map do |release_date, benchmarks|
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here as well, some logic could be extracted to view helpers

end

def average_emission
not_empty_values = emissions.values.compact
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

none_empty_values?

def parse_float(value)
return unless value.present?

value.to_f
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

value&.to_f but maybe current code is more readable..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will change it back, actually, it does not make sense to keep empty values. The same I will change in the interface, empty values will be discarded when saving.


def emissions(row)
row.headers.grep(/\d{4}/).map do |year|
{year.to_s.to_i => parse_float(row[year])}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

row.headers.grep(EMISSION_VALUE_PATTERN)
  .map { |year| {year.to_i => parse_float(row[year])} } # to_s is really needed?
  .reduce(&:merge)

Also I got a feeling we can replace .map {}.reduce { } with just one .reduce { }.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true, good point

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure why to_s is here, maybe it was needed. I copied that from climate watch, but I can remove it, we will see :P

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I know why to_s year is a symbol.


validates_presence_of :date
validates_presence_of :release_date, :scenario
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should validate scenario with inclusion on the known scenario list (https://github.com/Vizzuality/laws_and_pathways/pull/57/files#diff-bcd1663b967ed112eee68c615f3ac627R4)?

@simaob do you know if that list (of scenarios) should be open or rather strict? Do we need to manage this list as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would keep that as just a name with the flexibility to change to whatever. They already have different names for different release dates and sectors. As long we don't need any complex reports it should be fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm but later we will need only a known list of scenario on the frontend. How will we map it if there are more scenario types in the DB?

Zrzut ekranu 2019-09-18 o 12 17 42

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You only need names, and those benchmarks need to be grouped by release_date and only one benchmark group should be taken (everything depends on assessment date - an appropriate benchmark should be taken by date). Scenario names will be from that chosen benchmark group.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if the colour has any meaning, I can try to double check with Fausto. If not we can have a number of colours that are flexible enough to an expected number of scenarios and then sort them always the same way, so that they always get the same colour. Something like that?

Copy link
Contributor Author

@tsubik tsubik Sep 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can only show data against one benchmark set/group.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the color has meaning from the lowest to the highest scenario we can add colors based on the average of emission values, scenario name won't matter that much.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh right, good point!

Copy link
Contributor Author

@tsubik tsubik Sep 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kowal is right here, on the image above I can only see the top of the chart, but looks like that chart needs standardized scenario names across different sectors. They are not standardized now, so I believe in the next iteration when we know that all scenarios are the same we can add validation to be only those from strict list.

@tsubik tsubik force-pushed the feature/import-sector-benchmarks branch from f1fdd08 to 45788b2 Compare September 18, 2019 12:31
@tsubik tsubik merged commit 51d20cb into develop Sep 18, 2019
@tsubik tsubik deleted the feature/import-sector-benchmarks branch September 18, 2019 12:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants