Skip to content
This repository was archived by the owner on Jul 13, 2026. It is now read-only.

MosslandOpenDevs/SmartSafetyMap

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Smart Safety Map — Concept Archive

📦 Concept Archive — planning only, not a running application. Archived 2026-07-13. This repository holds a service concept, a data strategy, and a visual direction — no code, data, demo, tests, or CI (docs are Apache-2.0 licensed). It is preserved as an honest record of the idea and of a review that reframed it. If the project is revived, start from ROADMAP.md; if not, it stays archived. See the reboot-or-archive gate in ROADMAP.md.

Smart Safety Map began as a map-based web service for viewing public safety information around a building by selecting topics. A 2026-07 review found that, as written, it was effectively a smaller copy of existing public services (e.g. MOIS's Living Safety Map) and that the harder problems — data provenance, freshness, coverage, and safety-of-interpretation — were treated as afterthoughts. This document folds that review in.

Project status

Stage Concept & design (no implementation)
Status Concept Archive (2026-07-13)
Deliverables This concept · DATA_SOURCES.yml · DESIGN.md · ROADMAP.md
Repository health No code / data / tests / CI / issues · Apache-2.0 for code & docs
Next step if revived Pass the Reboot Gate, then Phase 1 vertical slice — see ROADMAP.md

What this is and is not

  • Is: a concept archive and a data/design strategy for a building-centered safety viewer.
  • Is not: an outdated app in need of a framework upgrade. There is nothing to "update to the latest framework" — there is no application yet.

Because of that, the priority is not modernizing dependencies. It is settling product differentiation, data contracts, and legal usage terms first.

Recommended reframing: Building Safety Context Viewer

Rather than a generic "pick-a-safety-layer" map, narrow the product to:

Enter one address or building and see the authoritative safety data within ~500 m / 1 km, each item shown with its source, observation time, validity, and coverage — and shareable as a link and JSON reproducing the same state.

Differentiation comes from four things, not from the number of layers:

  1. Every object shows its source and timestamp (provenance-first).
  2. "No data" is strictly distinguished from "safe."
  3. Regional coverage gaps and stale data are never hidden.
  4. A public adapter architecture absorbs the differences between public APIs.

Data taxonomy

Do not flatten everything into one "safety" layer. Separate by type:

Type Examples Display principle
hazard Flood traces, inundation scenarios Distinguish past / model / forecast
resource Shelters, emergency bells, hospitals Purpose, operational status, inspection time
observation Air quality, rainfall Observation time, station, unit
alert Disaster texts, weather warnings Issued / valid / cleared times
report User reports Verification status and expiry are mandatory

Canonical data contract

Every rendered object should carry at least:

sourceId        sourceRecordId   geometry        originalCrs
observedAt      publishedAt      fetchedAt       validFrom      validUntil
coverage        verificationStatus   qualityStatus   license   attribution

Freshness must be an explicit state, not an assumption:

fresh   stale   unavailable   unknown   no-events

unknown must never be rendered as green / safe. The full source catalog, with the fields above and per-source caveats, lives in DATA_SOURCES.yml.

Corrected difficulty assessment

The original plan labeled most categories "Easy." That was misleading — it measured drawing a marker, not making a safe claim.

Category Easy part The actually hard part
Mobility-vulnerable Facility POIs Accessible routes, entrances, slopes, live elevator status — high difficulty; split POI from routing
Built-in reports CRUD Auth, spam, defamation, EXIF, faces/plates, moderation, deletion/appeals — highest operational load
Shelters & hospitals Location markers Fitness per disaster type, operating status, live capacity
Air quality Level chip It is the nearest station's value, not the building's — must show station distance, observation time, missing readings
Risk zones Must not be raw report counts: needs minimum sample, time decay, dedup, bias handling, explainability

Recommended MVP scope

One verifiable vertical slice first, then two more observation/resource layers:

  1. Civil-defense shelters — end-to-end: EPSG:5174 → WGS84 (source CRS claimed — verify; see DATA_SOURCES.yml), operational status + update time + source, with an offline fixture fallback.
  2. Emergency medical institutions — separate static location from live bed / severe-condition capacity; auto-warn on stale responses.
  3. Air quality — station distance, observation time, CAI, pollutant; calls throttled through a server-side cache.

Out of the initial scope: user reports, composite risk score, CCTV-based "safety," accessible route-finding, nationwide performance optimization, and any Mossland wallet / token / Web3 integration. Trust here comes from provenance, not from blockchain.

Recommended technical architecture

Layer Recommendation
Web Vite + React + TypeScript SPA (simpler than Next.js for a map app with little SSR need)
Map MapLibre GL JS
Early data GeoJSON for small pilots
Nationwide static data PMTiles v3 when needed
Ingestion Scheduled GitHub Actions + a per-source adapter
Coordinate transforms PROJ/GDAL with reference-coordinate fixtures for regression tests
Realtime APIs Serverless proxy + cache + timeout/backoff
Database None initially; add PostgreSQL/PostGIS when reports or complex spatial queries appear
Validation JSON Schema or Zod; geometry validity, coordinate range, dedup/missing/stale checks
Testing Vitest, Playwright, axe-core, external-API fixture contract tests
Long-term public API OGC API Features; consider JSON-FG for time / multi-CRS

Ship synthetic or redistribution-cleared fixtures so anyone can run the app without API keys.

Data sources

See DATA_SOURCES.yml. Note: the record counts, cadences, quotas, CRS codes, and update/deprecation dates there come from the 2026-07 review and are unverified (marked verified: false). Confirm each against the live source before building on it. Existence of an API does not validate a safety judgment.

Design

See DESIGN.md. Treat it as a visual concept memo, not an implementable design system — several of its "absolute" rules (no-line sectioning, glassmorphism, shared error color for Bad/Very Bad) fail WCAG 2.2 non-text contrast and need rework before use.

Roadmap & the reboot-or-archive gate

See ROADMAP.md. In short: within two weeks, confirm a maintainer (≥ 12 weeks), a real user, a pilot region, and two core data sources. If those are not settled, keep the repository archived and tag concept-v0.1 rather than leaving it looking active.

Licensing

Code and documentation in this repository are licensed under Apache-2.0. The data license is separate: each public-API dataset keeps its own terms (see the license field per source in DATA_SOURCES.yml) — public data must not be re-licensed under Apache-2.0.

Short description

An open-source viewer for authoritative safety context around a single building, shown with source, time, and coverage.

Service name

Smart Safety Map (working title) · reframing proposed: Building Safety Context Viewer


Korean version: README_KR.md

About

Smart Safety Map is a map-based web service that allows users to intuitively view public safety information around a building by selecting topics of interest.

Resources

License

Stars

0 stars

Watchers

0 watching

Forks

Releases

No releases published

Packages

 
 
 

Contributors