Hierarchical Travel Matrix¶

Matrices¶

For dynamic scheduling it is usually recommended that a Hierarchical Travel Matrix (HTM) be used. The table below shows a list of currently available HTMs by region and matrix id, including their final installed size. Note that more disk space will be required during the installation process.

HTMs will only cover the mainland components of the named countries/areas, and not dependent or overseas territories, unless otherwise specified.

Current HTMs¶

Deprecated HTMs¶

Azure Database Tier¶

The Azure database pricing tier required for an HTM database will depend on a number of factors:

• The size and geographic spread of the customer data. Data with many activities covering a large geographic area will result in a much higher load on the database.
• The size of the HTM database being used. Larger databases, such as the North America HTM, will generally have a significantly higher load.
• The performance required of the scheduling system. The main load on the HTM is when the DSE is processing an initial load, which is usually overnight. The pricing tier to use should be based on ensuring that the DSE is able to process this load and all subsequent changes in reasonable time.

For scheduling problems of 3,000 activities or more, the minimum recommended Azure HTM database size to use is S3.

However, our recommended option for larger scheduling problems is to use the 'vCore Serverless' scaling option, with a maximum of 4 vCores and a minimum of 0.5 vCores. For very large problems the maximum could be increased to 6 or 8 cores.

Accuracy vs. Performance¶

The latest HTMs (V3+) include Routing tables to give precise travel estimates over short distances. These will be used by default for both scheduling and appointment booking.

When using these routing tables the services will read significant quantities of data from the HTM database, especially for larger scheduling problems spread over a large area. This will increase the load on the HTM database, and so can impact on the time taken to generate plans and process appointment requests. It also significantly increases the memory usage of the service components.

The use of these routing tables has been optimised to keep this impact as low as possible, though factors such as network bandwidth and database machine performance should also be considered. In Azure this would relate to the database performance tier.

Customers for whom performance is critical may wish to consider switching off the use of the routing tables, which can be done via setting the parameter 'RoutingMaximumDistanceMeters' to 0. See the appendix section on appointment booking performance for details of tests carried out.

Automated Intelligent Travel Profiles¶

The Hierarchical Travel Matrix is designed to give an accurate estimate of the average expected travel time for a journey, but this is not dependent on the time of day. Typically this will give a good approximation during 'normal' traffic flow periods (e.g. in the middle of the day), but will tend to be optimistic during rush hour periods.

To compensate for this travel time profiles can be used. This allows an additional weighting to be applied at certain times of day, to slow (or speed up) the expected journey times during this period. These weightings can also be area dependent, to target urban areas where the rush hour is likely to have a greater impact.

Automated Intelligent Travel Profile (AITP) files are now optionally provided alongside the HTM database for customers to use. These files have been generated using TomTom speed profile data, based on advanced machine learning techniques. Each file supplies travel weightings for urban areas within the HTM region, to provide more accurate travel estimates at any given time of day. These files are available for all V3 and V4 HTMs.