Architecture
Navitia is made of 6 main modules:
- Kraken is the c++ core
- Jörmungandr is the python frontend
- Tyr is the back-office boss
- Brokk, the postapp, is able to take and deliver all messages between all components
- Ed is the postgres database
- Sindri can persist real time perturbations in Ed
The second fiddles shown on the previous diagram, are:
- OSM2Ed which can fill Ed with some nodes and ways form OpenStreetMap database (take extracts from [http://download.geofabrik.de/](openstreetmap extract form geofabrik) for example)
- gtfs2Ed which is able to put public transport data into Ed
- Perturbations' connectors whom job is to translate different kind of perturbations into navitia's model
- Ed2nav which has the right to feed Kraken with a specific file called "data.nav.lz4"
- nav2RT which is describe below...
Jormungandr is the ws frontend. Spelling out request, it chooses the right worker (the right Kraken instance, but maybe another kind of worker in the future), requests it, waits for the answer and formats the good response. Jormungandr is multitenancy: its lonely instance is sharing by every Kraken instances and the reddis data cache. It can thereby process journeys between distinct Kraken workers.
Brokk is a broker. It is a RabbitMQ one. It assumes most of exchange between navitia components. The only exception is the communication between Jormungandr and Kraken, which uses zmq for performance purpose.
Il ne devrait y avoir qu’un seul exchange partagé par toutes les instances, c’est le topic qui détermine les instances ciblés. Par défaut le topic utilisé s’appelle “navitia”. Chaque application doit créer l’exchange avant de l’utiliser, sa configuration est la suivante:
type : topic
durable: True
Chaque message envoyé doit être associé a un topic(routing_key) précis, pour le temps réel le format est le suivant: “realtime.contributor”. Pour les communication intra-instance le format est le suivant: “instance_name.type.etc”, typiquement l’ordre de rechargement envoyé par pyed à kraken est associé à la clé suivante: “instance_name.task.reload”
Sindri persists real time events in Ed database. It only SQL persists them, Kraken are feeding straight by Brokk (well, actually not now, but in a few weeks :) ) Sindri receives real time events via Brokk.
Related connectors (like the next-to-come Chaos) have to transform specific formats into Navitia diagram model and to publish results on Brokk.
Chaque Contributeur temps réel se voit associé un topic, sous la forme : realtime.contributeur Le connecteur publie les événements sur l’exchange AMQP global (par défaut navitia) avec ce topic, ce qui permet à toutes les instances intéressé de pouvoir recevoir ces flux.
Les éléments insérés dans l’exchange doivent etre persistant ce qui se réalise en fixant la propriété delivry_mode à 2. Ceci permettra à Sindri de gérer la reprise sur incident
ED is the main database, which store
- theorical, adaptative and real time public transport data
- geographical and geocoding data
To fill Ed, there are many connectors. Some could need small databases to work: in that case, those small databases does not stand in Ed. Ed is pure ;-)
The database engine is postgresql with postgis extension. The database model will come very soon (we're currently working on it...)
gtfs2ed feed Ed with gtfs file. Ed can store more specific object properties than gtfs: accessibility data, comments, on demand transport data, traffic policy... All of them are shown in Ed database model. If you need one of that kind of data which is not managed by gtfs, you will need to produce another connector, and to append it in Tyr.
(whom real name should be nav2RT2nav, but...) who can take RT data in Ed, planned data from the "data.nav.lz4" files and feed Kraken with a new "data.nav.lz4" with some structuring perturbations (like a re-structured tramway route after a broken catenary)