A method of predicting a traffic behaviour in a road system

Abstract

The invention relates to a method of predicting a traffic behaviour in a road system, comprising the following steps carried out by at least one processor (9, 11, 14, 17) connected to a database (7, 12, 16), which contains a set of traffic profiles (6): clustering the traffic profiles (6); for each cluster (CLi), determining a dissimilarity measure (D); receiving a request (Req) having one or more request tags (RT); checking whether all request tags (RT) match one of the characteristic vectors (CVi) of the clusters (CLi), and if so, outputting a predicted traffic behaviour (PTB), else, eliminating one of the request tags (RT) from the request (Req) and returning to the beginning of said step of checking.

Description

A Method of Predicting a Traffic Behaviour in a Road System The invention relates to a method of predicting a traffic behaviour in a road system on the basis of a set of traffic profiles, each of which represents a traffic measure of vehi- cles in the road system recorded over time, wherein one or more pre-defined tags associated with a time of recording of the specific traffic profile is / are attributed to said traffic pro- file. The invention thus concerns the field of measuring and evaluating vehicle traffic behaviour, for example traffic be- haviour on a main street of a city. Once the traffic behaviour on this street has been analyzed over an extended period of time, typically over a year or longer, the aim is to estimate 15 the traffic behaviour for a certain day or time-window in the future. This can be used to predict which road will be con- qested or blocked at a certain time, e.g., for freighters plan- ning the transportation of cargo or families planning their va- cation. Depending on the predicted traffic behaviour, different routes or times at which to travel on this street can then be chosen, whereby in any case the start-to-end journey time for a vehicle can be reduced. To this end, known methods of traffic prediction use a similarity clustering of the recorded profiles and an assigning of characteristic vectors ("labels") of tags to the clusters, which tags can be queried to identify a cluster of traffic pro- files as a predicted traffic behaviour for a certain day, e.g., a specific weekday, a "rainy" day, etc. Weijermars, van Berkom: "Analyzing highway flow patterns using cluster analysis", IEEE Conference on Intelligence Trans- portation Systems, September 13 - 16, 2005, shows a method for analyzing traffic patterns. Herein, 118 traffic profiles have been recorded for a highway, each over a time-span of 24 hours. Thereafter, the traffic profiles have been clustered by means of a standard clustering algorithm. After manually labelling the clusters, deviations within the clusters were evaluated. Furthermore, in the state of the art it is known to take a standard traffic behaviour and extrapolate the traffic behav- iour for a short term forecast by determining the current de- viation from the standard traffic behaviour. This method is known as parametric regression and yields a 15 minute forecast. Thus, there is a need for a reliable long term traffic prediction method. The method should yield results even with computers having low computational resources such that the method can be used on mobile phones and the like on the go. The invention therefore sets its aim to create an improved method for predicting traffic behaviour. To this end, the invention provides for a method of pre- 15 dicting a traffic behaviour in a road system, comprising the following steps carried out by at least one processor connected to a database that contains a set of traffic profiles, each traffic profile representing a traffic flow or a different traffic measure of vehicles in the road system recorded over time, one or more pre-defined tags associated with a time of recording of the respective traffic profile being attributed to said traffic profile: clustering the traffic profiles with their tags into at least two clusters as to similarity of traffic profiles; assigning at least one characteristic vector to each clus- ter based on the tags in this cluster, wherein each character- istic vector contains a tag or a combination of tags of said cluster; determining which cluster comprises the most traffic pro- files and setting this cluster as a reference cluster; for each cluster, determining a dissimilarity measure of this cluster with respect to the reference cluster and assign- ing the dissimilarity measure to all characteristic vectors of this cluster, wherein the dissimilarity measure is a measure of how much the traffic profiles of a cluster differ from the traffic profiles of the reference cluster; receiving a request having one or more request tags; checking whether all request tags match one of the charac- teristic vectors of the clusters, and if so, outputting a predicted traffic behaviour based on the cluster with said matching characteristic vector, else, eliminating one of the request tags from the request and returning to the beginning of said step of checking; wherein the request tag to be eliminated is chosen by de- termining which of the characteristic vectors corresponds to each request tag and choosing the request tag whose correspond- ing characteristic vector has the lowest dissimilarity measure. 15 The method of the invention processes a request which can be easily formulated by choosing appropriate tags. For example, if a user wishes to predict the traffic behaviour for a Monday in July, and he knows that this Monday will be a holiday, he can formulate the request by means of the tags "Monday", "July", and "holiday". The method then uses an elimination al- gorithm which provides a minimal number of steps to find the closest matching cluster for said request. The prediction method of the invention is based on the in- sight that the cluster with the highest number of traffic pro- 25 files represents an average traffic flow in the road system. Tags in the request that are very peculiar, i.e., correspond to clusters that are very dissimilar to the cluster with the larg- est number of traffic profiles, are favoured and are thus less likely to be eliminated. Based on this principle, the method comprises a loop in which the least interesting tags are suc- cessively eliminated until the request corresponds to a charac- teristic vector of one of the clusters, which can then be used to predict a traffic behaviour therefrom. The method can be further refined by also taking into ac- count combinations of the tags of the request. To this end, when choosing which request tag is to be eliminated from the request, it may also be checked whether a combination of re- quest tags corresponds to a characteristic vector, and if so, and if this characteristic vector has the lowest dissimilarity measure amongst the characteristic vectors corresponding to all request tags or request tag combinations, said tag combination is disregarded until a tag is eliminated from the request. By means of this, the accuracy of the prediction can be enhanced while the computational effort is not substantially increased. Even though the loop might be repeated more often, no loop-in- loop situation occur so that computing requirements remain low. The dissimilarity measure can be obtained in a number of ways. Preferably, the dissimilarity measure of a cluster is ob- tained by comparing an average traffic profile of said cluster 15 with an average traffic profile of the reference cluster. Here, the term "average" also includes weighted averages. Alterna- tively, instead of an average also a modal or median value can be used. In this way, the most significant (deviated) traffic profile of one cluster will be compared to the most significant (deviated) traffic profile of the reference cluster. The step of comparing can be done in a number of ways too, for example by calculating L1 or L2 norms between the profiles to compare. There are two alternative embodiments when determining which characteristic vector corresponds to a tag or tag combi- nation of the request. In the first, "one-to-one equivalence" embodiment, a characteristic vector corresponds to a request tag or request tag combination if the characteristic vector only comprises this request tag or request tag combination. This has the advantage that fewer characteristic vectors are found as corresponding characteristic vectors, which enhances computational speed. In the second, "inclusive equivalence" embodiment, a char- acteristic vector corresponds to a request tag or request tag combination if the characteristic vector comprises this request 35 tag or request tag combination either alone or in combination with at least one further tag. This has the advantage that more options are available, which increases the reliability of the method and prevents "rare", important tags to be eliminated too soon when they do not have a strict equivalent characteristic vector. To further enhance the reliability of the method, a sig- nificance value of each characteristic vector of each cluster is calculated and, when two or more characteristic vectors cor- respond to a request tag or request tag combination from the request, the characteristic vector with the lower significance value is disregarded. This is available for both aforementioned alternative embodiments and prevents possible collision prob- lems as well as increases the accuracy due to the additional significance value. To further avoid collision problems of two or more corre- sponding vectors, i.e., if two characteristic vectors corre- spond to a request tag or a request tag combination, and both have the same significance value, if applicable, the character- istic vector of the cluster with the lower number of traffic profiles is disregarded. This is the safer option, but it is also possible to use the characteristic vector of the cluster with the lower number of traffic profiles so as to not discard relevant tags or tag combinations too soon. Sometimes situations may occur when a tag of the request does not exactly match any of the characteristic vectors of the clusters. This might mean that not enough data has been accrued to yield an exact result for this request. To still obtain the closest match with the available data, if in the step of elimi- nating no characteristic vector is found for a tag of the re- quest, the lowest dissimilarity measure is assumed for this tag. However, this also means that this tag of the request is likely to be eliminated early in the loop. In all embodiments of the invention, it is preferred that each traffic profile represents the traffic measure of vehicles in the road system over a time-span of 24 hours. Alternatively, time-spans of 6 hours, 12 hours or 18 hours can be used, too, especially when the traffic behaviour in certain hours of the day, e.g., night hours or rush hours, are substantially the same for all traffic profiles. Preferably at least one tag indicates a day of the week, a month of the year, a week of the month, a school vacation indi- cation, or a special holiday indication of said time of re- cording. Such tags can, e.g., be automatically generated by as- sociating an attribute of a calendar to a traffic profile. The calendar can be defined in advance, in real-time, or in retro- spect, and it is also possible to subsequently add tags to traffic profiles when they first occur in a request. Alternatively or additionally thereto, at least one tag indicates a road condition or a weather condition at said time 15 of recording. Such tags represent a physical measurement of en- vironmental data, which can be coded by the tag in advance, in real-time, or in retrospect. The invention shall now be explained in more detail below on the basis of preferred exemplary embodiments thereof with reference to the accompanying drawings, in which: Fig. 1 shows a schematic view of a road system; Fig. 2 shows a block diagram of databases and processing engines for performing the method of the invention; Fig. 3 shows an example of clusters and associated labels occurring at the clustering and labelling stages of the method of the invention; Fig. 4 shows a decision tree used to determine labels for clusters during the method of the invention; Fig. 5 shows a flow chart of the prediction stage of the method of the invention; and Fig. 6 shows an example of the elimination of tags from the request during the prediction stage of Fig. 5. In Fig. 1 a road system 1 with a plurality of roads 2 is depicted on which vehicles 3 travel in directions R. The road 35 system 1 is equipped with at least one traffic measuring device 4, which can be, for example, used for measuring traffic flow on a road 2 or on an intersection of roads 2. The traffic meas- uring device 4 may be mounted on a gantry 5 spanning the road 2 or may alternatively be mounted roadside. The traffic measuring device 4 can be embodied as any type known in the state of the art, e.g., as inductive loops, radar devices, light barriers, video processing cameras, or as wireless readers that read a radio response of so-called onboard-units (OBUs) carried by the vehicles 3. The traffic measuring device 4 can record the traffic flow on the road 2 directly, e.g., as a number v of vehicles 3 per time unit t, or it can record the number v / t of vehicles 3 travelling on a given section of the road 2 at a given instant in time, e.g., by counting the vehicles 3 in camera pictures of 15 said road section taken at regular time intervals. Instead of measuring the traffic flow, other traffic con- ditions on the road can be measured by means of different meas- urement values too, for example by recording an average speed on the road 2 at a certain point in time t or by measuring the travel time vehicles take to travel a section of the road 2. The traffic measuring device 4 records the traffic flow v / t - or equivalent measurement values as described above - per time t over a predefined time-span of, e.g., 24 hours as a traffic profile 6 (Fig. 2). Alternatively, shorter time-spans could be used, too, for example only the most interesting time- spans of, e.q., 6, 12 or 18 hours of a day. The traffic measuring device 4 records said traffic pro- files 6 over an extended period of time, e.g., day after day for a whole year or longer. A traffic profile can be made up of discrete samples, e.g., one sample each 5 min, 15 min, or each hour, or can be an at least partially smooth curve over time. In this way, each traffic measuring device 4 records a set of traffic profiles 6 for its road 2 or intersection of roads 2 and stores it in a database 7 via a data connection 8. A proc- essor 9 is connected to the database 7 via a connection 10 for further processing of the traffic profiles 6, as will be de- scribed in the following. Fig. 2 shows a clustering engine 11, which can be part of the aforementioned processor 9. The clustering engine 11 ob- tains traffic profiles 6 from the database 7 and clusters these traffic profiles 6 into at least one or at least two clusters CL1, CL2 ..., generally CLi. The clustering algorithm used in the clustering engine 11 can be of any type known in the state of the art, for example a hierarchical agglomerative clustering algorithm. To this end, the traffic profiles 6 might need to be pre-processed such that they contain, e.g., 96 time samples each at 15 minute intervals. Furthermore, filters can be em- ployed to deal with local anomalies occurring in the traffic profiles 6. As a result, the clustering engine 11 outputs clusters CLi, each comprising multiple traffic profiles 6 that are simi- lar to each other, to a database 12. This database 12 can be the same as the database 7 or a subset thereof. Furthermore, the clustering engine 11 can be controlled by means of a con- trol setting input 13 to adjust clustering parameters. After the traffic profiles 6 have been clustered to clus- ters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>, a labelling engine 14 is employed to assign a label <semantics>L1<annotation encoding="application / x-tex">L_1< / annotation>< / semantics>, <semantics>L2<annotation encoding="application / x-tex">L_2< / annotation>< / semantics>, ..., generally <semantics>Li<annotation encoding="application / x-tex">L_i< / annotation>< / semantics>, to each cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>, wherein each label <semantics>Li<annotation encoding="application / x-tex">L_i< / annotation>< / semantics> consists of at least one characteristic vector <semantics>CV1<annotation encoding="application / x-tex">CV_1< / annotation>< / semantics>, <semantics>CV2<annotation encoding="application / x-tex">CV_2< / annotation>< / semantics>, ..., generally CVi. The labels Li should reflect the contents of the clusters CLi as accurately as possible. The method steps performed by the labelling engine 14 will now be described in detail by means of Fig. 3, which shows four exemplary clusters <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics>, <semantics>CL2<annotation encoding="application / x-tex">CL_2< / annotation>< / semantics>, <semantics>CL3<annotation encoding="application / x-tex">CL_3< / annotation>< / semantics>, <semantics>CL4<annotation encoding="application / x-tex">CL_4< / annotation>< / semantics> output by the clustering engine 11. The first cluster <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics> comprises <semantics>N=100<annotation encoding="application / x-tex">N = 100< / annotation>< / semantics> similar traffic profiles 6, of which only four are shown in diagram 15 for ease of representation. Diagram 15 maps the time t on the horizontal axis and the traffic flow in vehicles per time v / t on the vertical axis. It can further be seen that each of the four exemplary traffic profiles 6 can have one or more, in the present example two to four, pre-defined tags T attributed thereto. The tags T attributed to a traffic profile 6 are associ- ated in some way with the time of recording said traffic pro- file 6. For example, a tag T can indicate a day of the week, a month of the year, a week of the month, a school vacation indi- cation, a special holiday indication, a road condition, or a weather condition at the time-span over which its traffic pro- file 6 had been recorded. The tags T can be attributed to the traffic profile 6 di- rectly at the time of recording by means of the traffic measur- ing device 4, at the database 7, or even after clustering at the database 12. To this end, the corresponding devices 4, 7, 12 can each comprise a clock, calendar, weather station, or any 15 means to receive environmental or road condition data. Alterna- tively, tags T can be attributed to the traffic profiles 6 in retrospect, for example by means of calendars of the databases 7, 12. Calendar, weather, environmental, or road condition in- formation can be attributed in retrospect, for example if a week or a month later information arises that the road on which the traffic flow has been recorded was damaged or under con- struction. Tags T can even be attributed to the traffic pro- files 6 during the step of labelling by means of the labelling engine 14, which can have its own calendar or data inputs for this purpose. Coming back to the specific example of Fig. 3, it can be seen that a first traffic profile 6 of the first cluster <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics> has the tags "Monday", "rain", "normal day (no holiday)", and "June". A second traffic profile 6 of this cluster has differ- ent tags T, here "Monday", "sunny", "normal day (no holiday)", and "July", and so forth. To extract a label <semantics>Li<annotation encoding="application / x-tex">L_i< / annotation>< / semantics> that most accurately describes a cluster CLi out of all the tags T of this cluster CLi, the la- belling engine 14 firstly calculates a significance value SV for at least some of the tags T within this cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>. In some embodiments, the significance values SV of all tags T of all traffic profiles 6 of a cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> are calculated, while in other embodiments significance values SV are calculated for only the most common tags T of the traffic profiles 6 of a cluster CLi. The significance value SV can be calculated by means of a Chi-square statistic. For example, Pearson's Chi Squared sta- tistic can be used if there are 5 or more traffic profiles 6, and an exact combinatorial method like Fisher's exact test can be used if there less than 5 traffic profiles 6. This yields a most accurate description of significance of an individual tag Τ. To evaluate if a tag T is in fact significant or not, the labelling engine 14 obtains a threshold value TH from a thresh- 15 old input 15. The threshold input 15 can be adjusted manually or digitally if it is connected to computer. If the signifi- cance value SV of a tag T within a cluster <semantics>CLi<annotation encoding="application / x-tex">\mathrm{CL_i}< / annotation>< / semantics> lies above the threshold TH, a characteristic vector CV; comprising this tag T is assigned to this cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>, see Fig. 3 on the right. For the first cluster <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics> of Fig. 3 it can be seen that four tags T within this cluster have a significance value SV lying over the threshold TH value, such that they have been stored as characteristic vectors <semantics>CV1<annotation encoding="application / x-tex">CV_1< / annotation>< / semantics>, <semantics>CV2<annotation encoding="application / x-tex">CV_2< / annotation>< / semantics>, <semantics>CV3<annotation encoding="application / x-tex">CV_3< / annotation>< / semantics>, <semantics>CV4<annotation encoding="application / x-tex">CV_4< / annotation>< / semantics>. The corre- sponding tags T were "Monday", "Tuesday", "Wednesday", and 25 "Thursday". The label <semantics>L1<annotation encoding="application / x-tex">L_1< / annotation>< / semantics> of this cluster <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics> thus consists of four characteristic vectors CVi, each containing a single tag Τ. Fig. 4 shows an example of how to generate the label Li corresponding to the second cluster CL2 and second label L2 of Fig. 3. Here, firstly the significance values SV of three tags "holiday", "Sunday", and "July" have been calculated. Assuming a threshold value TH of 90%, it can be seen that only the tag "holiday" with a significance value SV of 92% qualifies as a characteristic vector CV;. Additionally, significance values SV for combinations, i.e., "and"-combinations, of tags T can be calculated, either for all tags T whose significance value SV lies below the threshold value TH or for tags T whose significance value SV lies below the threshold value TH but above a further threshold value, for example 25%. For those tags T, the significance value SV is calculated in combination with a further tag T, and if the significance value SV of such a tag combination TC lies above the threshold TH (or a different threshold), this tag combination TC is assigned as a characteristic vector CV; to this cluster CLi. Depending on the method to calculate the significance value SV, it might be beneficial to also consider "or"- combinations insofar as they have not been already found in the 15 form of multiple individual tags T whose significance values SV lie above the threshold level within the same cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>. To this end, the significance value SV of an "or"-combination of two tags whose significance value SV lies below the threshold level TH is calculated to see if these are to be included each as a characteristic vector <semantics>CV†<annotation encoding="application / x-tex">CV_{\dagger}< / annotation>< / semantics> for a cluster <semantics>CLi<annotation encoding="application / x-tex">CL_{i}< / annotation>< / semantics>. Generally, this method can be performed also for tag com- binations TC comprising three or more tags T, for example when the significance value SV of a two-tag combination TC again lies in a specific range of thresholds values. By means of 25 this, tag combinations of any length can be assigned to a clus- ter CLi as characteristic vectors CVi. One exemplary algorithm of identifying the significant tags T of a cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> is given as follows. To begin with, the tags T are specific values of so-called variables V, e.g., variables V can be "weekday", "special day", "school vacation day", "month", "month week", and / or "weather condition". The tags T are in turn assigned to each variable V, e.g., tags "Mon", "Tue", Wed", ... to the variable "weekday", tags "holi- day", "pre-holiday", ... to the variable "special day", "Yes", "No" to the variable "school vacation day" and so forth. In a first step of the exemplary algorithm, it is deter- mined by means of one of said statistical tests (Pearson's Chi Squared test, Fisher's exact test, ...) if a variable V is siq- nificant for a cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>, e.g., if the week day distribution is a priori significant in this cluster CLi. In a second step, for the most significant variable V the tags T that appear more than expected are determined. In a third step, the significance value SV for each tag T with respect to the rest of the tags T for that same variable V 10 is determined and compared to a predefined threshold TH as de- tailed above. In this way it can be determined, e.g., if the "Saturday" distribution is significant with respect to the rest of the week in this cluster. Furthermore, an additional "sub- cluster" SCLi is generated, which only contains the rest of the traffic profiles 6 that do not correspond to the significant tags T determined before. In a fourth step, steps two and three are repeated for the sub-cluster SCLi until there are no more variables V or traffic profiles 6 to analyze. In a fifth step, the significance test for tags T is per- formed starting with the least significant variable V according to step one, but only for samples inside this sub-cluster SCLi and not with the full cluster size. If the significance value SV is above said threshold TH, those tags T will be added to the cluster label. In a sixth step, the fifth step is repeated for the next sub-cluster SCLi in increasing significance order. This time, not only its own traffic profiles 6 are considered but also the items of the previously analyzed sub-clusters SCLi that were not significant. In this way, all "significant" sub-clusters SCLi for the first level can be computed, and the corresponding tags T are added as a label to the initial cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>. If there are one or more significant sub-clusters SCLi in the first level, in a seventh step the process is repeated for each sub-cluster SCLi in the next level to determine new "child sub-clusters", considering only the characteristics or vari- ables that have not been analyzed before. These steps are then repeated until there is nothing more to analyze in any branch and all "combined" tags T can be added to the label for the child sub-clusters SCLi. Furthermore, if a sub-cluster SCL; includes more than one significant tag T for a variable V, then each tag T will be analyzed in a separate branch. Only if after analyzing all these branches they do not have sub-branches, all the tags T are grouped together. Also, to calculate the significance value SV of a tag T in each branch, only the traffic profiles 6 corresponding to the variables of all levels above the analyzed branch are consid- ered. For example, when the tag "rainy" of a sub-cluster "Fri- 15 days" is analyzed, the expected value for "rainy" will be cal- culated considering only the weather conditions for all the "Fridays" of the total population. Returning to the second cluster CL2 of Fig. 3 detailed in Fig. 4, it can be seen that the tag combinations "Sunday and rain" and "Sunday and July" have significance values SV lying above the threshold value TH. Thus, those two tag combinations TC are assigned as characteristic vectors <semantics>CV1<annotation encoding="application / x-tex">CV_1< / annotation>< / semantics>, <semantics>CV2<annotation encoding="application / x-tex">CV_2< / annotation>< / semantics> to the sec- ond cluster <semantics>CL2<annotation encoding="application / x-tex">CL_2< / annotation>< / semantics>. In this example, it can be seen that while the second cluster <semantics>CL2<annotation encoding="application / x-tex">CL_2< / annotation>< / semantics> is not representative for Sundays, rainy days, or days in July alone, this cluster <semantics>CL2<annotation encoding="application / x-tex">CL_2< / annotation>< / semantics> is representative for rainy Sundays and Sundays in July. Furthermore, if two clusters are assigned the same charac- teristic vectors CVi, the characteristic vector CVi whose tag T or tag combination TC has the lower significance value SV can be deleted from the label <semantics>Li<annotation encoding="application / x-tex">L_i< / annotation>< / semantics> of this cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>. By means of this, all clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> can be assigned a label Li comprising any number of characteristic vectors CVi that represent this cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>. The labelling engine 14 in turn stores these labelled clusters <semantics>CLi<annotation encoding="application / x-tex">\mathrm{CL_i}< / annotation>< / semantics> in a database 16 which can again be embodied as the database 7 or a subset thereof, as the database 12 or a subset thereof, or embodied as a stand-alone database. From the first cluster <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics> of Fig. 3 it can also be seen that since the characteristic vectors <semantics>CV1<annotation encoding="application / x-tex">CV_1< / annotation>< / semantics>, <semantics>CV2<annotation encoding="application / x-tex">CV_2< / annotation>< / semantics>, <semantics>CV3<annotation encoding="application / x-tex">CV_3< / annotation>< / semantics>, <semantics>CV4<annotation encoding="application / x-tex">CV_4< / annotation>< / semantics> each comprise a single tag T only, they can optionally be grouped together, for example as weekdays. This can be done to reduce the number of characteristic vectors <semantics>CVi<annotation encoding="application / x-tex">CV_i< / annotation>< / semantics>, which in turn reduces computational efforts when trying to find a certain cluster. The labelled clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> in the database 16 can now be used to predict a past, present, or future traffic behaviour PTB (Fig. 2) in the road system 1. To this end, a request Req can be fed into a prediction engine 17, which for this purpose obtains the labelled clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> from the database 16. The re- quest Req comprises one or more request tags RT, which can be formulated by a user. The prediction engine 17 then matches the request tags RT to the characteristic vectors CV; of the la- belled clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> to determine a "matching" cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>. This matching cluster CLi, or any data derived therefrom, is then output by the prediction engine 17 as the predicted traffic be- haviour PTB. One exemplary setup of the engines 11, 14, 17 can be as follows: While the traffic measuring device 4 acquires data in real-time in the field, after an extended period of, e.g., one year, the clustering engine 11 and the labelling engine 14 can produce the labelled clusters CLi in the processor 9 of a cen- tral station. On the other hand, the prediction engine 17 can be embodied as an entity physically distinct from the cluster- ing and labelling engines 11, 14. Alternatively, the clustering engine 11, labelling engine 14, and prediction engine 17 can be implemented by the same machine. The operation of the prediction engine 17 is now described in further detail by means of Figs. 5 and 6. After starting the prediction process, in step 18 the cluster CLi that comprises the highest number N of traffic profiles 6 is determined and set as a reference cluster. In the example of Fig. 3, the first cluster <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics> contains the most (N = 100) traffic profiles 6. In step 19, a dissimilarity measure D is calculated for each of the clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>. The dissimilarity measure D is a measure of how much the traffic profiles 6 of a specific clus- ter CLi differ from the traffic profiles 6 of the reference cluster (here: <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics>). Once a dissimilarity measure D is calcu- lated for a cluster <semantics>CLi<annotation encoding="application / x-tex">\mathrm{CL_i}< / annotation>< / semantics>, it can be assigned to all characteris- tic vectors CV; of this cluster CL; Per definition, the refer- ence cluster does not differ from itself and thus has the low- est dissimilarity measure, e.g., D = 0, assigned. To compute a dissimilarity measure D for the other clus- ters, for example, an averaged traffic profile of a cluster CLi is compared to an averaged traffic profile of the reference cluster. In some embodiments, this can be done by using the same distance metric that was used to generate the clusters. In the example of Fig. 3, the third cluster <semantics>CL3<annotation encoding="application / x-tex">CL_3< / annotation>< / semantics> deviates the most from the reference cluster <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics> and has a dissimilarity measure <semantics>D=12<annotation encoding="application / x-tex">D = 12< / annotation>< / semantics> assigned thereto. The fourth cluster <semantics>CL4<annotation encoding="application / x-tex">CL_4< / annotation>< / semantics> only deviates a little bit from the reference cluster and has a dissimilarity measure D = 3 assigned, while the second cluster <semantics>CL2<annotation encoding="application / x-tex">CL_2< / annotation>< / semantics> has a dis- similarity measure <semantics>D=7<annotation encoding="application / x-tex">D = 7< / annotation>< / semantics> assigned. It is stressed that the dis- similarity measure D is independent from the number N of traf- fic profiles 6 in a cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> and only represents a differ- 25 ence of the average, modal, or median value, or there like, of traffic profiles 6 between clusters <semantics>CLi<annotation encoding="application / x-tex">\mathrm{CL_i}< / annotation>< / semantics>. Any measure of (dis) similarity between curves known in the state of the art can be used as the dissimilarity measure D such as, for exam- ple, an L2 norm, an L1 norm, or hybrid norms. Steps 19 and 20 can, e.g., be performed in the processor 9 or in the labelling engine 14. After a request Req with request tags RT is fed into the prediction machine 17 in step 20, it is checked in step 21 whether all request tags RT of the request Req match one of the characteristic vectors <semantics>CVi<annotation encoding="application / x-tex">CV_i< / annotation>< / semantics> of the clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>. For this pur- pose, the request tags RT can be combined to the form of a characteristic vector CV; to see if any of the characteristic vectors CV; of the clusters coincide with it. If this is the case (branch "Y"), the cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> that contains the matching characteristic vector CV; is determined as the matching cluster CLi in step 22. At the end of step 22, either the whole matching cluster CLi or an average traffic profile or any other data derived from this matching cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> can be output by the prediction engine 17 as the predicted traffic behaviour PTB for the re- quest Req. Alternatively, if in step 21 no matching character- istic vector <semantics>CVi<annotation encoding="application / x-tex">CV_i< / annotation>< / semantics> can be found amongst the clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> (branch "N"), one of the request tags RT is eliminated from the request Req in a step 23, and step 21 is repeated. The step 23 of removing a request tag RT from the request Req is described in detail by means of an example shown in Fig. 6, which again uses the exemplary clusters of Fig. 3. Here, in the beginning the request Req comprises the request tags "Wednesday", "holiday", and "rain". When the step 21 is per- formed for the first time, it is checked whether the combina- tion of these three request tags RT appears in any of the la- bels <semantics>Li<annotation encoding="application / x-tex">L_i< / annotation>< / semantics> of the four clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>, see the four labels <semantics>L1<annotation encoding="application / x-tex">L_1< / annotation>< / semantics>, <semantics>L2<annotation encoding="application / x-tex">L_2< / annotation>< / semantics>, <semantics>L3<annotation encoding="application / x-tex">L_3< / annotation>< / semantics>, <semantics>L4<annotation encoding="application / x-tex">L_4< / annotation>< / semantics> on the right side of Fig. 3. In this example, no charac- teristic vector CV; can be found that comprises the three re- quest tags RT. To eliminate one of the request tags RT from the request Req, in one embodiment of the present method for each request tag RT it is checked individually whether there exists a char- acteristic vector CV; matching this request tag RT, i.e., it is not checked whether this request tag RT simply occurs in a tag combination TC of a characteristic vector <semantics>CVi<annotation encoding="application / x-tex">CV_i< / annotation>< / semantics>, but only if there is a characteristic vector CV; that exactly matches the request tag RT. By means of Figs. 3 and 6, it can be seen that the request taq "Wednesday" of the request Req occurs as the characteristic vector <semantics>CV3<annotation encoding="application / x-tex">CV_3< / annotation>< / semantics> in the label <semantics>L1<annotation encoding="application / x-tex">L_1< / annotation>< / semantics> of the first cluster <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics>, the request tag "holiday" of the request Req occurs as the characteristic vector <semantics>CV1<annotation encoding="application / x-tex">CV_1< / annotation>< / semantics> in the label <semantics>L2<annotation encoding="application / x-tex">L_2< / annotation>< / semantics> of the second cluster <semantics>CL2<annotation encoding="application / x-tex">CL_2< / annotation>< / semantics>, and the request tag "rain" of the request Req occurs as the characteristic vector <semantics>CV1<annotation encoding="application / x-tex">CV_1< / annotation>< / semantics> in the label <semantics>L4<annotation encoding="application / x-tex">L_4< / annotation>< / semantics> of the fourth cluster CL4. Now it is checked which of these corresponding character- istic vectors CV; has the lowest dissimilarity measure D. Since the characteristic vector <semantics>CV3<annotation encoding="application / x-tex">CV_3< / annotation>< / semantics> is in the first cluster <semantics>CL1<annotation encoding="application / x-tex">CL_1< / annotation>< / semantics>, which has the lowest dissimilarity measure <semantics>D=0<annotation encoding="application / x-tex">D = 0< / annotation>< / semantics>, and the other two clusters <semantics>CL2<annotation encoding="application / x-tex">CL_2< / annotation>< / semantics>, <semantics>CL4<annotation encoding="application / x-tex">CL_4< / annotation>< / semantics> have higher dissimilarity measures <semantics>D=7<annotation encoding="application / x-tex">D = 7< / annotation>< / semantics>, 3, respectively, the request tag "Wednesday" is eliminated from the request Req because this request tag RT corresponds to a characteristic vector <semantics>CVi<annotation encoding="application / x-tex">CV_i< / annotation>< / semantics> of the cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> with the lowest dissimilarity measure D, i.e., to the least interesting cluster 15 CLi, here: cluster CL1. Thereafter, step 21 is repeated and it is checked whether there exists a characteristic vector CVi that contains the tag combination of the remaining two request tags "holiday" and "rain". Again, this is not the case, and therefore it is again checked which of the two remaining request tags RT corresponds to a cluster <semantics>CL⁡i<annotation encoding="application / x-tex">\operatorname{CL}_i< / annotation>< / semantics> with the lowest dissimilarity measure D. In this case, the request tag "rain" is eliminated from the re- quest Req because it has the lower dissimilarity measure D. Thereafter, it is again checked whether the request Req, which now only comprises the taq "holiday", matches any of the characteristic vectors CVi of the clusters CLi. This is the case for the second cluster CL2, which has the characteristic vector <semantics>CV1<annotation encoding="application / x-tex">CV_1< / annotation>< / semantics> assigned. Therefore, the second cluster <semantics>CL2<annotation encoding="application / x-tex">CL_2< / annotation>< / semantics> is the matching cluster, from which the predicted traffic behaviour PTB is then derived. Sometimes request tags RT do not occur in a characteristic vector CVi that contains only this request tag RT in any of the clusters CLi because either this tag of the request is not pre- sent in any of the tags T of the traffic profiles 6 that are used to create the clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> or because this tag T is only used in a characteristic vector <semantics>CV1<annotation encoding="application / x-tex">CV_1< / annotation>< / semantics> in a combination with a further tag T. In this case, the lowest dissimilarity measure, e.g., <semantics>D=0<annotation encoding="application / x-tex">D = 0< / annotation>< / semantics>, can be assigned to this request tag RT. In an alternative embodiment, when checking which of the request tags RT is to be eliminated, it is not only checked if there is a characteristic vector CV; that only comprises this request tag RT, but it is also checked whether there is a char- acteristic vector CV; comprising this request tag RT in combi- nation with a further tag T. In this case, this characteristic vector <semantics>CVi<annotation encoding="application / x-tex">CV_i< / annotation>< / semantics> and in turn the underlying cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics> and its dis- similarity measure D is chosen, for which, e.g., the signifi- cance value SV of the characteristic vector CV; is higher or which has a higher or lower number N of traffic profiles 6. For example, in Fig. 3 for the tag "holiday", the characteristic vector <semantics>CV1<annotation encoding="application / x-tex">CV_1< / annotation>< / semantics> of the second cluster <semantics>CL2<annotation encoding="application / x-tex">CL_2< / annotation>< / semantics> and the characteristic vector CV2 of the third cluster CL3, which has the tag combina- tion "holiday and sunny", are available. Because the signifi- cance value SV of the characteristic vector CV2 of the tag com- bination "holiday and Sunday" the third cluster CL3 is higher (98%) than the significance value SV (92%) of the characteris- tic vector <semantics>CV1<annotation encoding="application / x-tex">CV_1< / annotation>< / semantics> in the second cluster <semantics>CL2<annotation encoding="application / x-tex">CL_2< / annotation>< / semantics>, the dissimilarity measure D = 12 of the third cluster <semantics>CL3<annotation encoding="application / x-tex">CL_3< / annotation>< / semantics> (and not D = 7 of the second cluster CL2) is chosen for the request tag "holiday" and further used in the comparison steps of Fig. 6. Thus, in some embodiments, in which significance values SV of characteristic vectors <semantics>CVi<annotation encoding="application / x-tex">CV_i< / annotation>< / semantics> have been used to label the clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>, these significance values SV can also be used when determining the cluster CLi matching the request Req. In all embodiments, when checking which request tag RT corresponds to the characteristic vector <semantics>CVi<annotation encoding="application / x-tex">CV_i< / annotation>< / semantics> of a cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>, and two clusters have the same characteristic vectors CVi, the characteristic vector CV; with the higher significance value SV can be chosen for this request tag RT. Furthermore, when in the matching step 21 two matching clusters CLi are found, the one with the high number N of traf- fic profiles 6 can be determined as the matching cluster and the other one discarded. To further enhance the accuracy of the method, not only can there be checked whether single request tags RT occur in the characteristic vectors <semantics>CVi<annotation encoding="application / x-tex">CV_i< / annotation>< / semantics> of the clusters <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>, but also if combinations of request tags RT correspond to a characteristic vector <semantics>CVi<annotation encoding="application / x-tex">CV_i< / annotation>< / semantics> of a cluster <semantics>CLi<annotation encoding="application / x-tex">CL_i< / annotation>< / semantics>. In this case, if this characteris- tic vector CV; corresponding to a combination of request tags RT has the lowest dissimilarity measure D amongst the charac- teristic vectors CV; corresponding to all request tags RT or request tag combinations, said request tag combination is dis- regarded until a request tag RT is eliminated from the request Req. The invention is not restricted to the specific embodi- ments described in detail herein, but encompasses all variants, combinations and modifications thereof that fall within the framework of the appended claims.

Claims

1. A method in a road system, comprising: in a traffic measuring device: measuring traffic conditions on a road or intersection of roads in the form of a set of traffic profiles, each traffic profile representing a traffic measure of vehicles in the road system recorded over time, one or more pre- defined tags associated with a time of recording of the respective traffic profile being attributed to said traffic profile; in a clustering engine of at least one processor connected to a database, which contains said set of traffic profiles: clustering the traffic profiles with their tags into at least two clusters as to similarity of traffic profiles; in a labelling engine: assigning at least one characteristic vector to each cluster based on the tags in this cluster, wherein each characteristic vector contains a tag or a combination of tags of said cluster; determining which cluster comprises the most traffic profiles and setting this cluster as a reference cluster; for each cluster, determining a dissimilarity measure of this cluster with respect to the reference cluster and assigning the dissimilarity measure to all characteristic vectors of this cluster, wherein the dissimilarity measure is a measure of how much the traffic profiles of a cluster differ from the traffic profiles of the reference cluster; in a prediction engine: receiving a request having one or more request tags; checking whether all request tags match one of the characteristic vectors of the clusters, and - if so, outputting a predicted traffic behaviour based on the cluster with said matching characteristic vector, else, eliminating one of the request tags from the request and returning to said step of checking; wherein the request tag to be eliminated is chosen by determining which of the characteristic vectors corresponds to each request tag and choosing the request tag whose corresponding characteristic vector has the lowest dissimilarity measure.

2. The method according to claim 1, wherein, when choosing which request tag is to be eliminated from the request, it is also checked whether a combination of request tags corresponds to one of the characteristic vectors, and if so, and if this characteristic vector has the lowest dissimilarity measure amongst the characteristic vectors corresponding to all request tags or request tag combinations, said request tag combination is disregarded until a request tag is eliminated from the request.

3. The method according to claim 1 or 2, wherein the dissimilarity measure of a cluster is obtained by comparing an average traffic profile of said cluster with an average traffic profile of the reference cluster.

4. The method according to any one of the claims 1 to 3, wherein the determining which of the characteristic vectors corresponds to each request tag or request tag combination includes determining whether one of the characteristic vectors only comprises this request tag or request tag combination. -5. The method according to any one of the claims 1 to 3, wherein the determining which of the characteristic vectors corresponds to each request tag or request tag combination includes determining whether one of the characteristic vectors comprises this request tag or request tag combination either alone or in combination with at least one further tag.

6. The method according to any one of the claims 1 to 5, wherein a significance value of each characteristic vector of each cluster is calculated and, when two or more characteristic vectors correspond to a request tag or request tag combination from the request, the characteristic vector with the lower significance value is disregarded.

7. The method according to any one of the claims 1 to 6, wherein, determining which of the characteristic vectors corresponds to each request tag includes determining that two characteristic vectors correspond to a request tag or a request tag combination and that both have the same significance value, and wherein, in response, the characteristic vector of the cluster with the lower number of traffic profiles is disregarded.

8. The method according to any one of the claims 1 to 7, wherein each traffic profile represents the traffic measure of vehicles in the road system over a time-span of 24 hours.

9. The method according to any one of the claims 1 to 8, wherein at least one tag indicates a day of the week, a month of the year, a week of the month, a school vacation indication, or a special holiday indication of said time of recording. .

10. The method according to any one of the claims 1 to 9, wherein at least one tag indicates a road condition or a weather condition at said time of recording.