Improving (individual) metadata page

[bennyistanto]

The moment is perfect to discuss this, as following relevant topics also came up

• @matamadio working on the Update pages template #49
• Some problem on Loss page, especially with DesInventar metadata Test upload Loss (only) metadata from DesInventar - HDX #113 (comment)
• @stufraser1 are discussing about DELTA Resilience (DesInventar replacement), which have more complicated HEVL components information compare to DesInventar https://github.com/GFDRR/rdl-datapipeline/issues/19

Background

With the recent integration of DesInventar national loss inventories (16 datasets, 809 loss entries total), the catalog now includes loss datasets with significantly more entries per dataset than we had before, Albania has 111 loss records across 9 hazard types, Colombia has 136.

The current mapper was originally designed for datasets with a handful of loss entries (2-4), and it works well for those. The DesInventar integration gives us a good opportunity to improve how loss information is presented when there are many entries, making it easier for users to browse and understand the data.

Current Behavior

Today, make_loss() in mappers.py summarizes all loss entries into a single flat row per field. For the description field, this means all individual descriptions are joined into one comma-separated string. With 111 entries, this produces a very long text block in the Description cell that's hard to scan. See https://jkan.riskdatalibrary.org/datasets/rdls_lss-albundrr_desinventar/

I have tried to reduce and make the description shorter on each entries, but having short version for 111 entries seems doesn't solve the problem.

The other loss fields (hazard_type, impact_metric, etc.) handle this fine because they contain short codelist values. It's really only the free-text description that becomes unwieldy at scale.

Idea: Group loss records by hazard type with collapsible sections

Instead of showing all descriptions as a single block, we could group them by hazard type and present each group as a collapsible section. This way users get a quick overview (which hazard types, how many records each) and can expand any group to see the detail.

What it would look like

For Albania (111 loss records, 9 hazard types):

Description        | 111 loss records across 9 hazard types
Total Loss Records | 111
Loss Records Detail|
                   | ▶ Coastal Flood [2]
                   | ▶ Convective Storm [8]
                   | ▼ Flood [18]                    ← expanded
                   |   • Deaths (flash flood) — 44 events out of 949
                   |   • Persons injured — 20 events
                   |   • Homes destroyed — 139 events
                   |   • Economic losses (local currency) — 282 events
                   |   • ...
                   | ▶ Earthquake [14]
                   | ▶ Landslide [16]
                   | ▶ Strong Wind [14]
                   | ▶ Wildfire [14]

For small datasets with 2-3 loss entries, everything stays exactly as it is today.

Interactive mockup

I put together an HTML mockup using the actual Albania data so you can see and click around:

mockup_loss_groups_proposed_a.html

It uses Bootstrap 3.3.6 to match the catalog's styling. The collapsible sections use HTML5 <details>/<summary>, no JavaScript needed.

How it could work

This would involve four small changes:

1. python/mappers.py — Add grouping logic to make_loss():

# Group descriptions by hazard type
groups = {}
for l in loss.get("losses", []):
    ht = l.get("hazard_type", "unknown")
    desc = l.get("description", "")
    if desc:
        groups.setdefault(ht, []).append(desc)

loss_groups = [
    {"hazard_type": ht, "count": len(descs), "descriptions": descs}
    for ht, descs in sorted(groups.items())
]

Add loss_groups and loss_count to the return dict. For datasets with >5 entries, replace the concatenated description with a short summary like "111 loss records across 9 hazard types".

2. New template _includes/display/loss_groups.html:

<tr>
  <th>{{ include.field.label }}</th>
  <td>
    {% for group in include.value %}
      {% capture ht_code %}{{ group.hazard_type }}{% endcapture %}
      {% assign ht_label = site.data.rdl-hazard_type[ht_code] | default: ht_code %}
      <details class="loss-group">
        <summary class="loss-group-summary">
          {{ ht_label }}
          <span class="badge">{{ group.count }}</span>
        </summary>
        <ul class="loss-group-descriptions">
          {% for desc in group.descriptions %}
            <li>{{ desc }}</li>
          {% endfor %}
        </ul>
      </details>
    {% endfor %}
  </td>
</tr>

3. Schema files (_data/schemas/rdl-02.yml and rdl-03.yml) — Add two fields after description:

  - field_name: loss_count
    label: Total Loss Records
  - field_name: loss_groups
    label: Loss Records Detail
    display_template: display/loss_groups.html

4. css/main.css — A few lines for the collapsible styling:

.loss-group { margin-bottom: 4px; border: 1px solid #e0e0e0; border-radius: 3px; }
.loss-group-summary { padding: 6px 10px; cursor: pointer; font-weight: 600;
                      background-color: #f9f9f9; list-style: revert; }
.loss-group-summary:hover { background-color: #f0f0f0; }
.loss-group-summary .badge { margin-left: 6px; font-weight: normal; }
.loss-group-descriptions { margin: 0; padding: 6px 10px 6px 30px; font-size: 90%; }
.loss-group-descriptions li { margin-bottom: 3px; }

Why <details>/<summary>

• No JavaScript needed — native HTML5 element
• Accessible out of the box (keyboard, screen readers)
• Degrades gracefully — shows expanded in older browsers
• Multiple groups can be open at the same time for comparison
• ~15 lines of Liquid, lightweight

Backward compatibility

Datasets that don't have loss_groups in their frontmatter simply skip the new field — no visual change at all. The existing description field continues to work as before for small datasets.

Open to other ideas

This is just one approach, happy to discuss alternatives or adjustments. The DesInventar data is a great test case for thinking about how the catalog handles larger datasets in general, and don't forget, soon we will face DELTA which more complicated.

[bennyistanto]

Additional finding: hazard_type.html display template doesn't handle multi-value fields

While testing the collapsible loss groups locally, I noticed the Hazard Type row in the Loss Info table renders blank for datasets with multiple hazard types.

This is also happen to other datasets with Loss information (All Tomorrow Cities metadata affected #111 (comment)

What happens:

The current _includes/display/hazard_type.html passes the entire comma-separated string as a single lookup key:

{% capture code %}{{ include.value }}{% endcapture %}
{{ site.data.rdl-hazard_type[code] }}

When the mapper produces hazard_type: coastal_flood, convective_storm, drought, ..., the template tries to find one key matching the whole string in _data/rdl-hazard_type.yml — which doesn't exist, so the cell is empty.

What already works:

Other templates like loss_type.html, process_type.html, and impact_metric.html already handle this correctly by splitting and iterating:

{% assign split_string = include.value | split: ", " %}
{% if split_string[0] %}
    {% for c in split_string %}
    {% capture code %}{{ c }}{% endcapture %}
        {{ site.data.rdl-hazard_type[code] }}{% unless forloop.last or site.data.rdl-hazard_type[code] == nil %}, {% endunless %}
    {% endfor %}
{% else %}
    {% capture code %}{{ include.value }}{% endcapture %}
    {{ site.data.rdl-hazard_type[code] }}
{% endif %}

Scope:

This currently affects DesInventar loss datasets (which have multiple hazard types per loss component). Some other single-value-only templates (analysis_type.html, approach.html, base_data_type.html, impact_type.html, etc.) could have the same issue if future datasets produce multi-value fields — though for now they only receive single values.

---

After revision:

DesInventar

Tomorrow Cities

[matamadio]

Thanks Benny for the proposal. It sounds good to have the accordion grouping.
Also agree on the required fix for multiple hazard types.
@lydiascarf to consider when updating templates.

[matamadio]

Will give a try on the restyle ie accordion thing.
Meanwhile, there a several datasets that show empty for some components that are part of the metadata, e.g.

https://jkan.riskdatalibrary.org/datasets/rdls_lss-gmb_floodcoastres/ > missing to show exposure box
https://jkan.riskdatalibrary.org/datasets/rdls_lss-hdx_ocha_regional_office_ken_kenya_drought_related_key_figures_drought/ > missing exp and vln
https://jkan.riskdatalibrary.org/datasets/rdls_exp-hdx_worldpop_ukr_worldpop_population_counts_for_ukraine/ > missing exp box

Plan:

• @lydiascarf to fix the multiple fields visualisation (all components affected)
• @matamadio to restyle the multi-components as from Benny suggestion

[matamadio]

@lydiascarf some issues with multiple components remain.

E.g. Papua New Guinea Earthquake Health Facility Status: exp and vln are present, but empty.

This is justified for vln cause all attributes are missing,

vulnerability:
  approach: ''
  base_data_type: ''
  category: ''
  dimension: ''
  function_type: ''
  hazard_analysis_type: ''
  hazard_primary: ''
  hazard_process_primary: ''
  hazard_process_secondary: ''
  hazard_secondary: ''
  intensity: ''
  metric: ''
  relationship: ''
  taxonomy: ''
  unit: ''

but exposure is there:

- category: infrastructure
  dimension: structure
  quantity_kind: length
  taxonomy: null

[bennyistanto]

The PR on Loss grouping has been updated #123 (comment)

No longer touch the schema.