Skip to content

Technical Overview

Jump to bottom
Nikhil VJ edited this page Apr 25, 2018 · 2 revisions

  • The core program is a Python3 script in GTFSManager.py. It launches a simple web server via Tornado module, and waits for asynchronous GET and POST requests.

  • These requests are made by the javascript in front-end HTML files as they are loaded in the browser and user navigates the program (which is like a typical website). The javascript makes GET or POST calls to the API, and gets data as callback to show to user.

  • The data is (as of v1.4.2) stored in a GTFS/db.json file, operated through tinydb module. Query-based or whole-table read-write operations are performed on this database while the user interacts with the frontend.

  • There is an additional sequence.json also maintained, storing a default sequence of stops per route and chosen shapes which is not part of official GTFS spec, but is used here to help structure the way new trips are created under a route.

  • Export of data results in CSVs being generated and zipped up to form a gtfs.zip. Its link is made available to the user for downloading. Exact reverse process is there for importing of GTFS feed.

  • The tables are heavily inter-linked, hence the tool features a dedicated Maintenance section (found under Misc) for handling renaming and deleting of id's. Deleting an id entails futher deletions elsewhere in the database : either whole row delete where it was a primary key, or zapping of the field where it was secondary.

  • There is a separate XML Import section created to cater to the project's first client KMRL's specific data format which needs to be converted to GTFS. There are many diagnostic functions at work there to ensure that the data uploaded and information entered is valid.

Clone this wiki locally