shakyground2 merge requestshttps://git.gfz-potsdam.de/shakemap/shakyground2/-/merge_requests2021-02-25T15:36:06+01:00https://git.gfz-potsdam.de/shakemap/shakyground2/-/merge_requests/6Implements Feature/site model to handle the site configuration2021-02-25T15:36:06+01:00Graeme WeatherillImplements Feature/site model to handle the site configurationThis MR implements the `shakyground2.site_model.SiteModel` class to manage the construction and manipulation of the site properties needed for the shakemap, as specified in https://git.gfz-potsdam.de/shakemap/shakyground2/-/issues/12. Al...This MR implements the `shakyground2.site_model.SiteModel` class to manage the construction and manipulation of the site properties needed for the shakemap, as specified in https://git.gfz-potsdam.de/shakemap/shakyground2/-/issues/12. Allows construction of the site model from a bounding box (with constant site properties) or `pandas` dataframe, and handles default properties for cases where they are not specified for the user.
Note:
1. The site class itself mirrors some properties of the OpenQuake `SiteCollection` object, and indeed the site model will be exported to the OpenQuake `SiteCollection` object for running the shakemaps. This approach was adopted in favour of direct inheritance and extension of the `SiteCollection` object, which requires a stricter control on the inputs and manipulates the site model in a manner more specific to the OpenQuake calculation cases than the shakemap case considered here. The `SiteModel` here acts as an interface to handle the likelier range of inputs encountered for shakemap applications and to provide more control on how these are handled in order to build the site model. Both ways (inheritance and composition) were compared and the composition approach favoured.
2. This does not address the case in which the input Vs30 data is extracted from the USGS Global Vs30 database. That will be a critical workflow feature, and methods for handling that will be added to this class subsequently, but this requires further consideration. A new issue will be opened on this in due course.https://git.gfz-potsdam.de/shakemap/shakyground2/-/merge_requests/22(Potentially) Fixes bug of shakemaps not working across antimeridian2021-06-02T14:22:36+02:00Graeme Weatherill(Potentially) Fixes bug of shakemaps not working across antimeridianAddresses https://git.gfz-potsdam.de/shakemap/shakyground2/-/issues/18
when the bounding box of the shakemap region crossed the antimeridian (not the "international date line" - I have been corrected on that terminology!) the shakemap c...Addresses https://git.gfz-potsdam.de/shakemap/shakyground2/-/issues/18
when the bounding box of the shakemap region crossed the antimeridian (not the "international date line" - I have been corrected on that terminology!) the shakemap could not be built. There were several steps in the calculation that prevented it, but it ultimately originates from the `ulon` of the bounding box being lower than the `llon` and thus no valid site model was built. This MR makes the necessary fixes in the shakemap code to ensure that the ground motion values are calculated at the sites correctly when the earthquake is near the antimeridian.
In the second modification, the generation of the raster and contours has been modified. For the contours these are re-centred such that longitudes in the western hemisphere (-180˚E to 0˚E) are shifted to an antimeridian centred system (i.e. 180˚E to 360˚E). Thus the contour can now contain longitudes greater than 180˚E. For the raster we use `rasterio`'s `reproject` functionality to transform the raster passing the `CENTER LONG = 180` keyword to the `GDAL` backend. This does not raise an error and seems to export complete rasters.
Here is an example of the shakemap in QGIS:
![Screen_Shot_2021-05-27_at_16.58.53](/uploads/c5a1c92f27aa186eb8373500fc065d7e/Screen_Shot_2021-05-27_at_16.58.53.png)
@nils @eggi Honestly, I have no idea whether this has worked or not. The results seem OK in QGIS when I set the basemap projection to EPSG:4326, but if I switch to another project (e.g. EPSG:3857) then it only shows me the portion of the raster in the eastern hemisphere. This could be just a QGIS issue, though, and it might be fine on the Earthquake Explorer server. I will keep issue https://git.gfz-potsdam.de/shakemap/shakyground2/-/issues/18 open after merging this MR until there is confirmation that this either i) works directly or ii) can be integrated into the pipeline.
An antimeridian crossing workflow has also been added to the workflow test cases.