Renaming scenarios in GitHub [Pages] about earthquake-scenarios HOT 3 CLOSED

Hey @tieganh,

Regarding renaming, I think it is a great idea, even though it does require careful planning and potentially non-trivial amount of work, and would likely involve @drotheram and @wkhchow too. To What types and scope/extent do you have in mind?

Name type(s) to rename

First, in my limited understanding, there are two types of names:

1. Display name, e.g. "M4.9 Georgia Strait (BC)"
2. Code name (I am probably calling it wrong, please correct me) seen in file names, path names, in initialization files, in code, etc., e.g. ACM4p9_Capilano5

Changing the display names alone is relatively simple, though there will be difficult for the users to match the display name to the corresponding code name.
Changing the code names too would be quite a bit more involved, but hopefully creates consistency and avoids confusion in the long run.

Scope/extent of the rename

From my limited understanding, here are the steps that are involved roughly from beginning to end (rough chronological order):

• OpenDRR/earthquake-scenarios:
  • Initialization files: file name and content
  • "FINISHED" CSV file names
  • Metadata
• OpenDRR/opendrr-api
  • pygeoapi config files, which would appear in pygeoapi collections at https://geo-api.riskprofiler.ca/collections, e.g. https://geo-api.riskprofiler.ca/collections/opendrr_dsra_acm4p9_capilano5_indicators_b
• Elasticsearch indices used in API calls and in Kibana
• Path to vector map tiles, e.g. https://riskprofiler.ca/dsra_acm4p9_capilano5_shakemap_hexgrid_5km/EPSG_900913/9/78/173.pbf
• www.RiskProfiler.ca (WordPress scenario names, etc.)
• GitHub Pages

Some of the above would propagate automatically; some would require manual changes.

Other concerns

Since the renaming will involve quite some work, we should get it right the very first time, and to fix any related issues on the way.

Consistency in naming and with description

I'm probably, as the Chinese saying "雞蛋裏挑骨頭" goes, "picking bones out of an egg" (i.e. nitpicking), but here are some examples of inconsistencies that I came across:

• "M5.5 near Ottawa (ON)" vs "M5.0 event near Montréal (QC)": Is there a difference in these two scenarios such that one uses the word "event" but the other doesn't?

• https://geo-api.riskprofiler.ca/collections/opendrr_dsra_acm4p9_capilano5_indicators_b shows "Capilano 4.9 Scenario (Point)" in the title but "Scenario for a magnitude 5.3 shallow crustal earthquake..." in the description.

• FINISHED/SIM9p0_CascadiaInterfaceBestFault.md in the public OpenDRR/earthquake-scenarios repo still refer to files in the private OpenDRR/openquake-inputs repo, and apparently with "incorrect" paths. (Probably correct on a local system where all the repos are checked out, but not on the web?)

Documentation

There should also be a mapping table maintained somewhere that document these changes, especially the old names have been "out there" for some time now, and to have a "canonical source" for all of us to refer to. Here is an example:

OpenDRR/earthquake-scenarios

With the upcoming influx of over 50 new earthquake scenarios, some in our tech team wonder if the flat structure of the FINISHED and initialization directories is the best way forward. If we are doing mass renaming anyway, it would be a great opportunity to do a directory restructure too, e.g. by putting the multiple files of each scenario in their own directory, if we indeed come to a consensus to do so.

That's my 2 cents. 😁

So yes, let's continue our discussion here on GitHub and on Zoom to see how and when we want to proceed, e.g. to try to have the upcoming v1.4.4 data file updates, or for a later date, etc. Fun! 😄

from earthquake-scenarios.

As @anthonyfok said, this is bigger issue than it seems. Specifically, for GitHub pages, the "code name" is used to generate the "display name", as it was set up to add additional scenarios with limited manual updating. All of the links, tiles, and associated files use the "code name" for ID, so we'd have to change the "display name" down the line.

The easiest way to do this is probably to add a "display_name" variable to the initialization files, and pull that in. However, we then have the issue of someone looking at a scenario named "Georgia Strait 4.9" and downloading a file called "capilano5", and probably assuming the link is broken (side note - should Georgia Strait be Salish Sea?). This is probably a good method if the code name and display name are similar, ex. "Ottawa" to "near Ottawa", and we just want additional detail, but seems problematic otherwise, ex. "BurwashLanding" to "Denali Fault".

The best way going forward may be to add a display name variable, but also to rename the files in the case of big changes, and reprocess them. @tieganh Do we have a list of proper names for the scenarios in Jeremy's repo?

from earthquake-scenarios.

Can only comment for the db side of things. The indicators_b, _s, _csd for the earthquake scenarios are generated off the code names. There is also reference to the code name in 'sH_RupName' indicator. In the long run it would be best to rename the code names at source to run the scenarios.

Quick fix in the meantime if needed I can go into the DB and manually update and adjust if needed, and generate the geopackages.

from earthquake-scenarios.