Box UK: BBC Innovation Labs Blog

I mentioned in a previous post that journeys were particularly complex datasets; how so?

If we begin by looking at a (relatively) simple definition of the term: a journey is a directional route between two geographic locations, at a particular time, via a particular mode of transport.

This, in itself, is a bit of a mouthful, with a number of variables already rearing their ugly heads. However, if we now think about how we may want to compare a ‘journey’ to other sets of data – as a case in point, travel warnings – we can uncover even more complexity:

• There could be multiple sub-journeys (e.g. by different modes of transport: walk, then car, then train, then tube, then bus).
• Defining a route between two points does not necessarily provide all the necessary information, e.g. which bus or train is being used.
• There are no standard conventions for identifying ‘parts’ of a road (the primary type of ‘route’ for walking, car, bus and bike), with the exception of motorways.
• A journey might not just be concerned with getting from A to B in the shortest time/distance, but also with a number of intermediate locations (e.g. for a preferred route through a park, via a coffee shop, or to pick-up a friend).
• The ‘directional’ aspect of journeys is particularly important; roadworks on a southbound section of road may not be of any interest – for the sake of ‘comparing’ the data – if you are traveling northbound.
• With the specific case of travel warnings, an incident at a particular point can affect routes/journeys ‘further up/down the line’, and not just at the specific location.

So, in the case of an application that compares user-defined journey data with other data sets, we can summarise the above as two fundamentally difficult problems to overcome:

1. A journey may be inherently complex (the route(s) and mode(s) within it), but much of this must be hidden from the user, so that they may quickly, easily and accurately define their routes – without frustration. The end-user benefit of the application must greatly outweigh the investment needed to use it.
2. The data-sets may be difficult to compare accurately (e.g. roadworks at a specific location, without knowing whether it affects north or south-bound traffic, or how a delayed train may affect a journey which includes part of that train’s route within it).

What potential solutions might there be to these fundamental problems?

• In reality, most users may not care about every detail of their journey. Instead, they may focus on an individual part of their journey, probably that which occupies the majority of their time, e.g. a single train journey, or a commute along the motorway, without being concerned about how they get to/from the train/motorway.
• With regards to the lack-of a systematic identification system for parts of roads, data-sets may be compared purely on their geo-spatial attributes (long/lat), assuming they are available in both sets (although the geo-spatial width/area of the road/incident will need some thought, to see if there is ‘overlap’ in regions).
• Google Maps already has a sophisticated, intuitive system for defining ‘waypoints’ for a journey – we could use the API.

We’ll be thinking more about these (and other) problems/solutions over the coming pre-lab weeks. In my next post, I’ll talk a little about the scope of the project.

*** Dan