{"id":13423423,"url":"https://github.com/bliksemlabs/rrrr","last_synced_at":"2026-03-14T01:43:14.400Z","repository":{"id":6478754,"uuid":"7718868","full_name":"bliksemlabs/rrrr","owner":"bliksemlabs","description":"RRRR rapid real-time routing","archived":false,"fork":false,"pushed_at":"2020-12-27T02:26:26.000Z","size":2092,"stargazers_count":166,"open_issues_count":48,"forks_count":32,"subscribers_count":24,"default_branch":"master","last_synced_at":"2024-10-26T23:10:41.167Z","etag":null,"topics":["gtfs","gtfsdb","journey","planner","transit"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-2-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/bliksemlabs.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2013-01-20T16:55:01.000Z","updated_at":"2024-10-06T16:17:44.000Z","dependencies_parsed_at":"2022-09-24T10:10:56.318Z","dependency_job_id":null,"html_url":"https://github.com/bliksemlabs/rrrr","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bliksemlabs%2Frrrr","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bliksemlabs%2Frrrr/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bliksemlabs%2Frrrr/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bliksemlabs%2Frrrr/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/bliksemlabs","download_url":"https://codeload.github.com/bliksemlabs/rrrr/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243766836,"owners_count":20344820,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["gtfs","gtfsdb","journey","planner","transit"],"created_at":"2024-07-31T00:00:34.241Z","updated_at":"2025-12-18T09:04:58.556Z","avatar_url":"https://github.com/bliksemlabs.png","language":"C","funding_links":[],"categories":["C","Producing Data","Uncategorized"],"sub_categories":["GTFS","Uncategorized"],"readme":"RRRR Rapid Real-time Routing\n==============================\n\nIntroduction\n------------\n\nRRRR (usually pronounced R4) is a C-language implementation of the RAPTOR public transit routing algorithm. It is the core routing component of the Bliksem journey planner and passenger information system. The goal of this project is to generate sets of Pareto-optimal itineraries over large geographic areas (e.g. BeNeLux or all of Europe), improving on the resource consumption and complexity of existing more flexible alternatives. The system should eventually support real-time vehicle/trip updates reflected in trip plans and be capable of running directly on a mobile device with no Internet connection.\n\nMultiple RRRR processes running on the same machine map the same read-only data file into their private address space. This file contains a structured and indexed representation of transit timetables and other information from a GTFS feed. Additional handler processes should only increase physical memory consumption by the amount needed for search state (roughly 16 * num_stops * max_transfers bytes, on the order of a few megabytes). Eventually the real-time updater process will probably also use memory-mapped files for interprocess communication.\n\nEach worker is a separate process and keeps a permanent scratch buffer that is reused from one request to the next, so no dynamic memory allocation is performed in inner loops. Transit stops are the only locations considered. On-street searches will not be handled in the first phase of development. Eventually we will probably use protocol buffers over a 0MQ fan-out pattern to distribute real-time updates. This is basically standard GTFS-RT over a message passing system instead of HTTP pull.\n\nIt looks like in may be possible to keep memory consumption for a Portland, Oregon-sized system under 10MiB. Full Netherlands coverage should be possible in about 20MiB.\n\nDependencies\n------------\n\n1. **zeromq** and **libczmq**:\nMessage passing / concurrency framework used by RRRR for load balancing and scaling.\n\n1. **libprotobuf-c**:\nFor decoding incoming realtime messages. https://code.google.com/p/protobuf-c/downloads/list, Ubuntu packages libprotobuf-c0 and libprotobuf-c0-dev.\n\n1. **libwebsockets**:\nFor receiving incremental realtime messages. https://github.com/warmcat/libwebsockets.\n\n1. **shapelib**:\nFor visualizing realtime messages in OpenGL using a map of choice. http://download.osgeo.org/shapelib/.\n\n1. **libsdl**:\nFor visualizing realtime messages in OpenGL via een SDL surface. http://libsdl.org/download-1.2.php.\n\n1. **gcc** or **clang**:\nclang provides very good error messages and warnings. RRRR benefits greatly from -O2 and link-time optimization. http://clang.llvm.org/.\n\n1. **check**:\na unit testing framework for c. http://check.sourceforge.net/.\n\n\nBuilding transit data\n---------------------\n\nDownload a GTFS feed for your favorite transit agency. We typically work with http://gtfs.ovapi.nl/gtfs-nl.zip.\nWe used to depend on Graphserver for its gtfsdb Python class which loads a GTFS feed into Sqlite and \nprovides query methods. We have now copied our customized gtfsdb class into the RRRR repository.\nFirst, run `python gtfsdb.py input.gtfs.zip output.gtfsdb` to load your GTFS feed into an SQLite database.\nNext, run `python transfers.py output.gtfsdb` to add distance-based transfers to the transfers table in the database.\nFinally, run `python timetable.py output.gtfsdb` to create the timetable file `timetable.dat` based on that GTFS database.\n\n\nCoding conventions\n-----------------------------\nUse specific types from stdint.h for cross-platform compatibility.\nAbsolute times are stored in uint64 and referenced from the Epoch. The absolute time are always stored with DST disabled this as DST is defined at serviceday instead of the usual 3 am.\nTimes in schedules are uint16 and referenced from midnight. 2**16 / 60 / 60 is only 18 hours, but by right-shifting all times one bit we get 36 hours (1.5 days) at 2 second resolution.\nWhen the result of a function is an array, the function should return a pointer to the array and store the number of elements in an indirected parameter (rather than the other way around).\nThe data file is mostly a column store.\n\n\nBuilding and starting up RRRR\n-----------------------------\n\n```bash\n~/git/rrrr$ make clean \u0026\u0026 make \u0026\u0026 ./rrrr.sh\n```\n\nyou should see make output followed by the broker and workers restarting:\n\n```\nkilling old processes\nrrrr[31023]: broker terminating\nrrrr[31024]: worker terminating\nrrrr[31025]: worker terminating\nrrrr[31026]: worker terminating\nrrrr[31027]: worker terminating\n\nstarting new processes\nrrrr[31109]: broker starting up\nrrrr[31111]: worker starting up\nrrrr[31110]: worker starting up\nrrrr[31112]: worker starting up\nrrrr[31113]: worker starting up\nrrrr[31111]: worker sent ready message to load balancer\nrrrr[31110]: worker sent ready message to load balancer\nrrrr[31112]: worker sent ready message to load balancer\nrrrr[31113]: worker sent ready message to load balancer\nrrrr[31114]: test client starting\nrrrr[31114]: test client number of requests: 1\nrrrr[31114]: test client concurrency: 1\nrrrr[31114]: test client thread will send 1 requests\nrrrr[31114]: test client received response: OK\nrrrr[31114]: test client thread terminating\nrrrr[31114]: 1 threads, 1 total requests, 0.036565 sec total time (27.348557 req/sec)\n````\n\nThen you should be able to run the test client:\n\n```\n~/git/rrrr$ ./client rand 1000 4\n\nrrrr[31144]: test client starting\nrrrr[31144]: test client number of requests: 1000\nrrrr[31144]: test client concurrency: 4\nrrrr[31144]: test client thread will send 250 requests\nrrrr[31144]: test client thread will send 250 requests\nrrrr[31144]: test client thread will send 250 requests\nrrrr[31144]: test client thread will send 250 requests\nrrrr[31111]: worker received 100 requests\nrrrr[31112]: worker received 100 requests\nrrrr[31110]: worker received 100 requests\nrrrr[31113]: worker received 100 requests\nrrrr[31109]: broker: frx 0502 ftx 0499 brx 0499 btx 0502 / 4 workers\nrrrr[31112]: worker received 200 requests\nrrrr[31111]: worker received 200 requests\nrrrr[31113]: worker received 200 requests\nrrrr[31110]: worker received 200 requests\nrrrr[31144]: test client thread terminating\nrrrr[31144]: test client thread terminating\nrrrr[31144]: test client thread terminating\nrrrr[31144]: test client thread terminating\nrrrr[31144]: 4 threads, 1000 total requests, 3.893521 sec total time (256.836935 req/sec)\n```\n\nTesting Bliksem\n-------------------\n\nThis project distinguishes between several types of tests. The **unit tests** check individual C units related to the RRRR router repository, such as the BitSet or RadixTree implementations. They make use of the `check` framework [http://check.sourceforge.net/]. The **functional tests** demonstrate that the Bliksem system meets the functional requirements of the MMRI project through which it was created. The **performance tests** demonstrate response time and throughput on journey planning operations connecting 50 points throughout the Netherlands. The performance tests and functional tests are types of **integration tests**, in that they test the process of issuing requests to a fully-assembled trip planner system rather than its individual components.\n\nThe `testerrrr` tool is a single-binary planner which allows planning simple queries without starting up separate broker or worker processes. It is simple to use this tool on a planner validation set such as the one used by MMRI.\n\nGiven a test, zip the test to a GTFS-file and compile the GTFS-file to a GTFSdb. Use the resulting GTFSdb as input for our timetable builder.\n\n```bash\nzip test.zip *.txt\ngs_gtfsdb_compile test.zip test.gtfsdb\ntimetable.py test.gtfsdb\n```\n\nThe tool can now be executed:\n\n```bash\n./testerrrr --from-idx=1 --to-idx=2 -a -D 2014-01-01T00:00:00 -T timetable.dat\n./testerrrr --from-idx=1 --to-idx=2 -d -D 2014-01-01T00:00:00 -T timetable.dat\n```\n\nLicense\n-------\n\nCopyright 2013 Bliksem Labs. See the LICENSE file at the top-level directory of this distribution and at https://github.com/bliksemlabs/rrrr/. RRRR is released under the BSD 2-clause (simplified) license.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbliksemlabs%2Frrrr","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbliksemlabs%2Frrrr","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbliksemlabs%2Frrrr/lists"}