olemd/tilfluktsrom

Fork 0

Støtte for internasjonale tilfluktsromdata #9

New issue

Open

opened 2026-03-08 23:11:48 +01:00 by olemd · 3 comments

olemd commented

2026-03-08 23:11:48 +01:00

Owner

Background

Tilfluktsrom currently only supports Norwegian shelter data from Geonorge (GeoJSON, EPSG:25833). To be useful internationally, we should identify and integrate shelter data from other countries.

Goals

Identify international data sources for public/civil defense shelters (tilfluktsrom, skyddsrum, bunkers, etc.)
Support multiple data formats without breaking existing functionality
Auto-download relevant data based on the user's current location

Known data sources to investigate

Country	Source	Format	Notes
🇳🇴 Norway	Geonorge	GeoJSON (EPSG:25833)	Current source, ~556 shelters
🇸🇪 Sweden	MSB (Myndigheten för samhällsskydd och beredskap)	Unknown	~65,000 skyddsrum, may have open data
🇫🇮 Finland	Pelastustoimi	Unknown	Civil defense shelters
🇨🇭 Switzerland	FOCP (Federal Office for Civil Protection)	Unknown	Extensive shelter network
🇸🇬 Singapore	SCDF	Unknown	HDB shelters
🇺🇸 USA	FEMA	Unknown	Varies by type (nuclear, tornado, etc.)

Technical considerations

Robust parsing

Each country's data will have a different format and coordinate system
Parsing errors in one data source must never break otherwise valid data from other sources
Each parser should be isolated — a malformed Finnish dataset must not prevent Norwegian shelters from loading
Consider a ShelterDataSource interface with per-country implementations
Validate and log errors per-record rather than failing the entire import

Data model

Current Shelter entity has Norwegian-specific fields (romnr, plasser, adresse)
Need to generalize or use a union model that accommodates different countries' metadata
Core fields across all sources: coordinates (WGS84), capacity, address/label, source country

Auto-download by location

Detect which country/region the user is in (reverse geocoding or bounding box check)
Download only the relevant dataset(s) — avoid bundling all countries in the APK

Could use a registry of available datasets with bounding boxes:

{ "country": "NO", "bbox": [4.5, 57.9, 31.1, 71.2], "url": "...", "format": "geojson" }

Fall back to bundled Norwegian data when offline (current behavior)

Offline-first

All downloaded datasets must be cached locally in Room
The app must remain fully functional without internet after initial download
Consider storage impact — some countries may have very large datasets

Out of scope (for now)

User-contributed shelter locations
Real-time shelter status (open/closed)
Routing/navigation to shelters

Current data pipeline: GeoJsonParser → CoordinateConverter (UTM33N→WGS84) → ShelterDatabase

## Background Tilfluktsrom currently only supports Norwegian shelter data from Geonorge (GeoJSON, EPSG:25833). To be useful internationally, we should identify and integrate shelter data from other countries. ## Goals 1. **Identify international data sources** for public/civil defense shelters (tilfluktsrom, skyddsrum, bunkers, etc.) 2. **Support multiple data formats** without breaking existing functionality 3. **Auto-download relevant data** based on the user's current location ## Known data sources to investigate | Country | Source | Format | Notes | |---------|--------|--------|-------| | 🇳🇴 Norway | Geonorge | GeoJSON (EPSG:25833) | Current source, ~556 shelters | | 🇸🇪 Sweden | MSB (Myndigheten för samhällsskydd och beredskap) | Unknown | ~65,000 skyddsrum, may have open data | | 🇫🇮 Finland | Pelastustoimi | Unknown | Civil defense shelters | | 🇨🇭 Switzerland | FOCP (Federal Office for Civil Protection) | Unknown | Extensive shelter network | | 🇸🇬 Singapore | SCDF | Unknown | HDB shelters | | 🇺🇸 USA | FEMA | Unknown | Varies by type (nuclear, tornado, etc.) | ## Technical considerations ### Robust parsing - Each country's data will have a different format and coordinate system - **Parsing errors in one data source must never break otherwise valid data** from other sources - Each parser should be isolated — a malformed Finnish dataset must not prevent Norwegian shelters from loading - Consider a `ShelterDataSource` interface with per-country implementations - Validate and log errors per-record rather than failing the entire import ### Data model - Current `Shelter` entity has Norwegian-specific fields (`romnr`, `plasser`, `adresse`) - Need to generalize or use a union model that accommodates different countries' metadata - Core fields across all sources: coordinates (WGS84), capacity, address/label, source country ### Auto-download by location - Detect which country/region the user is in (reverse geocoding or bounding box check) - Download only the relevant dataset(s) — avoid bundling all countries in the APK - Could use a registry of available datasets with bounding boxes: ``` { "country": "NO", "bbox": [4.5, 57.9, 31.1, 71.2], "url": "...", "format": "geojson" } ``` - Fall back to bundled Norwegian data when offline (current behavior) ### Offline-first - All downloaded datasets must be cached locally in Room - The app must remain fully functional without internet after initial download - Consider storage impact — some countries may have very large datasets ## Out of scope (for now) - User-contributed shelter locations - Real-time shelter status (open/closed) - Routing/navigation to shelters ## Related - Current data pipeline: `GeoJsonParser` → `CoordinateConverter` (UTM33N→WGS84) → `ShelterDatabase`

olemd commented

2026-03-08 23:12:22 +01:00

Author

Owner

Additional requirement: Graceful handling of unavailable sources

Data sources may disappear, go offline, change URLs, or stop responding at any time — especially during the kind of emergencies where this app is most needed.

Scenarios to handle

Source returns HTTP error (404, 500, etc.) — keep using cached data, log warning
Source times out — don't block the UI or other sources; use cached data
Source URL changes or is permanently removed — app continues working with last-known data
Source returns malformed/truncated data — reject the bad download, keep previous valid data
Source returns valid data with 0 records — treat as suspicious, keep previous data with a warning rather than wiping the database

Design principles

Never delete valid cached data because a refresh failed — a network error should not degrade the user's experience
Download to a staging area, validate, then swap — atomic updates prevent partial/corrupt data from reaching the database
Each source fails independently — a dead Swedish endpoint must not prevent Norwegian data from updating
Exponential backoff for retries — avoid hammering a struggling server
Surface staleness to the user — show data age in the UI so users know if their data is outdated (we already show a timestamp on the widget)

## Additional requirement: Graceful handling of unavailable sources Data sources may disappear, go offline, change URLs, or stop responding at any time — especially during the kind of emergencies where this app is most needed. ### Scenarios to handle - **Source returns HTTP error** (404, 500, etc.) — keep using cached data, log warning - **Source times out** — don't block the UI or other sources; use cached data - **Source URL changes or is permanently removed** — app continues working with last-known data - **Source returns malformed/truncated data** — reject the bad download, keep previous valid data - **Source returns valid data with 0 records** — treat as suspicious, keep previous data with a warning rather than wiping the database ### Design principles - **Never delete valid cached data because a refresh failed** — a network error should not degrade the user's experience - **Download to a staging area, validate, then swap** — atomic updates prevent partial/corrupt data from reaching the database - **Each source fails independently** — a dead Swedish endpoint must not prevent Norwegian data from updating - **Exponential backoff for retries** — avoid hammering a struggling server - **Surface staleness to the user** — show data age in the UI so users know if their data is outdated (we already show a timestamp on the widget)

olemd commented

2026-03-08 23:14:38 +01:00

Author

Owner

Include status/type metadata from official sources

If official data sources include fields like shelter type, status, or operational readiness, we should preserve and display them rather than discarding metadata during parsing.

Fields to look for in each data source

Status: open/closed, operational/decommissioned, under maintenance
Type/kind: nuclear, conventional, multi-purpose, residential (e.g. Swiss shelters distinguish between public and private)
Capacity details: standing vs seated, peacetime vs wartime capacity
Accessibility: wheelchair accessible, floor level
Construction year or last inspection date

Implementation notes

Store these as optional fields — not all sources will provide the same metadata
Use the source's original terminology in a structured way (e.g. an enum per source, mapped to a common display model where possible)
Show relevant metadata in the shelter detail view and bottom sheet
Consider filtering/sorting by status — a decommissioned shelter should be visually distinct from an active one, and probably excluded from "nearest shelter" results by default

## Include status/type metadata from official sources If official data sources include fields like shelter type, status, or operational readiness, we should preserve and display them rather than discarding metadata during parsing. ### Fields to look for in each data source - **Status**: open/closed, operational/decommissioned, under maintenance - **Type/kind**: nuclear, conventional, multi-purpose, residential (e.g. Swiss shelters distinguish between public and private) - **Capacity details**: standing vs seated, peacetime vs wartime capacity - **Accessibility**: wheelchair accessible, floor level - **Construction year** or **last inspection date** ### Implementation notes - Store these as optional fields — not all sources will provide the same metadata - Use the source's original terminology in a structured way (e.g. an enum per source, mapped to a common display model where possible) - Show relevant metadata in the shelter detail view and bottom sheet - Consider filtering/sorting by status — a decommissioned shelter should be visually distinct from an active one, and probably excluded from "nearest shelter" results by default

olemd commented

2026-03-09 09:34:41 +01:00

Author

Owner

Civil defense info: international considerations

v1.4.0 added a civil defense info dialog with Norwegian DSB guidelines (alarm signals, shelter instructions, DAB radio). When adding international shelter data, each country will also need localized emergency procedures:

Signal patterns differ by country — Norway has "viktig melding" (3 series) and "flyalarm" (short blasts); Sweden, Finland, Switzerland etc. have their own signal systems
Radio guidance varies — Norway uses DAB (FM shut down 2017), other countries may still use FM or have different emergency broadcast systems
The CivilDefenseInfoDialog could be extended with a country selector or auto-detect based on location, loading country-specific instructions from string resources or bundled JSON
All content must remain offline-capable — same pattern as shelter data

Current implementation: ui/CivilDefenseInfoDialog.kt with static content from strings.xml (en/nb/nn).

## Civil defense info: international considerations v1.4.0 added a civil defense info dialog with Norwegian DSB guidelines (alarm signals, shelter instructions, DAB radio). When adding international shelter data, each country will also need localized emergency procedures: - **Signal patterns differ by country** — Norway has "viktig melding" (3 series) and "flyalarm" (short blasts); Sweden, Finland, Switzerland etc. have their own signal systems - **Radio guidance varies** — Norway uses DAB (FM shut down 2017), other countries may still use FM or have different emergency broadcast systems - **The `CivilDefenseInfoDialog` could be extended** with a country selector or auto-detect based on location, loading country-specific instructions from string resources or bundled JSON - **All content must remain offline-capable** — same pattern as shelter data Current implementation: `ui/CivilDefenseInfoDialog.kt` with static content from `strings.xml` (en/nb/nn).