`get_task_id_params` likely needs to know about a round id about hubutils HOT 6 CLOSED

Noted! Working on a fix to #13 & #14 now.

FYI what I'm looking at is having available task id parameters as attributes of a hub-connection S3 class object as they are effectively metadata on the metadata. the hub-connection object will instead hold the possible values of each parameter as specified in the hubmeta file.

from hubutils.

Couple of questions for you @elray1 :

1. How likely is it that elements containing round specific metadata will not contain "round" in their names?
2. There is an option to simplify task_id names per round when they are the same for each round e.g for the example referenced in this issue, task id names are being extracted as such:

task_id_names
#> $`round-1`
#> [1] "origin_date" "scenario_id" "location"    "target"      "horizon"    
#> 
#> $`round-2`
#> [1] "origin_date" "scenario_id" "location"    "target"      "horizon"

However, given they are all the same, we could opt to simplify this metadata (and hence the downstream validation steps) to a single vector of the unique values:

task_id_names
#> [1] "origin_date" "scenario_id" "location"    "target"      "horizon"

Let me know what you think about that option.

from hubutils.

It is expected that functions should handle a user wanting to ask for data over multiple round ids (across which task ids may well vary) in one go, correct?

In this case it would be really useful to have an example hubmeta file for that. Would modifying the one provide here to have one less or differing available task id in round-2 compared to round-1 be reasonable? Any suggestion on what a realistic tweak might be?

from hubutils.

All good questions. Here are some quick thoughts:

• I like the idea of simplifying the structure by removing the round_id level when that's possible
• An easy way to get an example where round-1 and round-2 have different task id variables would be to remove the "target" entry for round 2 (note that it has only one possible value in round 2). A slightly more involved (and more interesting) way would be to add something like an age_group variable with categories like ["0-5", "6-18", "19-24", "25-64", "65+"]

from hubutils.

Quick follow up question. The fact that for the scenario hub metadata, we have round varying task ids implies that variation between rounds might be expected. Is this something we expect in the forecasting hub too at times? And does that just mean, if a forecasting hubs acquires further task ids, a metadata format with round varying task ids would be adopted going forward?

from hubutils.

I think that:

• it is possible that a hub will change its tasks over time, but this will be fairly rare. But note that the US forecast hub has added targets a couple of times. And we've thought about removing targets, though in the end we decided not to do that.
• if we did want to handle it, I think this could be handled within the existing metadata structure. For example, suppose the round_id_variable is origin_date. The model_tasks array could contain two entries with different sets of origin_dates specified, corresponding to the origin_dates before/after the change in tasks.

from hubutils.