Optimal Count Locator (OCL) for Visum

i2 - Intelligent-infrastructure is proud to present its newest Visum add-on which tells you where to place counting locations in the transport model to get best results. Lets see how it works.

Idea

The quality of transport modeling depends, among others, on counting data. But who cares about quality of counting itself? We set up counting locations willing to catch as much flow as we can, yet how can we be sure that our location is best possible. Knowledge, and experience seems to be a good hint, but here we propose something more refined. Our tool employs acknowledged optimization technique to specify set of optimal counting locations catching as much flow and as many OD pairs as possible.

Study Case

We asked transport planning professionals to specify 10 best nodes to be counted in the city that they know very well (Kraków - PL). We compared their solutions to our algorithm results, and that’s what we got:

	modeler 5yrs exp	modeler 10yrs exp	Optimal Count Locator by i2
Flow detected	45.7%	50.6%	56.3%
OD pairs detected	37.2%	45.1%	57.0%

We see that even experienced transport planners, who know the city didn’t manage to cover as much flow and OD pairs as OCL. They detected almost as many flows as OCL, but OD pairs coverage was much lower. This experiment can give you a hint about what are benefits from using OCL

Product

We introduce the optimization procedure wrapped in intuitive, user friendly interface(see fig below), which can quickly find optimal solution even for complex networks.

User can define his budget (number of points that can be placed) and detectors which are already installed. It’s also available to determine what kind of detectors we want to install: junction, link, directed link, (it soon will be extended to cover also turns).

Additional technical parameter is algorithm depth, being number of paths between origin and destination that are taken into calculation process. For assignment generating numerous routes per OD pair setting this parameter low can make procedure faster.

We propose various strategies of optimization. In our opinion, and due to our tests, the most useful is mixed maximization of both OD pairs coverage and flow coverage, however you can choose to maximize only flow, or only OD pairs.

fig. intuitive user interface

Running time

Calculation time depends on size of the network. On the average up-to-date PC it takes about 1 minute to download 300 000 of paths (model for Kraków, Poland  of ca. 350 zones), and then time of optimization itself depends on number of connectors and takes roughly 5s per detector.

Results

Results are saved in your Visum network as Boolean, User-Defined-Attribute “i2_OCL_Detectors”, which equals 1 if it’s an object that should be detected

To see results visually, you can import prepared .gpa file. Additionally you can use our flow bundle generator, where you can clearly see which flows are covered with your detection.

For detailed results and statistics you can see report including OD coverage, flow coverage, keys of detected elements, calculation time, etc.

fig. input data - Visum model

fig. Statistics for obtained results

fig. graphical presentation of results: violet - counting locations, yellow - counted flow, gray - uncounted flow.

Further developments

The engine we proposed is flexible and extendable, thus it can be suited for personal needs, or extended to new functionalities:

• Transit - soon we will try to extend our functionality to cover also PuT, and define set of stop points, or lines to be surveyed.
• Plate scanning – our partners ask us to provide tool to define optimal plate scanning locations. Actually that’s on our road map, however this task is much more complicated, and we will need to spend some hours thinking on how to solve it.
• Vehicle floating data – the engine we proposed is capable to define optimal trajectory of VFD to get as much details as needed.

Sales

OCL (Optimal Count Location) is ready to buy Visum add-on, available straightaway at intelligent-infrastructure. We offer competitive price for a product that gives you significant savings in modeling. We also provide service, where you send us your visum file and we simply calculate the results that you want.

See you at: www.intelligent-infrastructure.eu

Rafał Kucharski

How can we connect network with zones in Visum - review of options + i2 connector balancing method

Hi, 

I'd like to report here on what options do we have to connect Visum network. There are numerous ways available in Visum, and they can significantly alter modeling results.

 Now let me describe you the basic options provided, and the script written by i2, further extending basic capabilities. 

Basic info on how to model connectors can be found in Visum Manual, and the scheme of available options is shown below (fromVisum manual):

  See the results for various options below: 

1. Default 

if we do not change default setting, the traffic will start path searching at the zone centroid, and will use shortest connectors in shortest path search.

As we can see on the sample below, inner links of the network are empty, due to the fact that all of assigned traffic used connectors, which are optimal in shortest path search during assignment. This will happen if our connectors are “faster” than links. Also, traffic volume of single OD pair in most cases will use just one connector, which can be unwanted outcome.
When we use this method with multiple connectors we will most probably struggle to balance the network to reflect actual traffic from the zone.  Personally, It's hard for me to tune connectors' impedance in Visum (You don't have capacity as for links, you can only tune travel times)

Also, such a model will probably cause no significant harm in dense, urban model, where zones are relatively small, but imagine that your zone is a region in regional model, where zones are much bigger. The model below will drastically bias traffic resulting to underestimating inner traffic, etc.

Also one can notice that trip destination distribution at connector heads are different for each node (head).

fig. 1 Network with 5 zones -one in center,and foru at the sides. Red color is for links, and blue color is for connectors. 

2.      Regard connectors as shares – Standard

This option tries to balance Volume of each connector, regardless OD of traffic on it. Visum achieves it via “dummy” capacity restrain where impedance is calculated according to virtual capacity. Unfortunately we cannot save those impedances, so the connectors volumes can be different when we slighlty change network (see the last paragraph).   

We can see that all connectors are used by traffic, and volumes are comparable, however results are various (Vol min: 319,  Vol max: 526). Probably we could obtain more balanced result if we used higher travel times for connectors (to influence path search results).

With this option, distribution of trip destination at connector heads is still different for each node, but the results are slightly more balanced.  

fig. 2 Network with standard Visum connector balancing procedure (weights = 1)

3.       Regard connectors as shares – Each OD Pair

This option lets us obtain balanced assignment, where each connector has exact portion of traffic calculated due to its weight (here all connectors have weights equal to 1).

Additionally, at each connector ending point we have the same trip distribution, so that executing flow bundle will give similar results for each connector.

It's my favourite choice, andgives expectional results, however we need to remeber, than it significantlyincreases calculation time, as each connectors is regarded as a new virtual zone. So if we have network of 500 zones, and each zone has 10 connectors, than this option will increase dimension of calculation matrices from 500x500 to 5000x5000 , so that the thing to remember! Also it can exceed Visum licence for zones and outcoming error is yet unhandled as far as I'm concerned.

fig. 3 Network with Visum connector balancing procedure for each OD pair (weights = 1)

4.      i2 balance

This is result of script I have written to balance connectors in the network.

It gives similar results to standard “regard connectors as shares” with capacity restrained connectors, and it has similar logic of balancing.  However, I’ve written it because:

a)  now I’m be able to save connector travel times giving balanced results. In Visum the impedance of connectors is not stored in the network, it’s simply saved as assignment result, so when you want to test new scenario, assignment of the traffic to the connectors can be different. Now I wanted it to be constant and fixed for basic scenario, and that’s how I achieved it (for more info contact me at info@intelligent-infrastructure.eu).

b)  I didn't want to use regard connectors as share, as it increased my calculation time significantly.

c)  I wanted to test quick convergence methods, and statistic based regularity measures. 

fig. 4. Results of procedure developed by i2 tobalance connectors - results are similar to fig. 2 however can be stored to keep assignment results.

Transit Network Design Problem for “monocentric” network solved by means of poli-criterial genetic optimization method.

Summary:

Paper shows an approach to solve Transit Network Design Problem. Considered problem covers regional transport system (Lublin region in Poland). Input data were GIS transport network and population distribution. Complex optimization problem was simplified by means of graph theory methods. Final optimization problem was poli-criterial genetic algorithm. Result of solving problem was Pareto frontier, being a set of non-dominated solutions. Optimization process was continuation of Visum Zone definition described here.

Background: 

I got GIS database consisting of:

·        Location of  place with information about their population (fig.1)

·        Transport network (roads + railway) (fig.2)

·        Administrative division (zones) (fig.1+2) (each zone was about 50k inhabitants, 2k km²)

I presented the network as a graph consisting of 82 edges: 

fig.3

Method:

I solved poli-criteria problem of Network Layout Optimization. Two contrary criteria were:

1)     Operator cost minimization criteria: Total network length (km) and

2)     Passenger Cost minimization criteria: Total passenger kilometers (paskm) represented via two separate criteria:

a.     Travel times to get co central points of the network

b.     Overall accessibility, being DistanceMatrix x OD Matrix ^(-1) (reciprocal was employed to transform criteria into minimization)

Decisive vector was 82 element Boolean vector. Each element of vector was reflecting graph edge.

I solved problem using Multi-objective Genetic Algorithm, minimizing three given criteria. Result was Pareto Frontier. Pareto frontier final population is shown here. Additional criteria being standard deviation of accessibility is proposed:

Nuber In Pareto final population (Lp)	Passenger cost 1	Operator Cost	Passenger Cost 2	Additional Criteria
	Passenger kms[1000 paskm]	Network Length [km]	Accessibility [pop./km]	Standard Deviation of Accessibility for Zones
8	161 000	1 218	732 902	99,3
22	161 000	1 282	733 704	99,3
10	161 000	1 276	733 447	99,3
28	128 000	1 423	723 114	66,2
2	122 000	1 851	640 084	62,8
20	123 000	2 241	653 834	63,7
15	122 000	2 457	667 836	62,8
1	133 000	1 624	814 889	71,1
23	132 000	1 707	823 710	67,5
19	126 000	2 400	882 689	68,2
27	121 000	2 700	900 210	59,6
17	121 000	3 521	921 467	59,6
21	136 000	2 445	886 533	72,6
18	122 000	2 556	900 101	62,8
7	122 000	2 898	908 254	62,8

 Pareto frontier for two criterias can be seen here:

Network diagrams for selected solutions are shown here:

network no 8

network no 17

network no 22

Conclusion:

User friendly tools combined with good quality of input data can perform much more than you expect with basic transport models. Built-in optimization for tranpsport modeling - sounds good.