Build from a shared model.

The specifications explain the intended relationship between service facts, editorial choices and published information. Read their scope before treating a field or behaviour as a stable contract.

The standard addresses information quality; GTFS-Carto describes editorial data; Semantic Transit SVG connects a drawing to its transport objects. The working documentation below explains each draft and links to its source.

Current development combines a Rust geometry core, WebAssembly and a JavaScript integration library. Supported input work includes route text, GTFS ZIP and structured GeoJSON. Outputs include vector diagrams, quality diagnostics and an interactive browser view.

Version 0.3.2 is published on npm as opentransitinformation. It includes precompiled assets; using the package does not require Rust. The API remains experimental, and the Node.js interface requires version 20 or later. Python bindings remain future work.

Geographical inputs and diagrams without geographical coordinates have different meanings. Preserve that distinction, along with the source, licence and relevant dates. Unknown accessibility information stays unknown.

Document extraction requires a supplied extractor and produces a draft for explicit review. It does not provide automatic, reliable reconstruction of arbitrary maps. Automated checks report defined problems; they do not establish legal compliance, complete accessibility or a finished cartographic design.

Begin with one input, one output and an explicit acceptance task. Keep examples reproducible and record the decisions needed to make them useful. Use a bounded workflow to record acceptance criteria, inputs, outputs and editorial decisions.

Future OTI products and services may support design, integration, publication and operation around the same foundations. Each offer will need its own tested scope and responsibilities.