How to relate between data packages, study types and calculation methods?

[DenoBeno]

Related to: #90

Data packages can not be used with all study types. We need to somehow indicate which ones are compatible with what study types/calculation methods.

That is:

• Data packages listing the resources that contain $emikatid variable are only usable with the studies that call EMIKAT to perform a screening. Currently, this is only the case with "Screening: urban infrastructure"
• Data packages not listing such resources are currently only usable with the "expert" studies.
• No idea what will happen in the future, but possibly there will be other study types (very likely) that use a different calculation method (less likely in this project). We could also decide to split the calculation method in several steps and cleanly indicate what steps are to be performed depending on the study type, in which case the calculation methods will multiply (e.g., should we calculate the heat impact, flooding impact or both?)

For discussion

1. How should we indicate the DP/study compatibility in the data package?
I can see two possibilities: either by linking to the study types or to the calculation method taxonomy. Both methods have advantages:
-- calculation method link: allows us to add new "screening" study types without changing the data package
-- study type link: allows us to differentiate e.g. between "expert" data packages with the urban infrastructure data and those with the transport infrastructure related data.

Q: Which one should we go for? Or even allow both and let the logic down the road deal with the potential issues?

2. Where to store this information?
As discussed earlier today, this information could be handled in the same way as other "tags", but this is a data package level information and the tags are in the ressources. So we may need to add (at least one) new field to the data_package.

Q:: any suggestions/opinions?

**3. How to ensure the compatibility of the DP and the study type/calculation method?

"Expert" data packages are relatively simple. They just have to provide all the data that we can visualize in the DP.

"Screening" DPs are not so simple, for two reasons:

• The way I understand this, EMIKAT is currently hardcoded to source its data from somewhere, but in principle it could look it up in the DP. Issue at hand: how would EMIKAT even know which data resource in the DP corresponds to a parameter that it needs?. Or any other service that we might add in the future...
• Even if we ignore this for a moment, the data package still needs to define some resources that will be produced by EMIKAT on the fly. Currently, this is the case for the population density ressource in the Europe-wide data package. In the future, we will either need to add more such resources or find a different way for dealing with this issue. (I'll open a separate ticket for this one)

Q:: any suggestions/opinions?

@p-a-s-c-a-l , all: WDYT?

[p-a-s-c-a-l]

Data Package filtering is not implemented ATM: you could select a data package that does not contain any data for the selected study area. So this is a more general problem.

I would put this on hold and come back when we have our 1st screening data package defined and are actually able to create, calculate, visualise and asses (MCDA!) screening studies.

[DenoBeno]

After discussion with @patrickkaleta, this is what we recommend

Step 1: add a field to the data package to indicate which calculation methods (1..* if we count "no calculation" method as one) it supports.
Step 1b: allow multiple calculation methods in study types too.

Step 1 is easy, we should do it ASAP.

Step 2: assure that only the data packages are shown that provide (resources for) all the calculation methods that the study type requires

This is more difficult, but we have done something similar on DRIVER already (choice of solutions in trial). @fgeyer16 , do you remember what was necessary fo this to work?

Maybe this: https://www.drupal.org/project/entity_browser/issues/2790951 ?

Step 2b: also take into account the spatial aspect. If the data package is for Italy and the study is in Austria, it should not be shown.

This is similar to step 2, but involves geospatial "is polygon A within polygon B" operation. I have no idea if this is supported in Drupal.

[DenoBeno]

Step 1 is implemented.

[patrickkaleta]

Since I had a little bit of time I had a look at this issue again...

After discussion with @patrickkaleta, this is what we recommend

Step 1: add a field to the data package to indicate which calculation methods (1..* if we count "no calculation" method as one) it supports.

This was done already weeks ago. DP has a field calculations methods (1..*) and it references our Calculation methods taxonomy

Step 1b: allow multiple calculation methods in study types too.

In theory this is possible, but how would this even work? Let's assume a study type has Emikat and another external service as calculation methods. Which one will then perform the calculations? Both? Which results will we then display? etc etc...
I say we stick to one calculation method per study type.

Step 2: assure that only the data packages are shown that provide (resources for) all the calculation methods that the study type requires

This is more difficult, but we have done something similar on DRIVER already (choice of solutions in trial). @fgeyer16 , do you remember what was necessary fo this to work?...

It's not difficult when we use a simple select list instead of the current Entity Browser. The current implementation is confusing anyway (at least to me), so switching to a simple select list + adding the "show preview" widget created by @fgeyer16 should do the trick.

Matching the allowed calculation methods of the data packages with the one calculation method of the study type can then be achieved in the hook_form_alter() in our CSIS helpers module.

Step 2b: also take into account the spatial aspect. If the data package is for Italy and the study is in Austria, it should not be shown.

This is similar to step 2, but involves geospatial "is polygon A within polygon B" operation. I have no idea if this is supported in Drupal.

We could compare the selected Study area with the spatial extent field of the data package. This comparison could be done in the same hook_form_alter() and we could probably use the GeoPHP library (we is already installed) for this.

But for a start I think it enough to compare only the calculation methods. Comparing locations could be added later as a new feature, once the system is already up and running.

[p-a-s-c-a-l]

Can this be considered done?

[patrickkaleta]

Can this be considered done?

Basically yes. I implemenent this feature in this branch of the csis-helpers module. I just need to merge it into Dev. I wanted to wait, since I hoped for some more data packages in the system. With this feature enabled, some study types now might show just one available DP or none at all.... but it is what it is, so I'll enable this feature next week and close the issue.

[patrickkaleta]

Done. The csis-helpers module now shows only published DPs with a calculation method fitting the selected Study type of current Study.

ATM for the following Study types we have these DPs:

1. Basic Screening: General
   • RESCCUE - Barcelona Climatic Projections
2. Adv. Screening: Urban Infrastructure
   • European Wide Data package
3. Adv. Screening: Transport Infrastructure (available soon)
   • DC4 Spanish Transport Network