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.

Sign up for GitHub

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

Jump to bottom

Should EMIKAT read the input data from the data package? #43

Closed
DenoBeno opened this issue Sep 2, 2019 · 2 comments
Closed

Should EMIKAT read the input data from the data package? #43

DenoBeno opened this issue Sep 2, 2019 · 2 comments
Assignees
@p-a-s-c-a-l @humerh
Labels
BB: Catalogue of ER & AO Catalogue of Elements at Risk and Adaptation Options Building Block question Further information is requested wontfix This will not be worked on
Projects
T1.3 Climate Services Co-creation T4.2 Catalogue of Elements at Risk an...

Comments

@DenoBeno
Copy link

DenoBeno commented Sep 2, 2019 •
edited
Loading

Related to:

Currently, EMIKAT "knows" which data to source for its calculation and whatever we include in the Data Package is just optional/for information.

Advantage: easier to do from EMIKAT side, robust as calculation will always work.
Disadvantage: not flexible, can lead to mismatch, if EMIKAT uses one input data and a different input data is shown in the DP.

For discussion: what should we do about this, if anything?

As I see it, our options are "leave as is" or "do it properly". ATM, I'm inclined to say "just leave it as it is for now", but we must be aware what this means:

  • EMIKAT always uses the same data for calculations (no flexibility)
  • Whatever input data is in the DP will be ignored by EMIKAT (DP and EMIKAT will eventually go out of sync, maybe they already are)
@p-a-s-c-a-l
Copy link
Member

I strongly support "leave as is" as I don't expect that you'll ever need that flexibility (YAGNI) since I'm pretty sure that we won't produce additional screening data packages.

@p-a-s-c-a-l p-a-s-c-a-l added the question Further information is requested label Sep 2, 2019
@p-a-s-c-a-l p-a-s-c-a-l added this to the 1st Data Package milestone Sep 2, 2019
@p-a-s-c-a-l p-a-s-c-a-l added this to Backlog: High Priority in T1.3 Climate Services Co-creation via automation Sep 2, 2019
@DenoBeno
Copy link
Author

DenoBeno commented Sep 2, 2019

OK, I second this.
If we ever come to the point where this may be useful AND we have enough time, then we'll think of doing it.

@DenoBeno DenoBeno moved this from Backlog: High Priority to Backlog: Low Priority in T1.3 Climate Services Co-creation Sep 2, 2019
@DenoBeno DenoBeno removed this from the 1st Data Package milestone Sep 2, 2019
@DenoBeno DenoBeno added the wontfix This will not be worked on label Sep 2, 2019
@DenoBeno DenoBeno closed this as completed Sep 6, 2019
T1.3 Climate Services Co-creation automation moved this from Backlog: Low Priority to Done Sep 6, 2019
@p-a-s-c-a-l p-a-s-c-a-l added the BB: Catalogue of ER & AO Catalogue of Elements at Risk and Adaptation Options Building Block label Oct 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@p-a-s-c-a-l p-a-s-c-a-l

@humerh humerh

Labels
BB: Catalogue of ER & AO Catalogue of Elements at Risk and Adaptation Options Building Block question Further information is requested wontfix This will not be worked on
Projects
No open projects
T1.3 Climate Services Co-creation
  
Done
T4.2 Catalogue of Elements at Risk an...
  
Done
Milestone
No milestone
Development

No branches or pull requests
3 participants
@p-a-s-c-a-l @DenoBeno @humerh