- Entry date
- 1 October 2025
- Category
- Tooling
- Access
- 🔓 Public
Dozens of scattered rail passenger-information projects across a region, one map — because a spreadsheet was never going to hold where they actually are.
- PostGIS
- geospatial extension chosen over a flat relational table
- 4
- layers shipped: backend, frontend, monitoring, CI/CD
- Docker + Nginx
- deployment stack
Honest evaluation
The infrastructure bet — PostGIS over a flat table for distributed rail assets — paid off in production; the tool stayed exactly as scoped, a tracker, not a controller.
What would prove or disprove it further
What would disprove it further: if the project had needed to bolt on ad-hoc spatial hacks over time to keep up with real usage, that would undercut the "PostGIS was the right call" claim. The falsifiable test is simply whether it keeps handling new spatial questions natively as the tracked project set grows, without needing a schema rework.
The evidence — full reasoning behind the verdict
Verdict: proven. The specific claim this project made — that distributed rail assets are a geospatial problem first, and PostGIS is the right infrastructure for it — is backed by a real, shipped, working system, not a pitch.
The system runs the full stack (Node/Express, React, PostgreSQL + PostGIS) in production behind Docker and Nginx, and PostGIS queries answer exactly the questions a flat table couldn't: proximity, clustering, corridor overlap. The second half of the claim — that this should stay a tracker, not grow into a control system — is also borne out: the report holds that line explicitly rather than letting scope creep in, and nothing in the record contradicts it.
Rail passenger-information and PA-system projects across a region rarely live in one place — different contractors, different cities, different stages of delivery. This project asked a plain question: what does it take to actually see that pipeline in one system, rather than reconstruct it from memory and spreadsheets every quarter.
What it was
A monitoring system for tracking passenger-information and PA-system projects across a global rail market — not one line, one system that watches many. The scope was deliberately a tracker, not a controller: know what's happening, where, and at what stage.
What we built
Shipped & measuredA working full-stack system: Node.js/Express on the backend, React on the frontend, PostgreSQL as the database — with PostGIS doing the real work. Distributed rail assets are a location problem before they're anything else, and a flat table of project names and cities was never going to answer questions like "which projects are near which corridor" or "what's clustered in this province." PostGIS made those queries native instead of bolted on. The system shipped with monitoring and CI/CD wired in, deployed behind Docker and Nginx.
What we learned — including the honest negative
The infrastructure call was the right one: choosing real GIS tooling over a flat table paid for itself the first time a genuinely spatial question came up. That's a small but real lesson worth generalising — when data has a location, treat the location as first-class from day one rather than retrofitting it later.
The honest edge is exactly that restraint: this is a monitoring and tracking tool. It does not issue announcements, does not touch a live PIDS screen, and was never meant to. Scope stayed narrower than the safety-critical control systems built alongside it in the same domain.
Where it went / status
Shipped and working — backend, frontend, monitoring, and CI/CD all in place. It sits as one node in a longer rail-domain thread that runs through the portfolio, from an early 2022 tender-quoting prototype through this and on to the production PA/PIDS control-centre work that followed a year later.
What is still open — kept visible
The honest edges, next to the wins. This is what turns 🔬 into 🟢 — honestly.
- A monitoring and tracking tool, not a control system — it does not touch live PA/PIDS operations, only tracks the projects that build them.
- Regional scope by design — it was never built to be a global rail database, and doesn't claim to be one.
Sources
- vocabotics project audit — rail PIDS project monitoring (PostGIS, PA/PIDS tracking), Oct 2025vocabotics internal project history · as of October 2025