London Underground Map Data - Data Format
ERD
Map
Data
Mapdata
Orangeness
 

The map data in the data file is designed to store information in a form which is suitable for insertion into a relational database. Effectively, the records described below are relational tables without the foreign keys connected. Connecting the foreign keys to a suitable generated primary key values is what the data manipulation program does.

I feel I should apologise for this description of the data format. What is here is just the end result; I have nothing written down about the process I used in reaching this result, which is probably more interesting than the data structures!

Top
Entity Relationship Diagram

The entity relationship diagram below is really of the database table, but it should also be useful in trying to understand the text file content. Note that both the diagram and the description below make reference to station alignments, which are no longer extant.

I should redraw this in UML, but one strength of this diagram is that it was produced by the same tool that generated the initial forms of the C++ data structure code. I like that kind of continuity.

Top
Map Structure

The map contains the following things:

  • lines - these have a name, a short code and a colour

  • stations - these have a name, a zone and an alignment

  • station nodes - for each distinct component of a station, there is a station node. For a co-situated station, there is one node per line (eg Mansion House). For a simple interchange, there is one node (eg Victoria). For a compound interchange, there is one node per blob (eg Paddington has three).

    A station node has a quadrant (most stations have all their nodes in the same quadrant, but Shepherd's Bush doesn't so quadrant has to be stored at this level), an ordinal (a number identifying the node uniquely within the station), map location, and flags for whether it is part of an interchange or is a terminus.

  • line segments - these are the sections of a particular line connecting station nodes. Each has line segment has an originating station node, a destination station node, a direction in which the segment sets off (used for calculating alignments), and a flag indicating whether or not the segment is available in peak hours only.

Top
Data File Structure

In general, the records in the data file all follow the form -

<record type> TAB <comma delimited data>

The individual records are defined as follows:

LINE Type String: line
Format: <line code>,<colour>,<name>
STATION Type String: station
Format:

<name>,<zone>,{<default quadrant>}

... where <zone> is the zone number for stations in only one zone but both zone numbers separated by 'b' for zone border stations (eg 2b3); and <default quadrant> is the quadrant compass point if all nodes in the station lie in the same quadrant. Quadrant boundaries are signified by specifying the half.
STATION NODE Type String: node
Format:

<line code>,<ordinal>,({<flags>}),(<x>,<y>){,<quadrant>}

... where {...} indicate something optional; and <flags> includes an 'i' for an interchange and a 't' for a terminus (eg Stratford (DL) would be it); and <x>,<y> are in pixel coordinates relative to Tottenham Court Road; and <quadrant> is defined in the same way as for <default quadrant above>, and is only needed where the node quadrant varies from that default.

Note: the station of which a particular node is deemed to be a part is the most recently named one.
LINE SEGMENT Type String: line
Format:

<direction>,({<flags>}),<to station>:<node ordinal>

... where <direction> is a compass direction; and <flags> are 'p' for peak only line sections.

Note: the <from station>:<node ordinal> is taken to be the most recently defined node.

Top
London Underground Map Data - Data Format
ERD
Map
Data
Mapdata
Orangeness
Last updated 29-September-2004