-
Notifications
You must be signed in to change notification settings - Fork 3
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
Conversation
Hmm, I think it worked without providing emission, let me check |
Ok, @kowal I fixed that. |
end | ||
|
||
csv do | ||
year_columns = collection.flat_map(&:emissions_all_years).uniq.sort |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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| |
There was a problem hiding this comment.
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
app/models/cp/benchmark.rb
Outdated
end | ||
|
||
def average_emission | ||
not_empty_values = emissions.values.compact |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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..
There was a problem hiding this comment.
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])} |
There was a problem hiding this comment.
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 { }
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
true, good point
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh right, good point!
There was a problem hiding this comment.
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.
f1fdd08
to
45788b2
Compare
Previously CP::Benchmark has
benchmarks
jsonb column with different scenarios and emissions values for them. I decided to flatten that structure to incorportatescenario
in the model andemissions
jsonb. Import/export and data management for single benchmark is easier now, it also makes more sense.To reimport existing benchmarks