A matrix which is defined in terms of zone-to-zone cells may be “compressed” (or “aggregated”) into a matrix of group-to-group cells by adding together all the appropriate zonal cells. Mathematically:
where I and J represent the rows and columns of an aggregated matrix, i and j are zonal rows and columns and i denotes the fact that zone i is contained within group I.
Note that this form of aggregation is appropriate for, say, a matrix of trips where it is natural to add trips together but it would not be appropriate to a matrix of, say, zone to zone distances where ideally the group-to-group distance should be some form of weighted average of the zone-to-zone distances.
The rules for compression/aggregation may be specified via a number of different formats: (1) an explicit mapping of zones into groups, (2) hierarchical numerical rules and (3) specific TfL numbering conventions for traffic boroughs. These are described in further detail below.
The conversion from zones into groups may be either set explicitly by an external “Z2G” file or by pre-defined zone-to-group data.
Hierarchical aggregation uses two parameters, NBASE and IROCKY, to create new aggregated zones based on the current set of zone names by applying the formula: “new” = NBASE + old/IROCKY. Generally speaking IROCKY will be 10 or some power of ten on the basis that the first digit in a zone name equals a “sector” of some sort. NBASE, generally 1, is included so that a new zone name of zero is not permitted (whereas the very similar use of IROCKY to define sectors explicitly does not use NBASE since a sector 0 is permitted).
The specific aggregation of a TfL SATURN matrix from zones to traffic boroughs follows the rules used by TfL (see 5.1.7.2) to include the definition of a traffic borough within a zone number, specifically using the first two digits.
Note that the MXZ2G (and similar) does include any intra-zonal trips in the aggregation.