# Routing Topology¶

Author: Stephen Woodbridge Stephen Woodbridge. The source code is released under the MIT-X license.

## Overview¶

Typically when GIS files are loaded into the data database for use with pgRouting they do not have topology information associated with them. To create a useful topology the data needs to be “noded”. This means that where two or more roads form an intersection there it needs to be a node at the intersection and all the road segments need to be broken at the intersection, assuming that you can navigate from any of these segments to any other segment via that intersection.

You can use the graph analysis functions to help you see where you might have topology problems in your data. If you need to node your data, we also have a function pgr_nodeNetwork() that might work for you. This function splits ALL crossing segments and nodes them. There are some cases where this might NOT be the right thing to do.

For example, when you have an overpass and underpass intersection, you do not want these noded, but pgr_nodeNetwork does not know that is the case and will node them which is not good because then the router will be able to turn off the overpass onto the underpass like it was a flat 2D intersection. To deal with this problem some data sets use z-levels at these types of intersections and other data might not node these intersection which would be ok.

For those cases where topology needs to be added the following functions may be useful. One way to prep the data for pgRouting is to add the following columns to your table and then populate them as appropriate. This example makes a lot of assumption like that you original data tables already has certain columns in it like one_way, fcc, and possibly others and that they contain specific data values. This is only to give you an idea of what you can do with your data.

ALTER TABLE edge_table

SELECT pgr_createTopology('edge_table', 0.000001, 'the_geom', 'id');


The function pgr_createTopology() will create the vertices_tmp table and populate the source and target columns. The following example populated the remaining columns. In this example, the fcc column contains feature class code and the CASE statements converts it to an average speed.

UPDATE edge_table SET x1 = st_x(st_startpoint(the_geom)),
y1 = st_y(st_startpoint(the_geom)),
x2 = st_x(st_endpoint(the_geom)),
y2 = st_y(st_endpoint(the_geom)),
cost_len  = st_length_spheroid(the_geom, 'SPHEROID["WGS84",6378137,298.25728]'),
rcost_len = st_length_spheroid(the_geom, 'SPHEROID["WGS84",6378137,298.25728]'),
len_km = st_length_spheroid(the_geom, 'SPHEROID["WGS84",6378137,298.25728]')/1000.0,
len_miles = st_length_spheroid(the_geom, 'SPHEROID["WGS84",6378137,298.25728]')
/ 1000.0 * 0.6213712,
speed_mph = CASE WHEN fcc='A10' THEN 65
WHEN fcc='A15' THEN 65
WHEN fcc='A20' THEN 55
WHEN fcc='A25' THEN 55
WHEN fcc='A30' THEN 45
WHEN fcc='A35' THEN 45
WHEN fcc='A40' THEN 35
WHEN fcc='A45' THEN 35
WHEN fcc='A50' THEN 25
WHEN fcc='A60' THEN 25
WHEN fcc='A61' THEN 25
WHEN fcc='A62' THEN 25
WHEN fcc='A64' THEN 25
WHEN fcc='A70' THEN 15
WHEN fcc='A69' THEN 10
ELSE null END,
speed_kmh = CASE WHEN fcc='A10' THEN 104
WHEN fcc='A15' THEN 104
WHEN fcc='A20' THEN 88
WHEN fcc='A25' THEN 88
WHEN fcc='A30' THEN 72
WHEN fcc='A35' THEN 72
WHEN fcc='A40' THEN 56
WHEN fcc='A45' THEN 56
WHEN fcc='A50' THEN 40
WHEN fcc='A60' THEN 50
WHEN fcc='A61' THEN 40
WHEN fcc='A62' THEN 40
WHEN fcc='A64' THEN 40
WHEN fcc='A70' THEN 25
WHEN fcc='A69' THEN 15
ELSE null END;

-- UPDATE the cost infomation based on oneway streets

UPDATE edge_table SET
cost_time = CASE
WHEN one_way='TF' THEN 10000.0
ELSE cost_len/1000.0/speed_kmh::numeric*3600.0
END,
rcost_time = CASE
WHEN one_way='FT' THEN 10000.0
ELSE cost_len/1000.0/speed_kmh::numeric*3600.0
END;

-- clean up the database because we have updated a lot of records

VACUUM ANALYZE VERBOSE edge_table;


Now your database should be ready to use any (most?) of the pgRouting algorithms.