Raising this subject is thought-provoking. On one hand, I wanted to do something, and some of you may appreciate it, but on the other hand, why should I look at a company from a different country? And no, this is not a sponsored post. My reason to do this was simple: just read on and check if you feel butterflies in your stomach or not.
API SNCF is one of the most curious transportation APIs that I have encountered in my career (during integration ventures). But I must admit that “curious” doesn’t always mean “good”. It’s true that I have experience in working with the older, XML version, with more SOAP services, but the basic concepts are similar in this case. The SNCF Open Data concept is laudable: let’s share data from our business with other people so they can start doing other business based on SNCF.
Access is free for every developer, but there is a limit of operations – 90,000/month and up to3,000/day. You can register as a developer for free here, and such an account is sufficient for running small tests. These tests consist of a few non-coordinated read-outs, which are helpful in getting information about specific rail travel. Unfortunately, this service is available mainly in France (it operates on data from France). That’s a shame because it would be beneficial in Poland, too.
The API access token is the basis of communication. It must be accounted for in the heading of every web request (username). Basis address: https://api.sncf.com/v1.
What we receive in return is a list of available services. Autocomplete, journeys or geocoding API are all standard solutions used when operating on transportation data. But coverage of Nativia is a whole different story….
As you can see by looking at an unauthorised response, SNCF API is based on Nativia software, which is an open-source solution created by Kisio Digital. It’s available on nativia.io with interesting documentation on doc.nativia.io. The start page for developers beginning their journey with SNCF API is quite good. Check it out here.
Above all, we need to take notice of rapid insertion to vocabulary, as well as the nomenclature used in the transportation industry (rail industry in this case). Examples in jsfiddle aren’t necessarily up to date, but it takes a while to update it by entering the proper basis address and access token.
The most important basics we need to remember:
- Access data in API is strictly connected with the French market, but the abstractions used in it are universal and may be used in other countries (i.e. in Poland which would require implementation of Nativia software and feeding it with data in General Transit Feed Specification format and others similar to it),
- The SNCF API contains theoretical and real-time train data for the following commercial modes: TGV,TER, Transilien (only theoretical, separate endpoints), Intercités,
- The SNCF API handles Journey computation, Line schedules, Next departures, Exploration of public transport data (Search places, Autocomplete, Isochrones),
- Stop_point is the smallest part of information (as a location, where a train can stop). Stop_points are grouped into stop_areas and connected with links or journey_pattern (it depends on whether we ride or walk),
- The whole ride route is aggregated to journey which is aggregated to route,
- From rails’ standpoint, time (stop_time) and kind of vehicle (inside vehicle) are also crucial,
Source: ticketstravelnetwork.com
- One last piece of very helpful information: API is based on Nativia so we can use documentation on their website by claiming another basis address.
Now we can go back to the coverage issue:
This gives us a list of all available datasets from the “sncf” region, i.e.:
- Addresses
- Contributors
- Companies
- Connections
- Vehicle_journeys
- Stop_points
- Coverage
- and more…
Blah blah blah. There is a lot of it, right? The best thing we can do is to focus on the essence: dictionary data, journey data, the nearest places and rail transport data.
Hypermedia API
Examples of methods:
- Stop points (it’s necessary to remember about pagination, start_page=n)
- Places (q=City)
- Journeys (may be divided into arrivals and departures; for interpretation, dictionary should be taken into account)
- Places nearby (it’s crucial to provide correct geographic coordinates)
- Traffic reports
Despite sincere intentions, it’s difficult to say that hypermedia API and the method’s results are impressive. What’s more, we can get a little confused while trying to connect and interpret data from lists and trees to connection graphs. Postman or another API client won’t help us to read transportation data better.
Luckily, Nativia is coming to the rescue with their testing client (Nativia Playground). We receive suggestions of method parameters and interpretation of initial results (and presenting them on the map). We just have to change the base address and token, and the results are much more understandable to us.
- Stop points on the map (the first 25)
- Places (Paris)
- Journey planning
- Places nearby (json interpretation, tree browsing)
- Available lines
And here we are again – without a specific scenario of using it, API is a bit boring to us. At least until we find something called isochrony.
Whether using a specific set of coordinates or a general location, you can find places within your reach and their corresponding travel times using a variety of transportation options. You can even specify the maximum amount of time you have to spare on travel and find the quickest way to reach your destination.
And indeed, when we provide
information about localisation and maximum travel time, we can find
out what is available within our reach:
Conclusion
Transport API is excellent if it offers a uniform set of abstractions and methods of interactive data analysis. Having such a solution in Poland would be amazing.
