A C implementation of the RAPTOR public transit routing algorithm for generating Pareto-optimal itineraries over large geographic areas.
RRRR is a C-language implementation of the RAPTOR public transit routing algorithm, designed to generate sets of Pareto-optimal itineraries over large geographic areas like Europe. It solves the problem of efficient, real-time journey planning for transit systems while minimizing memory and computational resources.
Developers and organizations building public transit journey planners, passenger information systems, or mobility applications that require high-performance, offline-capable routing engines.
Developers choose RRRR for its exceptional memory efficiency, support for real-time updates, and ability to run on resource-constrained devices like smartphones, all while handling continent-scale transit networks.
RRRR rapid real-time routing
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Uses memory-mapped files and reusable scratch buffers, allowing entire European transit networks to run in about 20MiB, as noted in the README for Netherlands coverage.
Implements the RAPTOR algorithm with separate worker processes, achieving high throughput (e.g., 256 req/sec in tests) for Pareto-optimal transit itineraries over large areas.
Engineered to run directly on mobile devices without internet, making it suitable for embedded transit apps, as stated in the project goals and introduction.
Leverages zeromq for message passing between workers, enabling horizontal scaling on servers with minimal memory overhead per process, as shown in the build and startup logs.
The README explicitly states that on-street searches (e.g., walking) are not handled in the first phase, limiting door-to-door journey planning capabilities.
Requires multiple external libraries (e.g., zeromq, libprotobuf-c) and a multi-step build process with Python scripts, which can be cumbersome and error-prone for newcomers.
Real-time update support is described with 'eventually' and relies on planned protocols like protocol buffers over 0MQ, indicating it's still in development and not production-hardened.
Being implemented in C, it poses a steep learning curve for teams accustomed to higher-level languages and limits ecosystem tooling compared to more popular frameworks.