search

swiss-seismological-service / REIA

GNU Affero General Public License v3.0
3 stars 0 forks source link

Upload Functionality for Scenario Metadata #19

Closed schmidni closed 7 months ago

schmidni commented 1 year ago

User Story

As a non-technical user of the scenario workflow I would like to be able to upload shakemaps and event metadata to the database.

Acceptance Criteria

Using the CLI it is possible to upload all the additional information needed to display the scenario calculations.

schmidni commented 10 months ago

Working with Cyrill to include his script(s) as smoothly as possible into the ria-engine CLI.

romanoe commented 8 months ago

Can there be multiple scenarios for the same origin_id?

schmidni commented 8 months ago

That is a very good question. Currently, no.... I would say, there will always be one entry for the metadata, one entry for the shakemap, and if possible, we could probably have multiple RIA's.

So shakemap <-> origin is always 1<->1. origin <-> ria can be 1<->many. do you see problems with that?

kaestli commented 8 months ago

(not sure this is relevant here, if not, ignore & apologize ) If you are using the same db scheme for scenarios as in the shakemap DB, then sm_origin <-> sm_computation is 1 <-> many, with the description being the description of the origin (parametrized earthquake location). sm_computation for the same origin may differ by code_version (metadata describing the software used) and sm_version (just a counter with no further context) So if there are multiple shakemaps for one origin, we currently cannot tell which loss_riskassessment was computed based on which shakemap. At the time being, we have no use-case for multiple meaningful shakemap versions - we would have a second version only if the first version fails, so one would look at the last sm_computation.shakemap_version and the last loss_riskassessment.creationinfo_version and think this is it. However, we had times when we calculated shakemap with two setups at the same time, differentiated by sm_computation.code_version, with both having their own meaning. if this comes back, we cannot easily do RIA for both. Similarly, one day you may wish to be able to have parallel loss_riskassessments for the same shakemap, differentiated by a code_version or a config_version/reference to a configuration.

schmidni commented 8 months ago

well... thanks @kaestli for the complete answer.

@romanoe my reasoning, which I did not expand on before, is that since we can have multiple RiskAssessment for one origin, but can not differentiate if they were calculated with different shakemaps, we will use the relationships as I described above.

romanoe commented 8 months ago

If I understand correctly, giving shakemap <-> origin_id is 1<->1, I'd use the origin_id to check if these scenarios already exist and perform the 'upsert' accordingly (overwrite functionality).

schmidni commented 8 months ago

yes, origin_id should be unique and there should only ever be one shakemap for the same origin_id