Train schedules

Introduction

Timetable of train

verso with more timetable

map of the railway network

zoom on detailed path

This project aims to observe how a railway user of the middle of the 19th century could travel between some cities such as Paris, Lyon, Geneva or Marseille in regards to nowadays. Several aspects of the trip have been looked into, the journey path, the schedules of the trains and the price of the tickets. All of these informations come from a single document that contains both a timetable and a map of the railway network and have been computed into a program, so one can look for a trip and find easily all the informations needed. This whole project puts into perspective how the evolution of transports, in this particular example trains, have made the world much more connected and travelling much easier.

The document

This project will focus on this old train schedules from 1858. It has been found in the Bibliothèque Nationale de France's (BNF) digital library, Gallica. This document belongs to BNF's department of maps and is in free access, as all the document presented in Gallica.

It has been made by Alfred Potiquet (1820-1883), a civil engineer known for being responsible of the first stamp catalogue in the world, in 1861. Its exact title is Chemin de fer de Lyon à Genève. Marche des trains depuis le 10 novembre 1858. Correspondances les chemins de fer de France, de Suisse & d'Italie. As the title implies, it contains the complete timetable for train between Lyon and Geneva, but also the connections between Swiss, French and Italian trains. It has been decided to focus the project on this last aspect, since it is more relevant for us to know how long it takes to go from Paris to Geneva than from Montluel to Bellegarde for example.

This document shows different possible paths between "important" cities, with detailed stops when the train is between Mâcon, Geneva and Lyon, as seen in the picture zoom on detailed path'. For each of this path, one can read the prices for each class (first, second and third), the distance between the destinations ad the different departure and arrival times. Some mental maths were required, as the prices and distances were always shown in regard to the first city of the path.

A few observations can be made on the document. First, some trains are written as "express" and are first-class only. Then, the schedules were based on a 12-hours format, with the indications of "matin" (=morning) and "soir" (=evening) to know if it is am or pm. However, these indications were not always clear and it can get quite confusing to know whether the train leaves in the morning or in the evening. Furthermore, some small incoherences were observed in the timetables, for example the distance is sometimes different if one goes from A to B or from B to A. Same goes with the prices. But these differences are usually not more than a couple of kilometers or a ten of cent.

Milestones

This section summarized the different milestones achieved and the corresponding dates. It was necessary to organize this project as a series of milestones with corresponding dates, first to ensure that it was feasible, and then to encourage the group to work on a weekly basis even though the project itself was only due at the very end of the semester. The first obvious thing that had to be done with such a document was understanding how it works, i.e. what informations it contains and how they are organized. The document was printed in an A3-format to facilitate its study and the manual data extraction. Then the main focus switched to the coding part of the project. Some basic knowledge in web languages (HTML, Javascript, JSON, CSS, ...) were essential for this project and one had thus to get first familiar with this language. Then, some Javascript library were identified as potentially helpful and the data were chosen to be entered in the computer as JSON objects. As this is a quite tedious job, It was decided to make a first test of the program with only one possible route, and then, only if it turned out to work well, to enter more data to extend the program. The feasibility of converting the data into GTFS (General Transit Feed Specification) format was evaluated, but it was concluded that we did not have the appropriate skills to do so. The aesthetic aspect of the interface and the completion of the wiki article were dealt at the end of the project, when the program was fully working. All these tasks were evenly splitted in order for each member of the group to spend the same amount of time on the project.

The following list summarizes how the project was planned:

• 12.10.2018: Formation of group, choice of map.
• 17.10.2018: Decision about what to do with this map. Resulted in a CFF-like website.
• 19.10.2018: Presentation of the idea to the class.
• 24.10.2018: Understanding of the document, A3-model printed.
• 31.10.2018: Getting familiar with web languages. Basic HTML program. Choice of system to store the data (JSON file). Creation of the graph.
• 07.11.2018: Preparation of the slides for the midterm evaluation. Choice of java libraries for the program.
• 09.11.2018: Mid-term presentation.
• 21.11.2018: Working program with one route only and departure only (Paris - Bourg). Creation of the website, with different tabs (Search, Document, About). First consideration of aesthetic aspect (CSS file).
• 28.11.2018: Add arrival option. Now search program is fully operational. Half of the data computed in the JSON file.
• 05.12.2018: Full set of data.
• 12.12.2018: Aesthetic aspect (CSS file). Website finished
• 14.12.2018: Complete the wiki article.

Extraction of the data

zoom on detailed path

In this document, the data were presented in tables, making it relatively easy to extract. It has been decided since the beginning of the project that the extraction will be done manually, which would be faster than learning how to use a program and then set it up for this document. Indeed, the amount of data was consequent but still feasible. Moreover, with the morning/evening schedules not always clear and with some data requiring basic maths, it seemed simply easier to it by ourself.

The best way to work with this kind of data is to create a graph. So one needed the connections between each node of this graph (i.e. the cities). The format chosen to store the data was JSON. GTFS (General Transit Feed Specification) had been considered and would have been more relevant, since it is the classic format used for public transportation around the world and thus would have made this project more easily reproducible and exportable. Unfortunately, it looked like the only way to use this format was to set up a server to host node.js and after several unsuccessful attempts, it was concluded that we lacked the required skills and it would have been too time-consuming to spend more time on it.

JSNO files are extremely handy to store this kind of data. An object has been created for each city, containing all the cities linked to it, the schedules of the trains going there (including a boolean express to know whether the train is first-class only), the price of the ticket for each class and the distance between them. The example shown here is for Paris. It is only connected to Mâcon and there are two trains per day, one being a first-class only.

The map

• comparaison with actual railway networks
• ...

The app

• how it works
• example of comparaison

Further possible development

• assess impact of train in cities development
• create a game with trains