Possibility to work with custom ground motion maps

[schmidni]

Hi there

I am currently working with OQ to integrate our own shakemaps and ground motion maps at the SED for Switzerland into the workflow "Scenarios from ShakeMaps" which you mentioned in the advanced user manual and the paper from Silva and Horspool.

To achieve this, I need to extend the respective code of openquake. I am open to all and any input or opinions and prefer to do things differently than I propose here, if as a result it adds value to Openquake and can be added to the official repo.

I am currently working on 3 different things:

1. Ability to define a custom URL for a shakemap.xml file and a uncertainty.xml/zip, instead of only being able to define USGS shakemap ids. I already made a pull request for that one, I am also happy however to make changes to the proposed solution. It could also be a good idea to try streamline the input of ground motion data from different sources and in different formats (see next point).

2. Ability to work with ground motion maps from shapefiles. I have not yet fully implemented this. My plan right now is to add, like with the shakemaps, a possibility to input the shapefile and then parse them.
   I would parse all intensity values into the same form as with the shakemaps, and use geopandas and pygeos to efficiently do the geographic associations with the sites (almost all dependencies of those packages are already in the project). From there on the existing workflow can take over.

3. Right now we only have vulnerability models based on MMI. Since for spatial correlation and cross correlation PGA and SA values are needed, I slightly changed the code so it works with MMI if spatial- and cross correlation are disabled.

I am happy to discuss this with you, take your input and recommendations.

Kind regards
Nicolas

[micheles]

This is very interesting. We should definitively talk, perhaps next week, when I should hopefully have more time.

[schmidni]

I started on the code. The goal is to be able to input different formats from different sources and easily extend the code to be able to use additional inputs.

I will open a new pull request with a first draft soon.

@micheles The question remains, on how best to specify the input source and format in the job.ini file.

• Local or on the web doesn't really matter since "urlopen" handles them the same way, depending on the address starting with https:// or file://

• I suppose the oq parameters "shakemap_id" and "shakemap" should both still work for backwards compatibility.

• I am open on how the new parameter should be called. Since "shakemap" already defines a specific format, I'm trying not to use that name.

• It now should be possible to define multiple files (eg. grid.xml and uncertainty.xml), or an alltogether different input, eg. ground_motion.shp, instead of adding two new parameters, I would suggest to add just one parameter, with the form:
  a) ground_motion_input = {"shakemap_grid": "file://grid.xml", "shakemap_uncertainty":"file://uncertainty.zip"}
  or
  ground_motion_input = {"shapefile": "file://grid.shp"}
  b) ground_motion_input = ["file://grid.xml", "file://uncertainty.zip"]

• The decision, how the input is parsed, is made in the code. Option a) would simplify this decision logic, option b) makes the input easier, although less clear.

[micheles]

See #6636

[schmidni]

I like the implementation with the CallableDict. Since you chose to implement somthing like my suggestion a) above, it is possible to use such a simple solution.

In the next steps, we still have to discuss:

• how to handle different input formats (like shapes instead of grids): get_sitecol_shakemap().
• How to handle different "preprocessing" and "sampling" strategies, since the current ones don't work for all cases: to_gmfs()

[micheles]

Is the work finished now?

[schmidni]

I am working on the integration to use shapefiles. But I don't think I have any more questions for the moment and the new code will be in line with the refactoring/optimizations up to now.