The methods have been tested on several different problem instances, based on OpenStreetMap-data, obtained from the Internet. See  for details of the data extraction procedure. The networks cover smaller cities around Linköping, and also different parts of Linköping.
A certain filter was applied to the OSM-data, leaving only streets (highways) with the following label: “motorway”, “trunk”, “primary”, “secondary” and “tertiary”, but leaving out “road”, “cycleway”, “living_street”, “pedestrian”, “footway”, “path” and “residential”. These instances are thus based on real life networks, with real life distances, but with certain links removed, and nodes with degree two eliminated by simply adding the two adjacent links into one, summing up the costs. Therefore, the curvature of the link is not visible, but the distance is correct.
We have, for practical reasons, divided the set into three parts, depending on the size. The first part contains networks with less than 200 nodes. They are rather small cities or areas, and give rather easy problems. The second part contains networks with between 200 and 400 nodes. These problems are a bit more time consuming to solve. The third part contains the most difficult problems, networks with more than 400 nodes.
In Table 1, we give the number of nodes and links, the total distance of all the links (i.e., the total distance to be cleared from snow), the average node degree, and the number of inhabitants for the cities represented in the test set. For the examples based on parts of Linköping, no number of inhabitants can be specified. (The whole of Linköping has around 140,000 inhabitants.)
Pictures of some of the networks are given in Figs. 6, 7, 8 and 9.
In Fig. 1, we show a preliminary run with Snowplan. In the graph at the bottom of the picture, the blue line denotes the actual objective function value for each iteration, the green cross denotes the objective function value after the improvement procedure, and the dashed red line denotes the best objective function value obtained up to that iteration. The light blue horizontal line denotes the lower bound.
In the top of the picture, one can see the parameters that are possible to change, and their current values. At the top left, the total time for each vehicle is shown. There one can identify the vehicles that takes the longest and the shortest time, and may consider moving links between them. In this example, one may consider moving links from vehicles 1 and 2 to vehicles 3 and/or 4.
In the middle green part, the best objective function value is shown, together with some more information, such as at which iteration the best value was found, and the lower bound.
In Fig. 2, we show how the network and allocation are brought into Vineopt. This allows single links to be changed in Vineopt. The resulting allocation can then be saved and used as starting solution in Snowplan.
In , we present preliminary tests, made to find interesting values of the parameters. (More parameters and values are tested than presented here.) One should remember that the method contains randomness, so all results should be regarded as approximate. In any case, in these tests, the best setting seems to be the following: MD 1, RS 1, SV 5, MV 2, IV 1, ChV 3, II 7, ST 1000, RC 0.3. In words: Mark passed streets done, revise allocation after this, start with k-means, put border links in the highest number set, move a link from a vehicle that does most to one that does least, try all combinations of moving cycles, swap the most and least used vehicles, try to move a cycle from an expensive tour to a cheap one, try once for each pair of vehicles. In simulated annealing, do 7 interior iterations (with the same temperature), use start temperature 1000 and cooling factor 0.3. An observation is that these parameter settings make the method act more like greedy heuristics than metaheuristics, i.e., one searches for the best improvement in every step, and does not do random changes and leave the optimization to the metaheuristic. The reason is probably that each iteration is rather expensive, so we do not have time to do as many iterations as one would prefer in a metaheuristic.
We have chosen a number of interesting settings, i.e., variants of the method to try more. They are shown in Table 2.
We will also use the notation Ak, Bk, etc., which denotes setting A with k iterations and so on. For the setting A1, B1 etc., the method becomes a one-shot heuristic. If the starting solution is very good, the succeeding changes may not give much improvement, and the question is how many iterations one should spend on trying to improve the solution.
Tests of one-step methods
In , we give results for the settings with only one iteration, followed by one round of improvements. We use four vehicles, and find that the times are very reasonable.
We find that the settings K1 and L1 give bad solutions, while good solutions are obtained by several other settings. Some solutions are actually close to the lower bound, but most are not very close. Setting E1 gives the best solution for 8 instances, followed by G1 and C1, both giving the best for 5 instances. A conclusion is that one cannot be sure of good results using only one iteration.
Tests with 30 iterations
In several tables in  we present detailed results of our main tests with the chosen settings, A–L, using 30 iterations. In Table 3, we give the best and the worst of the results. Checking how many times each setting gave the best objective function value for \(q=4\) and 30 iterations, we get the following: A 8, G 6, B 4, C 4, E 4, F 4, D 2, H 1, and the others zero. The randomness makes it hard to pick one “best” setting, but here A seems to be a good choice, since it gives the best solution for eight problems.
Times are obviously longer here than with one iteration. However, it is still possible to use the method, from a practical perspective, as it is much faster to use this tool than to do it by hand.
In Table 4, we investigate the setting A30 more thoroughly, by giving the results together with lower bounds and relative errors. The quality of the lower bounds may vary between instances.
Different number of iterations
In Table 5, we give the results for setting A with 1, 5, 30 and 100 iterations. The question here is the value of continued iterations. Since the methods contain randomness, we see cases where more iterations give a worse solution. That will obviously not happen within the same run.
Times grow almost linearly with the number of iterations. As there can be several iterations without improvement of the objective function value, improvement of the objective function value is not very regular. Usually, doing 100 iterations gives better solutions than doing 30 or less, so it is mainly a question of how much time one wants to spend.
Tests with more vehicles
We have also done test with more vehicles. In , we present tests with methods A30–L30 and \(q=5\). The number of best objective function values are the following: E 10, G 6, C 4, D 3, F 3, A 2, B 1, I 1, and the others zero. The worst objective function values were given by settings K and L. The minimal times, however, were given by K and L, and in a few cases G and I. The solution times for the first group is between 1 and 10 s, for the second group between 7 and 47 s and for the third group between 33 and 772 s. Picking a winner is not easy, but E and G could be candidates.
In Table 6, we present the tests with methods A30–J30 for six vehicles for the larger networks, as we believe that one would not use that many vehicles for smaller areas. Picking a winner here is even harder, but method I is quite fast, while the best results were found by C 3, A 2 and G 2.
Different numbers of vehicles
We have solved a couple of problems for different numbers of vehicles, from one up to eight, and then added a fixed cost for each vehicle. The results are reported in Table 7 for equal weights on time and cost, and 8 for weight on time twice the weight on cost, i.e., when it is more important to remove the snow quickly. We used settings A30.
The time for clearing obviously decreases when the number of vehicles increase, but the vehicle cost increases. One can then find a minimum of the total cost.
For equal weights on time and cost, we find that for Mantorp the total cost is minimized for four vehicles, while also six is good. For Åtvidaberg, four, five or eight vehicles seem to be best. For Vadstena, which is a somewhat larger city, the cost is minimal for eight vehicles. Again we recall that the methods use randomness, so one should not put too much trust in small differences. Perhaps the best conclusions of these tests are that one should not use less than three vehicles in Mantorp and not less then four in Åtvidaberg and Vadstena.
For a larger weight on time, we find that the minimum for Mantorp is found at six vehicles, for Åtvidaberg at six vehicles and for Vadstena at eight vehicles.
We see that the weights on cost versus time are important. Increasing the weight on time (i.e., that the snow is removed quickly) will increase the number of vehicles needed for the minimal total cost. Obviously, using this tool for a certain city, the authorities/users should put some effort in estimating the best values of these weights.
Estimating the fixed costs for vehicles may be rather difficult, since we are comparing investments for many years with daily cost of operations. We will look more at this question in the future. For now, the fixed costs are not much more than guesses, but we note that they give reasonable numbers of vehicles in our tests. The results in this paper are just an illustration of how our methods can be used to dimension the fleet for a certain area.