smc.peering.tw: a live map of the submarine cables that keep Taiwan connected

What it is, and the framing the project uses

The Taiwan Submarine Cable Map is an interactive map application that displays the status and historical incidents of Taiwan's submarine cables, built with React, TypeScript and Vite. The features list names the pieces. An interactive map using Leaflet maps to view cable routes and landing points. Real-time status covering active and historical incidents. An uptime timeline visualising cable uptime data over the past year. A topology view that shows active incident impact across explicit ISP and cable segment dependencies. Multi-language support in English and Traditional Chinese. An intro screen on first visit. Responsive design for desktop, tablet and mobile. And incident tracking with the start time, estimated repair time and resolution status. The repository description puts the purpose plainly, a dashboard that shows the current status of submarine cables that connected Taiwan to the world, and the homepage is smc.peering.tw.

The data is generated, not hand-maintained, and that is the architectural decision

The Data Sources section is short and points at a separate repository, the tw-submarine-cable repository, with the data automatically updated and converted to a static format using GitHub Actions. So the application itself ships no live collector. It ships a data directory of JSON files, and a script, convert_incidents.py, that produces the incident file. The Python requirements for that script are minimal, requests and pytz, so the conversion is a fetch and a reshape rather than a heavy pipeline. The consequence for a user is that the map is as fresh as the last scheduled run of the workflow, and the consequence for a contributor is that editing the data by hand in this repository is the wrong move, because the next workflow run overwrites it. The repository has a .gitmodules file, which is a hint about how the data is pulled in.

The data formats, and what the topology file actually means

The Data Format section documents four files, and the topology one carries the rules that matter. The landing points file is an array of objects with an id, a name and coordinates. The incidents file has a date, a status which is disconnected, partial_disconnected or notice, a cableid, a segment, a title, a description, a repairing_at and a resolved_at, all in a plus eight hours offset. The cables directory holds one file per cable with an id, a name, a colour, a building flag, an available_path of country and segment pairs, an equipments list with a type of BMH, AC, BU or Other, and a segments list with per-segment coordinates. The topology file has nodes and edges, where a node is either an ISP with level 0 or a segment with level 1 and a dependency array of segment IDs. The semantics are explicit: topology dependencies are ordered segment ID arrays representing one logical route, any listed segment with disconnected status makes the node disconnected, otherwise any partial_disconnected segment makes it partially disconnected, and the level field places nodes in separate topology ranks with lower levels rendering first.

{
  "nodes": [
    {
      "id": "isp-id",
      "label": "ISP Name",
      "type": "isp",
      "level": 0
    },
    {
      "id": "segment-id",
      "label": "Segment Name",
      "type": "segment",
      "level": 1,
      "dependency": [
        "segmentID",
        "anotherSegmentID"
      ]
    }
  ],
  "edges": [
    {
      "source": "isp-id",
      "target": "segment-id"
    }
  ]
}

Running it locally, with three data files you fill in first

The Getting Started section is a five step list and step three is the one that trips people up. You need Node.js 18 or higher and npm or yarn. You clone the repository and change into the directory, run npm install, and then put the necessary data in place: the landing-points.json file can be an empty array, the incidents.json file is produced by running convert_incidents.py, and the cables directory can be left empty. Then npm run dev starts the development server and you open localhost:5173. The build for production is npm run build, which produces files in the dist directory, and the scripts list adds npm run preview to serve the production build and npm run lint to run ESLint. The other scripts are test:statistics, which runs a node test file for the annual incident statistics, and the dev script binds to 0.0.0.0 rather than localhost, which is convenient if you are developing from another machine on the network.

git clone https://github.com/seadog007/smc.peering.tw.git
cd smc.peering.tw
npm install
npm run dev

The stack, and the reason the map is MapLibre rather than a tile layer

The dependency list in the package.json is worth reading, because it shows the choices behind the interface. React 19 with react-dom, TypeScript throughout, and Tailwind CSS 4 with a Vite plugin and a separate tailwindcss package. For the map, the interesting pair is maplibre-gl and @vis.gl/react-maplibre, which is the MapLibre GL JS renderer, and the features list calls it Leaflet maps, so the project has moved from Leaflet to MapLibre at some point and the README text has not caught up. MapLibre renders vector tiles, which is what makes a submarine cable map with thousands of coordinate points viable. The interface kit is Radix UI with shadcn-style components, components.json at the repository root, and lucide-react for icons. State is zustand, data fetching is @tanstack/react-query, motion handles the animation, and i18next with react-i18next and a browser language detector handle the English and Traditional Chinese switch. The driver.js dependency is the guided tour that the version history shows being added in v3.9.0.

The version history is a changelog of the data, not just the code

The Version History section is the most revealing part of the README, because most of the entries are about the map's content and behaviour rather than the framework. The recent entries include desktop cable search with hover preview and cable selection plus annual incident statistics with repair time trends and rolling averages in v3.13.0, cable metadata, incident glossary tooltips, connectivity capacity details and a public cable data repository link in v3.12.0, and a full-page topology view with improved edge status coloring in v3.11.2. Earlier entries show the same pattern, with a topology view and a guided tour in the v3.9.0 to v3.11.2 range, then a series of data fixes such as the SJC2 segment ID and the SJC2 Hong Kong path. The colour semantics were also worked out in this period, with v3.5.0 showing partial-disconnected segments as yellow and prioritising red on overlaps, and v3.5.2 excluding retired segments from path propagation so that same-path segments colour correctly.

Sponsorship, language and the state of the project

The project is sponsored by TWDS and its sub-project STUIX, and the README explains why in terms of the peering ecosystem, that TWDS aims to promote peering in Taiwan, avoiding the situation where traffic needs to be routed out of the country and then back in, and that they introduce foreign network cache to help establish that ecosystem. That is a useful piece of context for why a cable map is worth building carefully. The licence is MIT, the primary language is TypeScript, the last push to the repository was on 2026-10-11, and the repository is not archived. The version in the package manifest is 3.13.0, matching the most recent entry in the version history, and there are no GitHub releases, so the changelog in the README is the release record. The test setup is a node test runner file for the annual statistics, the linting is ESLint with a flat config in TypeScript, and there is a components.json, a Prettier config, an eslint config file and a tests/ directory at the root.

Editorial conclusion

smc.peering.tw suits a network engineer, a journalist or a policy researcher who needs a clear picture of Taiwan's submarine cable routes and their outage history, and who is comfortable running a Vite front end with a generated data directory. It is the wrong choice if you need a live operational feed, since the application is a static site whose data is refreshed by a scheduled workflow rather than a running collector, and a poor fit for reuse as a general submarine cable monitoring tool, since the schema is built around one country's topology. Before adopting it, read the data format section, because the topology file's semantics are specific: a node is disconnected if any listed segment is disconnected and partially disconnected if any is partially disconnected, and segment IDs must exist in the cables directory.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. seadog007/smc.peering.tw on GitHub