transitive.js: schematic transit maps drawn from OpenTripPlanner output

A schematic map is a different artefact from a geographic one

transitive.js is a tool for generating dynamic stylized transit maps that are easy to understand, and the input is specific: information describing transport network elements, routes, stops and journeys, typically produced by the OpenTripPlanner Profiler extension. The output is a schematic map of those elements. The word schematic is doing the load-bearing work here. A geographic map answers where things are, and a schematic answers how things connect. The classic metro diagram that every city has drawn since the 1930s exists because a stop network with a fixed topology reads better when the distances are invented. transitive.js renders that genre as SVG, which is why the network geometry is derived from the graph structure rather than from coordinates, and why the output scales and repaints cleanly.

Dynamic styling is what makes a single journey pop out

The README says dynamic styling of the network elements allows for interactivity and flexibility in the visual presentation, and gives a single case: one journey can be highlighted. The screenshots demonstrate it with the same network in two states. This is a rendering model rather than a static image, so the map is a live object you can drive. The styling model is where the data flows, and the package dependencies show the machinery: d3, svg.js for the SVG drawing, and helpers such as rounded-rect, measure-text, priorityqueuejs and sphericalmercator. The mercator projection and the text measurement library are there for labels and geometry, and the priority queue is a hint that the layout work is not a simple loop. You can also override the default style with a style prop, and the README points at a style example in the transitive-demo repository.

Standalone or as a Leaflet overlay, and the embedding asymmetry

A Transitive map can be embedded as a freestanding web element or overlaid onto a Leaflet map using the Leaflet.TransitiveLayer plugin. Both demos are linked, one showing a freestanding map and one showing the Leaflet combination. The Leaflet path is the interesting one for a planner, because it lets a schematic overlay sit on top of a real basemap, so the user gets both the topology and the geography. The Leaflet.TransitiveLayer plugin lives in its own repository, which means the integration is maintained separately from the library and you have to version it yourself. The library itself depends on Leaflet only in the development setup, through the otp-ui story dependencies, so the core package stays independent of any mapping framework.

The Storybook is the documentation and the test harness

The README points to a live Storybook hosted on S3 for samples of Transitive in action, and gives the local run recipe.

git clone https://github.com/conveyal/transitive.js
cd transitive.js
yarn start
# Go to http://localhost:5555 to view the storybook (the web page should open automatically)

The stories rely on the otp-ui project to render Transitive data on a Leaflet map, and three of its packages are used for that. The base-map package renders the Leaflet basemap, core-utils converts an OpenTripPlanner itinerary object into data Transitive can read, and transitive-overlay is copied from otp-ui and swapped to point at the local Transitive build, which the README says is useful for testing local changes. That copy step is a small but important detail: it is how you see your own edits in the overlay without publishing a package. The repository root backs this up with a .storybook directory, a stories directory, a lib directory holding the TypeScript source, and an __tests__ directory.

Bring your own data by swapping one prop

There is a documented path for testing with your own data without writing an integration. To see how your own data, for example an OpenTripPlanner itinerary, would appear, you replace the itinerary prop in the Itinerary story, or the transitiveData prop in the Profile story. The two props correspond to the two input shapes the library expects, one being a journey and the other a network profile, which matches the two kinds of thing transit planning produces. This is a small design decision with a large practical payoff. Rather than a fixture file format, the contract between your data and the library is expressed as a React prop, so the same substitution works in a story, in a test and in production code. The API documentation is on the project wiki, and the See Also section points to conveyal/modeify, a sibling project in the same ecosystem.

A d3 version 3 dependency in a tsdx build, and a quiet release history

The build setup is dated in ways that matter for adoption. The package builds with tsdx targeting node, the test script runs tsdx lint over the tests, lib, stories and storybook directory, and the test runner is tsdx test with jest underneath. The dependency list pins d3 at ^3.5.8, which is the old major version, alongside svg.js at 2.6.5, augment, component-each, component-emitter and lodash.foreach. The storybook is version 6 with React 17 in the dev dependencies. The release history is quiet: the most recent listed release is v0.14.1 from May 2022, with v0.14.0 in October 2021 and v0.13.7 in April 2021, while the last push was on 2026-06-21. The repository is not archived, so work continues on the default branch, but there have been no tagged releases in several years, which means if you adopt it you are adopting whatever the master branch holds, and the npm package version may lag the code. The licence is MIT, and a SemVer-based release flow is wired up in the scripts through semantic-release.

Editorial conclusion

transitive.js fits a transit planning team that needs a schematic diagram rather than a geographic map, for a journey planner, a printed handout or a kiosk, and who can supply network data in the shape the library expects. It does not fit a project that needs a map with real geography, since the whole point of the library is to discard that, and it does not fit a team on a modern build toolchain, because the package is built with tsdx and depends on d3 version 3. Verify first that your data source produces the network and itinerary structures the library reads, try the live Storybook before writing any integration, and check the changelog and the pinned d3 version before you plan around the current API.

Frequently asked questions

Official sources

1. conveyal/transitive.js on GitHub
2. License: MIT
3. Project website
4. README
5. Releases