Update IMT.csv

[matamadio]

Add imt code for cyclone wind speed 10-min sustained. It was already there as km/h but STORM uses m/s...

This makes me reconsider the discussion in #5, and splitting IMT into two separate codelists:

• metric (optional)
• unit (mandatory)

So even if the specific metric (larger range of variability) is not in the codelist, one can still indicate the unit if part of the most common ones (smaller range of variability).

Related issues

5

Merge checklist

If you added, removed or renamed a field:

• [ ] Update the collapse option of the jsonschema directives for dataset, resource, hazard, exposure, vulnerability and loss on reference/schema.md
• [ ] Update the diagrams in reference/schema/md
• [ ] Update the JSON files in examples

Always:

• [ ] Run ./manage.py pre-commit
• [ ] Update the changelog (style guide)

Having trouble?

See how to resolve check failures.

[matamadio]

In addition: it's not always useful to specify the hazard type in the metric. In some cases it just create unnecessary duplication when the same metric:unit could be used.

E.g. Why we need to differentiate FL from LS when speaking of flow depth, velocity? How tsunami inundation depth is different from FL or LS "flow depth"? Why we need to indicate "etc" (extra-tropical cyclones) for strong wind unit?

[odscjen]

The other tests that are failing are because you've added some codes to closed codelists (metric_dimensions, and exposure_category) but you've not included the new codes in every instance of enum that uses that codelist. (this was presumably in a different PR)

[matamadio]

The other tests that are failing are because you've added some codes to closed codelists (metric_dimensions, and exposure_category) but you've not included the new codes in every instance of enum that uses that codelist. (this was presumably in a different PR)

I've only edited this open codelist. Still, I don't know how to do what you are suggesting: which file should be edited in addition to csvs?

[odscjen]

Hi Mat you've got 3 errors showing up I'll deal with them in turn.

1. One or more codelist CSV files are invalid

The problem is that lines 11 and 12 in licence.csv both end with a space, they should just end with the comma. It looks like that error was introduced in this commit https://github.com/GFDRR/rdl-standard/commit/6e35b0b60afa9e8b918be1dc5e1ed27bf4ad577e

2. Files are not indented as expected

This one can be fixed by running ocdskit indent -r . as explained in the developer docs You have to run this locally on your own computer, it can't be done within github.

3. One or more JSON Schema files are invalid

I've had a bit more of an investigate and the problem is again in an older commit to this base branch. It looks like Stu made a commit https://github.com/GFDRR/rdl-standard/commit/ba9472e7a9cd3c9baf80ff03cdf3d832b49b3f8b earlier that added 2 new codes to the exposure_category.csv. However he only updated the csv file itself. For closed codelists (like this one) the codes also need to match those in enum fields in the schema itself.

e.g.

"category": {
          "title": "Asset category",
          "description": "The category of the lost assets, from the closed [exposure_category codelist](https://docs.riskdatalibrary.org/en/{{version}}/reference/codelists/#exposure-category).",
          "type": "string",
          "codelist": "exposure_category.csv",
          "openCodelist": false,
          "enum": [
            "agriculture",
            "buildings",
            "infrastructure",
            "population",
            "natural_environment"
          ]
        },

in this example (which is from Losses) only the original 5 codes are listed out but there's now 7 codes in the referenced file so the test expects to see those same 7 codes in the enum field where codelist references "exposure_category.csv".

[odscjen]

I see the change of removing quotation marks on line 7, but other lines have quotation marks as well..?

Ah yes you only need quotation marks if there are special characters (normally commas). If there aren't any, as is the case in that line of metric_dimensions.csv, the tests complain.

[matamadio]

I think I solved some of the PR errors, but others remain:

• json indent (can't locate the issue, if exists)
• properties within properties (ignore?)

[odscjen]

properties within properties can be safely ignored, it's just a warning rather than an actual error.

indent errors are almost impossible to spot by eye and requires the dev env to fix it using the ocdskit module. It's one of the tests that can be safely turned off for the time being if that's what you'd like?