Latest News

iPhone-specific

SysRailData has also developed an iPhone-specific version. (image 1)

EVeryWay for iphone (image 2 - image 14)

Voyages-sncf.com choose the eVeryway solution as timetable information tool on their help site.

SysRailData and DUO were asked by Voyages-sncf.com to set up a backup solution when the number or searches on their Voyages-sncf website reaches a critical alert threshold. The solution offered by the SysRailData & DUO partnership is built on the eVeryWay® solution that is hosted in 2 geographically distinct data centres, which can each process up to 4 million timetable searches per day. Voyages-sncf.com decided to set up a simple and robust solution, offering only timetable information, result printout for the web user, and price lists, in order to unload their main website temporarily. During the use of this backup website, all users will automatically be redirected to one of the available servers. The first load tests indicated that our solution was able to support 10.000.000 hits per day and more than 4 million timetable searches.

This solution has been under production since 9 April 2009 and will be used by Voyages-sncf.com whenever there is a need (website maintenance, unloading part of their site, website downtime, ...).

News

Lyria SAS

Lyria SAS entrusted us with designing their mobile website. SysRailData developed the timetable portal in 3 languages (French, English and German), integrating a version of eVeryWay® that can be accessed using any web-enabled mobile phone.

Railteam

A specific platform with the data set specific to Railteam was set up in order to enable the project teams to acess the timetables of the Railteam perimeter (ICE, THALYS, Euro-star, Alléo, TGV, Lyria).

New challenges

In our continuous efforts to improve response times and the quality of route results, we recently stumbled upon a challenging problem: to find good solutions for some very local ODs in regions with many very similar trains per day crossing the map in all directions, and to do so with the same acclaimed route calculation algorithm that already serves more and more happy customers for larger ODs.

The most familiar example to most people is probably the region around Paris, known as Ile de France. The public transport system calls these local connections Transilien. The order of complexity of the web of train and metro connections in this area compares to or even exceeds the railway network of a small country like Belgium.

When resolving route requests involving areas like these, there are actually several issues impeding performance and quality of results, of which we shall discuss two.

First, there are so-called implicit transfers, which are really placeholders for some kind of local transport - perhaps the very kind of connection the user wants to obtain in this case - to reach the correct station when continuing a journey after passing a major station like Paris. While very useful, these also multiply the number of possible connections in a small area, thereby taking up valuable  calculation time that could be spent elsewhere to find more intelligent solutions.
So this is both an issue of performance and quality.

A second problem is the fact that certain optimizations, which really work wel for longer itineraries, get in the way (pardon the pun) when there are so many possible trains in a limited area. Sometimes, valid paths are discarded because the optimizer predicts their composing services will not lead to an interesting solution.

We took the opportunity to introduce a concept called "zones" in the engine, and improve performance of not only these problematic connections, but also drastically reduce the processing power needed for the longer itineraries we were already renown for. In the schedules database, certain smaller local trains are tagged as local services, and their stations are assigned a zone. When calculating routes, these local services are only considered if the destination
station is connected to a local service and when a station in the same zone as the destination station can be reached. In addition, we introduced smaller implicit transfers to replace the more coarse transfers that were impeding performance before. These local transfers are used rather than the old implicit transfers to connect between stations from the same zone.

To address the optimizer problem, we disable this particular algorithm for local services. In addition, some other details in the engine's behaviour are changed when a local zone enters the picture. These changes effectively make eVeryWay® aware of the context of the connection it is researching, so it can spend its energy solely on where it is best spent. The benchmarks confirm this pays off, since the average calculation time for random ODs has almost halved, with very complicated long connections benefiting even more from the improvements.

The future

The current version of the engine is version 9 and version 10 is in its test phase.

The new versions of the engine are always aimed along two axes:

• Offer more solutions with increased performance of calculation times,
• Offer new functionalities, either requested by our customers, or contributing towards future needs.

Some of these functionalities are already operational:

• cartographic presentation of the itineraries with Google maps

• the station timetable: displays the next departures or arrivals in a train station in real time.

• the journey planner lets you know the cities (capitals or major cities) that can be reached with a given time

Other subjects are being re-searched or are at the prototype stages:

• An eco-comparative makes it possible to compare the rail-way trips with other means of transport in terms of CO2 emissions,
• The integration of the Paris subway for all connections in Paris,
• A prototype was developed to display real-time information.