I built a browser-based GTFS viewer for transit professionals (and why this niche deserves better tooling)
If you've ever worked with public transit data, you've probably run into GTFS - the General Transit Feed Specification. It's the de facto standard for distributing transit schedules, routes, and stops. Every major transit agency publishes it. Developers use it to power trip planners, researchers use it to study network coverage, consultants use it to audit service patterns.
And almost everyone who works with it regularly has the same complaint: inspecting GTFS feeds is surprisingly painful.
The problem with the current workflow
GTFS is a ZIP file containing a set of CSV tables - routes.txt, stops.txt, stop_times.txt, calendar.txt, and so on. The tables are relational and the data can get large. A single feed for a mid-sized agency might have 50,000 stops and hundreds of thousands of trip records.
The typical workflow looks something like this: download the feed, unzip it, open the CSVs in Excel or a text editor, write some Python or R to join the tables, spin up QGIS or another GIS tool to visualize the routes. Repeat every time you want to check something.
This isn't bad tooling in the abstract - it's just not a great experience for quick exploration. If you want to answer "does this route serve this neighborhood?" or "what does the Saturday schedule look like?", you don't want to write a script. You want to just look at it.
What I built
TransitLens is a browser-based workspace for exploring GTFS feeds visually. You load a feed (local file or remote URL), and you get:
- A map of all routes and stops
- Structured tables for routes, stops, and trips
- Schedule and calendar views
- GeoJSON and KML polygon import for spatial queries (e.g., "which stops fall within this service area boundary?")
No installation. No setup. Works entirely in the browser.
The goal isn't to replace GIS tools or code for serious analysis - it's to make the first 10 minutes of working with a new feed fast and clear.
Why browser-based matters
Transit data work happens across a range of environments - analysts on Windows, consultants on Macs, developers in Linux terminals, planners at agencies without software budgets. A browser-based tool is neutral territory. It also means I can share a link to a specific feed view, which is useful for team discussions.
Who it's for
Primarily transit developers, planners, analysts, and researchers who regularly work with GTFS data but don't want to fire up a full GIS stack just to answer a quick question about a feed.
I built this because I kept running into this problem in my own work and couldn't find a lightweight, modern tool for it. The niche is small but real, and the people in it are serious about their workflows.
Happy to answer any questions. If you work with transit data, I'd love to hear how your current setup looks.
