Modelling Commuter Trip Length and Duration Within GIS Application to an O-D Survey

Journal of Geographic Information and Decision Analysis, vol. 3, no. 1, pp. 40-56, 1999Modelling Commuter Trip Length and Duration Within GIS: Application to an O-D SurveyMarius ThériaultCentre de recherche en aménagement et en développement (CRAD), Université Laval, Sainte-Foy, Québec, G1P 7P4, CanadaMarius.Theriault@ggr.ulaval.caMarie-Hélène VandersmissenCentre de recherche en aménagement et en développement (CRAD), Université Laval, Sainte-Foy, Québec, G1P 7P4, CanadaMartin Lee-GosselinCentre de recherche en aménagement et en développement (CRAD), Université Laval, Sainte-Foy, Québec, G1P 7P4, CanadaDenis LerouxUniversité du Québec à Trois-Rivières, C.P. 500, Trois-Rivières, Québec, G9A 5H7, CanadaDenis_Leroux@uqtr.uquebec.caContents1. Introduction2. Simulation needs and issues3. Modelling and simulation procedure4. Empirical results and discussion5. ConclusionReferences ABSTRACT This paper presents a modelling and simulation procedure to evaluate optimal routes (minimising impedance costs) and to compute traveltimes for each individual trip of an OD survey database. Canadian postal codes provide accurate locations within street blocks for each trip beginningand end point. Using TransCAD GIS software, the procedure finds the best routes through a topological road network. Each road (link in the network) is characterised by a maximal speed related to the functional class of the road, to its location in rural or urban areas, and to the distance from the nearest school. Turn and transfer penalties govern movements at the intersections. Moreover, the procedure calculates the number of persons travelling on every road (network link) to estimate a traffic map which is used to detect topological errors in the network and to estimate traffic congestion. Simulation results are totally dis-aggregated, making them suitable to model the mobility behaviour of individuals and households. They are key inputs in procedures for evaluating impact of transportation on housing markets (accessibility and traffic noise). Their availability for urban studies enables comparison of travel patterns among specific groups of persons. This procedure adds value to costly survey data that are already available in many North American cities, and enable space-time analyses of individual?s activities. The entire procedure can be run efficiently using a Pentium-based PC, even with large sample size (more than 100,000 trips). Hardware and software implementation costs are low (about 15,000 US$), making the computation tool accessible to transportation agencies and small research projects. KEYWORDS:t opological networks, optimal route modelling, origin-destination surveys, geographical information systems, transportation studies.1. IntroductionTravel time is among the most important factors that affects attractiveness of transport modes and consequent commuter travel decisions in urban areas (Makin et al. 1997). Accurate estimates and comparisons of travel paths and the duration of trips are basic requirements for planners, transportation industries, marketing businesses and social scientists. Their applications must consider aggregated effects of individual ch oices on the market penetration of public transport facilities. They need models to evaluate the foreseeable impact of new residential developments on the long term evolution of road traffic. They must improve understanding of how people choose where to live, shop and pursue leisure. The need to consider how travellers trade off costs within temporal constraints, while keeping inconvenience to the daily life of their households within acceptable limits (Arentze et al. 1993; Miller 1991).This paper presents a procedure to model commuters' travel routes and transit times using a very large data bank on commuting trips recorded in an Origin-Destination (OD) survey. Its purpose is to enhance the evaluation of mass transportation demand and to permit geographical analysis of commuters behaviour. The immediate objective is twofold. Firstly, we need to overcome methodological issues in modelling huge number of travel routes. Secondly, we want to demonstrate the feasibility and fruitfulness of integrating sophisticated simulation procedure into existing and user-friendly geographical information system (GIS). The ultimate purpose is to design efficient tools for large scale simulation.Evaluating duration of commuting trips is a basic requirement for our research program. We want to understand and model the evolution of households' mobility in relation to the geographical accessibility of activities in the Quebec metropolitan area (Canada). This mid-size city has an over-developed highway network: 21.7 km per 100,000 inhabitants.OD surveys are the main source of data about urban mobility in Canada, and elsewhere in North America. However, while these surveys yield the usual zonal matrices, they offer little o r no data on individually chosen paths, in terms of either distance or time, even though this information is indispensable for transportation planning, since trip duration and route geography are the most significant variables to consider while modelling commuters behaviour (Gordon et al. 1991).Gathering this crucial time information implies one of the following alternatives: •Questions of OD surveys may ask for trip duration or the choice of itinerary. But self-reported variables of this type are often not reliable. It seems difficult to draw clear conclusions using these data (Hanson 1995; England 1993; Gordon et al.1991).•Specialised activity surveys encompass trip scheduling of each household during long temporal intervals (generally a week). Despite its interest, this method goes to details that are not needed for our purpose. The data gathering work is too tedious when considering thousands of households. (Ben-Akiva and Bowman 1995; Doherty and Miller 1997).•Euclidean distances (from origin to destination points) are crude estimates of journey lengths. Used by many social scientists (Villeneuve and Rose 1988;Blumen and Kellerman 1990) arguing they show a close linear relation with route41length (Thomas et al. 1996), these estimates are not, however, sufficiently accurate when evaluating trip duration.•Private vehicles monitoring us ing GPS (global positioning systems) and data-loggers can track individual travel journeys with satellites. While this is a promising development, work is still in the early stages on issues of database overload and compatibility between GPS co-ordinates and geographical modelling of transportation network. For the moment, this is a costly option (Lee-Gosselin 1996).•Procedures integrating routing algorithms, GIS and behavioural criteria can be developed and later calibrated using GPS monitoring and/or activity surveys (Makin et al. 1997; Gärling and Gärling 1988; Golledge et al. 1994).2. Simulation needs and issuesThe last option, retained here, is a compromise between the calculation of Euclidean distances and the use of GPS or activity based surveys. OD data are used to estimate the most likely paths that minimise impedance costs for each commuter trip. This modelling procedure provides consistent estimates of journey duration and travelling distance using existing data. This is an absolute requirement to allow the retrospective study of the evolution of transportation within metropolitan areas.To be adopted by end-users (planners, tran sport analysts, economists, scientists), the proposed tool should be portable, user-friendly and accessible to small transportation agencies. The development of such decision support systems is one of the major challenges in the GIS community (Etches et al., 1998). They would exploit available OD data for the benefit of transportation agencies, businesses (accessibility assessment) and society as a whole (linkage among land uses and their effects on transportation).The main database used for this mobility analysis comes from the OD survey carried out by the Quebec Urban Community's public transportation corporation (STCUQ), in 1991. This survey (Table 1a) describes about 111,224 trips related to 50,808 persons (8% of the total population) living in 20,796 households. The geographical database of the road network (Table 1b and 1c) for the metropolitan area was topologically structured (Thériault et al. 1995); it contains 52,538 street segments (directional links) and 19,249 nodes.Generating 111,224 minimal cost paths to estimate travelling time and distance of each OD trip involves methodological and technical issues. Literature dealing with the shortest path calculation is well developed and efficient solutions have been put forward (Adamson and Ti ck 1991; Khoong 1993; Pearn et al. 1994). A classic solution, based on Dijkstra's algorithm, is already implemented in many GIS but requires, in the worst conditions, V2 steps (V = number of nodes) to reach a solution (Sedgewick 1990). Generating the 111,224 individual routes from the STCUQ OD survey could take 4.12 x 1013 (111,224 x 19,2492) steps. Even with a powerful computer system, that can mean days, probably weeks, of computing.On the other hand, to generate the most probable route in a network, knowing only the origin and the destination, one need to consider all possible network configurations for any transportation mode in the entire urban area: private cars, public transportation (bus routes and schedules), bicycle, pedestrian, etc. The value of expected results will mainly reflect the quality and completeness of the network database used for the42calculation and impedance specification. For the Quebec network, this means adding an impedance coefficient to each of the 52,538 road segments to reflect travelling resistance according to road type (highway or local road for instance). This also implies providing a table in the network database for the identification of prohibited turns and for penalties related to moves at intersections. Furthermore, the OD pairs must be located in space and linked to the nearest road for route computation.Table 1 OD survey and road network tables structure(a) OD Trips Origin Destination Survey Trips (111,224 records in the 1991 OD survey)Field Format Step Content (units/procedure)[software]TripId Integer OD Unique ID for each OD survey trip PersonId Integer OD Unique ID for each respondent Origin_Pcode Char*6 OD 6 digits Canadian postal code at thestarting point of the tripDestin_Pcode Char*6 OD 6 digits Canadian postal code at theending point of the tripMode Integer OD Transportation mode {car; bike ... } Purpose Integer OD Trip purpose {work; shopping ... } Expansion Integer OD Expansion factor (computed foreach municipality by respondents'age group and sex to estimate ratiosbetween census counts and the ODsurvey respondents; used to expandOD trips to the total areapopulation)Origin_Lat Real PA Latitude of the origin (degrees) Origin_Lon Real PA Longitude of the origin (degrees) Destin_Lat Real PA Latitude of the destination(degrees)Destin_Lon Real PA Longitude of the destination(degrees)Origin_Node Integer NA Road network node (excludinghighways) nearest to the originlocationDestin_Node Integer NA Road network node (excludinghighways) nearest to the destinationlocationTravel_Time Real RS Total modelled travel time by car onthe road network (minutes)Route_Length Real RS Optimal route length (kilometres)43(b) Road Links Road Network Links (52,538 records in the 1988 road network)LinkId Integer RD Unique ID for each road linkLinkDir Char*2 RD Road link direction {AB : forward; BA :backward}Road_Name Char*40 RD Street/Road nameFunctional Integer RD Functional class {street; local road; major road;regional road; national road; highway; highwayexit}Speed Integer RD Road link speed (kilometers per hour) [seeTable 3]Length Real RD Road link length (metres) [MapInfo]Time Real RD Road link travel time (minutes) [MapInfo;Length*60/Speed*1000]Start_Node Integer RD Starting node [TransCAD]End_Node Integer RD Ending node [TransCAD]Traffic_Count Integer RS Traffic count; sum of Expansion for everyindividual OD route using the road link (personstravelling on the segment during a typicalweekday)(c) Road Nodes Road Network Nodes (19,249 records in the 1988 road network)NodeId Integer RD Unique ID for each network nodeLatitude Real RD Node latitude (degrees) [TransCAD]Longitude Real RD Node longitude (degrees) [TransCAD]Functional Integer RD Maximal Road link functional class connected to thisnode {street; local road; major road; regional road;national road; highway; highway exit} [MapInfo;using geometric intersection with road links](d) Postal Codes 6-digit Canadian Postal Code Locations (23,126 records in 1991)(from Statistics Canada PCCF ; checked using Canadian Postal Corporation maps and the road network) P_Code Char*6 PC 6-digit Canadian postal codeLatitude Real PC Postal code latitude (degrees)Longitude Real PC Postal code longitude (degrees)The geographical location of OD pairs uses Canadian postal codes (Table 1d), allowing resolution to the block face level (generally < 100 metres from real position) with 23,126 postal code locations.Such geographical detail implies using GIS to manage spatial data, to update the road network, to operate the selection of the best route and to check for data correctness. To reduce processing time and to design a tool that could be run on a relatively cheap system, reasonable criteria sets and route computing procedures must be developed and/or integrated into the GIS package using their extension development languages. That is the specific purpose of this paper. We implement a modelling procedure for the Quebec region 1991 OD survey, using currently available commercial GIS packages running in conjunction with Windows 95, in order to test the feasibility of this approach with current technology and t o evaluate its operational costs (processing time and/or4445 money).3. Modelling and simulation procedureThe modelling procedure is divided into sixconsecutive steps shown in Table 2. Figure 1presents a general data processing flow chartmaking use of various software packages torelate and mutually enrich the four base tables.The first three steps are devoted to datagathering from multiple source documents.These data are often already available formany urban regions in North America andneed only to be checked for their suitabilityand correctness. For the Quebec region, it wasdecided to rebuild or check the entire databaseto deliver maximum quality (cost estimates areprovided in Table 2).Figure 1 Data processing and simulationflow chartThe first step (RD) was devoted to editing and building of a topological road network using 1:20,000-scale topographical maps (Figure 2). This accuracy level is mandatory to ensure future compatibility with GPS technology. This is a huge task that can be done using powerful GIS packages, like Arc/Info running on Unix platforms. For our project, in order to minimise equipment costs, we developed an add-on application (MapLogix) running in conjunction with MapInfo (MapInfo Corporation 1996) for Windows 95. It is now commercialised (Korem 1998). In a computerised road network, each link must contain appropriate identification and labelling of road segments (network links; Table 1-b ) and street intersections (networks nodes, Table 1-c ). Some links are unidirectional: this information was added to road segments using a custom -made tool programmed in MapBasic (MapInfo Corporation). To simulate the real world, each road segment (link) must be characterised by the speed it allows for various transportation modes (here we retain only private cars) and penalties may be specified for various movements at intersections (nodes). Adding exact information for each of the 52,538 road segments and 19,249 nodes in the network is nearly impracticable. Therefore we decided to use the functional classification of roads provided by the Quebec provincial Ministère des transports, adding three supplemental local criteria to enhance the local context?s impact on travelling speed (Table 3 and Figure 4). These criteria are compatible with legal speed limits and were implemented using MapInfo's Geo-SQL and updating capabilities. Together, they distinguish between highways, highway interchanges, rural and urban roads, and local streets with or without nearby elementary school. For the seek of simplicity, the intersection penalties were specified globally for the entire network using the appropriate option of TransCAD (Caliper Corporation 1996), the GIS software retained to model the route choices. This is not an absolute restriction, since TransCAD allows for many other methods, including site specific penalties. This set of criteria provides a realistic basis for simulation of route choices, matching the average behaviour of individuals travelling across the city (they minimise theirtravel46 time while avoiding complex paths). For the Quebec region, we do not consider road congestion, postulating that it seldom happens, due to the high density of its highway network.Figure 2 Road network modelling Table 2 Modelling procedure steps Step NameProcedure [software] (time and/or cost) RD Roadnetworkcreation Topological structuring of road links from 16 topographical 1:20,000 map sheets [MapInfo-MapLogix] ; Manual assignment of road directions, functional classes and names [MapInfo] ; Road networkcreation [TransCAD] (computer assisted procedure ; 32 weeks ;approximate cost 35,000 CAN$)PC Postal code location Assign and check latitude and longitude co-ordinates for each 6digits postal code in the region [MapInfo-MapBasic] (computerassisted procedure; 10 weeks; cost about 6,000 CAN$)OD OD survey Phone survey (computer assisted procedure involving 30 operators ;8 weeks ; cost 250,000 CAN$, including phone calls) [Access-MapInfo]PA Postal code assignmentAssign postal code location (latitude and longitude) to each ODstarting and ending points [MapInfo] (13,148 locations ; 25 minutes) NA Nearest node assignmentAssign nearest network node (excluding highway nodes) to each tripstarting and ending points [MapInfo-MapBasic] (75 minutes)RS Optimal route search Find the optimal route (minimising travel time) for each OD tripusing the road network and table 3 criteria; update the OD trips table with travel time and route length ; update the road network links withtraffic counts [TransCAD-GISDK] (722 minutes for route simulationand 9 minutes for road traffic updating)The second step (PC) improves the geocoding (providing geographical co-ordinates of the starting- and ending-points of trips). In Canada, the postal code is used to locate individuals and households in space. In urbanised areas it provides location at the block face level. Statistics Canada maintains a conversion file (PCCF) that associates geographical co-ordinates (latitude and longitude) to each 6-digit postal code. Thus, the 6-digit postal code was retained to indicate every position within the OD survey (Figure 3). However, the precision of Statistics Canada's location is insufficient and incompatible with our accurate road network. Some postal code locations were even found in the middle of the Saint-Lawrence River at hundred of meters from any land. It was then decided to check the location of every postal code in the region using maps published by the Canadian Postal Service Corporation to put them in the appropriate street block (Table 1-d).Figure 3 Location of the postal codes on the roadmapFigure 4Assignment of maximum speed to everyroad linkThe third step (OD) implies the creation of a trip information table from the OD survey. Examples of necessary information fields coming from that operation are tagged with the "OD" label in the "Step" column of Table 1-a. Remaining fields in this table are to be filled during upcoming data processing steps.The fourth step (PA) associates geographic co-ordinates coming from the postal codes location table to the starting- and ending-points of each trip (Table 1-a). This operation can be undertaken with any software that implements SQL join operations. However, GIS capabilities are needed to use latitude and longitude in order to generate point features that are needed at the next step, so it was appropriate to use MapInfo to handle this task.The next step (NA) uses these point locations to find the nearest node in order to establish a geometric link between the OD survey and the road network. Despite that TransCAD provides an automatic fun ction to handle this task, linking each point to the nearest node, it was decided to implement it in MapInfo, using a custom-tailored MapBasic program, in order to avoid increasing the complexity of the network resulting from several simulations. This program uses the buffering functions of MapInfo to select the nodes at increasing radial distance from every point, retain the nearest one and update the appropriate field of the OD trips table (Table 1-a), using its identifier. To prevent users from entering the network through an highway connector, these specific nodes were47excluded from the table before node assignment. The Geo-SQL functions of MapInfo were extremely efficient to aggregate the "Functional" field of road links (Table 1-b) in order to qualify each node using the maximum value of every connected link (Table 1-c).Table 3 Speed and turn penalty assignment criteria for modelling of private carroutes(a) Speed Criteria used to assign speed to each road link in the networkFunctionalclass Additional criteria Speed(kmperhour)Street within 150 meters from a primary school(>=100 pupils)30 Street at more than 150 meters from a primary school(>=100 pupils)50Local road in urban areas and within 150 meters from a primary school (>=100 pupils)30Local road in urban areas and at more than 150 metersfrom a primary school (>=100 pupils)50Localroadin rural areas 70Majorroadin urban areas 50Majorroadin rural areas 70Regionalroadin urban areas 70Regionalroadin rural areas 90Nationalroadin urban areas 70Nationalroadin rural areas 90HighwayexitRamps, exits, entrances, etc. 65Highway High speed divided lanes 100(b) Turn penalties Global criteria used to assign time penalties for specificmovements at each network node using TransCADMovement Timepenalty(minutes)Turn left 0.4Turn right 0.2Through 0.1U-turn prohibited48Figure 5Finding optimal routes using TransCADFigure 6 Adding trip location and statistics to anO-D survey tableFinally, the last step (RS) uses TransCAD functions to find the optimal route for each OD trip (mainly the ShortestPath procedure). However, despite that TransCAD provides a very efficient user-interface to model trips directly on the screen (Figure 5), pointing locations on the network, and to model the entire matrix of routes between two sets of nodes, there is no function to handle a set of nodes taken from a file or a table. With thousands of routes to model, the first operation mode (pointing on the screen) was impracticable. The nodal matrix was also rejected because it implies building the entire 19,249x19,249 matrix to retain a mere 111,224 actual routes, rejecting 370,412,777 remaining cell results. Overload on resources (estimated at many weeks of processing time with a 200 MHz Pentium, needing more than 6 Gigabytes of disk space for storage) would clearly exceed any PC's capabilities for a while. Once again, it was decided to build a macro program using the GISDK (Caliper Corporation) language running in conjunction with TransCAD (Figure 7). This macro establish a direct link between the OD trip table, providing the route beginning- and ending-nodes of each journey, the road network and the criteria set (penalties, fields to minimise and update) to model the requested paths. These paths are then measured in length and travelling time to update the OD survey table (Table 1-a and Figure 6) and, optionally, to accumulate traffic on every link of the network (Table 1-b).This last function is a side benefit: it does not slow down the procedure and implies only a small overload of about 10 minutes to record the traffic information for our entire network. The informatio n gain is very significant: it transforms an OD survey into traffic maps that can be used to model road congestion and, when calibrating a new network, to disclose topological errors, since an inappropriately connected or inaccessible link will generally return a null traffic. It is an error detection tool that has clear advantage over the tedious manual checking of every connection in a topological network. It can even be applied without an OD survey, by choosing starting- and ending-nodes at random.49Figure 7 Procedure to update the O-D table with tripdataFigure 8Estimated traffic during a typical weekday: Example for Limoilou, Fall of 19914. Empirical results and discussionThe main purpose of this project being to develop a tool adapted for small transportation agencies and low-funded research projects, it was decided at the very beginning to retain a PC platform using a conjunction of two low cost and widely available GIS packages, MapInfo and TransCAD, running on the popular Windows 95 or Windows NT platforms. These two packages are user-friendly and provide excellent interoperability features (ODBC, SQL relational principles, MapInfo interchange format to handle map and data transfers, ext ension through MapBasic and GISDK languages, etc.).Beyond specific simulations from our OD survey, the primary goal was to develop a procedure that can be re-used for various other purposes, such as modelling the time accessibility of services wi thin a city, comparing the efficiency of two transportation modes, etc. Processing times (based on a 200 MMX Pentium PC with 96 Megabytes of RAM) are reported in Table 2, and can be useful to estimate the feasibility on any specific project using that procedure. While refining our approach, early processing time expectations, expressed in days or weeks, became hours, and even, minutes. However, we experienced some performance problems with the TransCAD route simulatio ns. After some 80,000 routes had been found at a very impressive speed, the system performance gradually deteriorated showing excessive disk activity. After 90% of the overall modelling task was carried out in about 12 hours, activity reports displayed on the screen by our GISDK application indicated that about 1% of the remaining task took the next 10 hours. So, we decided to cancel the processing. The problem is probably related with overlays and data transfer between the RAM and the virtual memory that a ppears when the task is large and the available disk space becomes low. Thereafter, we decided to disable virtual memory swapping at the system level and to restart the application. The system performance then stay constant and the reported time of 722 minutes for route simulations appearing in Table 2 comes from this operation. Using memory swapping yields longer processing times, even for small tasks. TransCAD, as well as many other packages, seems relatively unstab le without virtual memory and it is highly advisable to reset the system after the simulation results are secured to disk.50。