GB2448931A

GB2448931A - A Method of Processing Vehicle Position Data

Info

Publication number: GB2448931A
Application number: GB0708682A
Authority: GB
Inventors: Anthony Lovick; Matthew Barnes
Original assignee: Norwich Union Insurance Ltd
Current assignee: Norwich Union Insurance Ltd
Priority date: 2007-05-04
Filing date: 2007-05-04
Publication date: 2008-11-05
Also published as: GB0708682D0

Abstract

A method is provided for processing data recording movements of a vehicle, in which a sequence of data records representing successive positions of the vehicle is matched with additional data relating to the vehicle's location in a road network at a particular time. Each record comprises data fields representing a given time in the sequence and the position of the vehicle at a given time. In accordance with the method, a road portion data table is provided which comprises data relating to a geographical area divided into regions, the area including road portions which together form a road network, wherein the table associates a group of the road portions with each region. For each data record in the sequence, the region which contains the vehicle position represented by the data record is identified, and a road portion is selected from the group associated with the identified region in the road portion data table.

Description

1 2448931 Title: A Method of Processing Vehicle Position Data

Field of the Invention

The present invention relates to processing of data recording movements of a vehicle. More particularly, it relates to a method for matching a sequence of data records representing successive positions of a vehicle with additional data. The additional data relates to where in a road network a vehicle is located at a particular time.

Background to the Invention

The use of positioning devices in vehicles is becoming increasingly widespread, not only for navigation, but for other purposes, such as use of position data in calculation of insurance premiums based on actual journeys undertaken by the vehicle concerned. For many applications, it is necessary to determine which road the vehicle is on at any time. Attributes of a particular section of road may be useful in insurance research, or in calculation of insurance premiums, or to provide information about congestion.

Known in-vehicle navigation systems typically match position data to a road network in "real time", one point at a time. The device needs to be relatively small and have low power requirements. It will therefore have limited memory capacity. Accordingly, geographical data is often uploaded to the device in batches from a data carrier such as a DVD.

In some applications, position data may be generated by a large number of vehicles for subsequent processing. Where this processing involves matching geographical data with the position data, carrying this process out using existing commercial packages matching the data one point at a time would be an extremely slow and expensive process. There is therefore a need to effect this processing in a more efficient manner.

Summaryof the Invention

The present invention provides a method of matching a sequence of data records with additional data, wherein each record comprises data fields representing a given time in the sequence and the position of an object at said given time, the method comprising the steps of: (a) providing a road portion data table comprising data which relates to a geographical area divided into regions, the area including road portions which together form a road network, wherein the table associates a group of the road portions with each region; and (b) for each data record: (i) identifying the region which contains the object position represented by the data record; and (ii) selecting a road portion from the group associated with the identified region in the road portion data table.

In this way, a large bulk of position data can be processed in a single procedure, providing substantial cost and time savings. By processing geographical information to provide the road portion data table in advance, the process of handling the bulk data is considerably accelerated. The position data is matched to the corresponding region of the geographical area. The road portion candidates in the region are then compared to the position data and the most appropriate one selected.

The claimed method can be stored on-line within a database, providing fast access. It can be implemented at a cost per telernatic device year of position data which makes exploitation of the data value commercially viable.

The speed of database table "joins" with appropriate indexes is employed. Both the position data and the geographic information can be identified to fall within a small region. This reduces the search method to only considering candidates within this area to find the appropriate match.

The geographical data is likely to only be updated periodically and so the substantial pre-processing necessary to create the road portion data table need only be carried out on an occasional basis to facilitate processing of the bulk data.

Preferably, a road portion is associated within a region in the road portion data table if at least part of it is within the region, or it is outside the region but at least part of it is within a predetermined distance of the centre of the region. For example, tolerance in the accuracy of the position data generated by an in-vehicle telematics device may mean that the relevant road portion is in a region adjoining the region in which the data point itself falls.

In a preferred embodiment, the geographical area is divided up into regions by mutually perpendicular lines and the region data table includes data which identifies each region by reference to the location of the same corner of each region. By referring to the co-ordinates of the region corners, it is then possible to rapidly identify the region of interest. For example, the mutually perpendicular lines may be lines of latitude and longitude. The lines may be in accordance with Ordnance Survey grid references in the UK, or other systems of gridlines used in the UK or elsewhere.

In a preferred implementation, the location of said corner of each region is represented in the region data table by values representing a latitude and a longitude, respectively, and the geographical area is divided into the regions such that the values representing the location of each corner are a multiple of ten or a multiple of a power of ten. Using this technique, it is not necessary to consider all the digits making up the position data in order to identify the region of interest.

Alternatively the values representing the location of each corner may be multiples of other numbers. For example, rounding to units of 20 transforms references 158,162,212 to 140,160,200.

The roads network may be divided into road segments, each segment comprising at least one of the road portions. Attributes of a particular section of road (for example, whether it is a motorway, the relevant speed limit and the like) can be stored in association with each segment. As there are fewer segments than road portions, the volume of memory occupied by this data is therefore reduced. This increases the speed of access to this data, and decreases the associated storage requirements. The larger number of road portions (each representing a straight line) provides greater resolution of the paths of roads in the network.

The road portion data table may identify which road segment each road portion is in, so that in carrying Out the method, the road segment which contains the road portion assigned to each data record can be directly identified.

Once the road segment associated with each data record has been identified, a further data field may be added to each data record which relates to the respective road segment to form a corresponding augmented data record, and the sequence of augmented data records can then be stored in electronic memory.

Preferably, the method includes the step of providing a road segment data table comprising data relating to each road segment, wherein the data included in the further data field of each record is derived from the road segment data table. The further data field may merely be sufficient to identify a particular entry in the road segment data table to minimise the size of the augmented data records.

The present invention further provides a method of analysing a sequence of road segments which represents a journey undertaken by an object, including the steps of providing a direct connection node table comprising data relating to a road network formed of road segments, wherein the table identifies the road segments to which each road segment is directly connected in the road network; analysing the sequence of road segments with respect to the direct connection node table to identify an extra road segment in the sequence which is not part of the journey; and removing the extra road segment from the sequence. By providing a direct connection node table, it is then possible to quickly analyse the sequence of road segments to identify an apparently spurious additional road segment to the side of the journey path. Processing of position data may identify a side road where an individual data point falls closer to the side road than the road along which the vehicle is actually travelling.

It is not appropriate to include such a road segment in a record of the vehicle journey and so the sequence is processed to remove any such extra road segments.

Furthermore, the present invention provides a method of analysing a sequence of road segments which represents a journey undertaken by an object, including the steps of: providing an indirect connection node table comprising data relating to a road network formed of road segments, wherein the table identifies the road segments to which each road segment is connected in the road network via a single intervening road segment; analysing the sequence of road segments with respect to the indirect connection node table to identify a road segment missing from the sequence; and inserting the missing road segment at the appropriate place in the sequence. The indirect connection node table is prepared by pre-processing of the geographical data as a whole to accelerate analysis of a particular sequence of road segments. If an individual road segment is relatively small, a recorded data point may not fall close to the segment and so it may be omitted from the sequence of road segments representing a journey. The indirect connection node table is used to identify the missing road segments quickly and the missing segments can then be inserted at the appropriate places in the sequence.

The table may also be expanded (or a further table added) to identify those road segments to which each segment is connected via two intervening road segments (or via three intervening segments, and so on).

Brief Description of the Drawings

Embodiments of the invention will now be described by way of example and with reference to the accompanying drawings wherein: Figure 1 is a diagram illustrating matching of journey points to geographical information in a point-by-point manner; Figure 2 is diagram illustrating the matching of a journey point to a road vector data table; Figure 3 illustrates the relationship between various geographic data tables according to an embodiment of the invention; Figure 4 is a diagram illustrating association of geographical regions with a road vector; Figures 5 and 6 represent a direct connection node table and an indirect connection node

table, respectively;

Figure 7 is a diagram of part of a road network and direct and indirect connection node tables based on that network; Figure 8 is a diagram to illustrate inclusion of an extra, anomalous road segment in a sequence; is Figure 9 illustrates omission of a road segment from a sequence; and Figure 10 is a diagram illustrating processing of a sequence of road segments to omit duplicates and an extra road segment.

Detailed Description

Figure 1 illustrates matching of "journey point" data with "road vector" data simply by considering each journey point in turn. Each journey point data record in a large volume of data 2 collected from various positioning devices consists of a data field identifying the positioning device which generated the data ("device ID"), a "timestamp" data field which records the time at which the vehicle position was recorded, and latitude and longitude data fields which record the position of the vehicle at that time.

The road vector data table 4 lists road vectors (also referred to herein as "road portions") which together form a road network. Each entry in the table includes the start position and end position of the respective road vector. A road vector table representing a reasonably sized road network, such as that of the UK, might typically include 20 million entries. A journey point data table consisting of data from a number of positioning devices could include an entry for every second that each vehicle engine was turned on in a year, and therefore run to millions of rows of data.

It can readily be appreciated that matching each item of journey point data to the vector data, point by point, would be an extremely time consuming and expensive process. Also, this process could identify several road vectors as potentially the most appropriate for a particular data point.

A method of matching journey point data with road vector data embodying the present invention is illustrated in Figure 2. The journey point data 6 to be processed could be in the same format as that of Table 2 in Figure 1. In the embodiment of Figure 2, some initial processing of the journey point data has taken place and a further data field has been added to each data record, namely, a "square identifier". This field identifies an entry in a road portion data table or "squares" table 8. Generation of the square identifier field will be discussed further below.

Each entry in the squares table 8 relates to one of a large number of squares which together cover a geographical area including the road network of interest. Each entry includes a square identifier field and lists the road vectors or road portions of the road network which are included in or close to the square concerned.

Each journey point therefore maps to just one row in the squares table. The correct row can be determined entirely from the latitude and longitude of the journey point, without needing to search through the squares table, which could have millions of entries.

Before matching of journey points to road vectors can take place, it is necessary to process data representing the road network to create the squares table. The results of this processing, according to one embodiment of the invention, are illustrated in Figure 3.

The geographical data is processed to identify three sets of elements that together represent the road network. Each "road segment" is a continuous length of road which starts and ends with a "node". A node represents the point at which two or more road segments join together. Often a node will correspond to an actual road junction, but may merely represent a join between two road segments of a common road. Each road segment is formed of one or more straight line "road vectors" or "road portions".

These three sets of data are stored in a relational structure of the form schematically illustrated in Figure 3.

Each entry in a node table 10 has an identifier field and a "segment identifier" field which identifies the segments which join at the nodes by identifying the respective entries in a road segment table 12. Each entry in this table includes the segment identifier field together with one or more attributes of the respective road segment, such as the name of the road it lies on and the road type.

The road vectors making up the road network are listed in road vector table 14. Each entry identifies which entry in the road segment data table represents the road segment of which the road vector forms a part (the "segment identifier"). Each entry also identifies the start and end positions of the respective road vector.

The road network data is also processed to create squares table 8. In relation to each square, the associated road vectors are identified by a reference to the respective entry in road vector

table 14.

The size of the squares making up the squares table may be selected by adjusting the number of squares needed to cover the whole geographical area with reference to the number of candidate road vectors that would be associated with each square. Having larger squares would reduce the number of entries in the squares table, but would increase the number of road vectors to be considered in selecting the most appropriate road vector to match with a particular position data point. The sides of each square could be 20 metres long for example.

In implementing the present method, having a large number of entries in the squares table need not slow down the process of selecting the appropriate square, as the journey point data table identifies an individual entry in the squares table.

In generating the squares table, it is necessary to select which road vectors are to be associated with each square. As the length of an individual road vector can be substantial (vectors over 100 kilometres in length may be encountered in practice), the processing effectively superimposes each road vector over the squares and then identifies all the squares whose centres are within a fixed perpendicular distance of the vector. I0

This is illustrated in Figure 4, in which a vector 16 is superimposed over a group of squares 18. In this example, those squares shaded grey are considered sufficiently close to the road vector to be associated with that vector in the squares data table. It can be seen that some of the squares are not actually intersected by the vector itself. This allows for some inaccuracy in the positioning data. A journey point may fall within one of these squares whilst a vehicle is travelling along a road vector 16.

In pre-processing journey point data to form a table of the structure shown in Figure 2 as Table 6, each journey point is matched to a square identifier. This process can.be facilitated by defining these squares in squares table 8 in such a way that the same corner of each square lies at a point corresponding to round co-ordinate values. For example, if the co-ordinates are represented by 6-digit numbers, the co-ordinates of the bottom left corner of one square may be (15 8000,300000), the co-ordinates of the bottom left corner of the square above as (159000,300000), and the co-ordinates of the bottom left hand corner of the square to the right as (158000,301000), and so on. In determining which square a data point (158 101,300402) lies, it will only be necessary to consider the first three digits of each co-ordinate, therefore simplifying the associated computation, and accelerating the process.

Once the appropriate square has been identified, a corresponding square identifier can then be associated with the respective journey point in the journey point data table 6, forming a join between the journey point data table 6 and the squares data table 8.

The next processing step is then to determine the most appropriate road vector to associate with each journey point. This involves considering the road vectors associated with the relevant square in the squares table. Selection of the most appropriate road vector may be based on a number of factors, such as: 1) The distance from the road vector to the journey point; 2) The direction of vehicle travel, compared to the orientation of the road vector; 3) The speed of travel; and 4) Any restrictions on the direction of travel on the road vector, that is taking into account if it is a one-way street, or part of a roundabout, for example.

The weighting given to each of these factors may differ. Furthermore, the weightings may be adjusted to improve accuracy by feedback from their application to real data.

Also the weightings may vary depending on the individual values of the recorded data being processed. For example, heading data is likely to be inaccurate when a vehicle is stationary due to noise in the vehicle positioning data. However, heading data is more reliable when the vehicle is moving.

In determining the distance from a road vector to an individual data point, the perpendicular distance from the road vector to the position can be taken. If a line extending from the journey point which is perpendicular to the road vector does not intersect the road vector, then the distance from the journey point to the nearest endpoint of the vector (or a suitable approximation thereof) can be taken.

Once the road vector to be associated with a particular data point has been identified, the data structure shown in Figure 3 can then be employed to identify which segment the road vector lies on in road segment table 12. In some applications, it may be desirable to augment the original journey point data by addition of the respective segment identifier to each journey point data record. The sequence of segment identifiers in the augmented data therefore represents the sequence of roads on which the vehicle travelled.

II

In preferred embodiments, some further processing of a sequence of road segment identifiers is carried out to identify any potential anomalies. Analysis of the sequence may identify inappropriate entries or omitted entries in the sequence. More particularly, each segment may be considered with reference to the preceding andlor following segment(s), and knowledge of the connections between segments in the road networks.

In order to facilitate analysis of a road segment sequence, one or both of the further data tables shown in Figures 5 and 6 can be created fTom the road network data. Figure 5 shows a direct connection node table 30, called "Connect 2". Each entry in the table includes an identifier relating to an individual road segment, and also one or more identifiers for each further road segment which is directly connected to the road segment concerned.

Figure 6 represents an indirect connection node table 32, called "Connect 3". Each entry in this table again relates to an individual road segment and includes a corresponding segment identifier field. In relation to each road segment, not only is each road segment connected directly to it identified, but also those road segments connected to it by a single intervening road segment.

Figure 7 illustrates the structure of the tables shown in Figure 5 and 6 with reference to a simple exemplary road network 34. The network consists of five road segments A to E, which intersect at nodes 36, 38 and 40.

Entries are included in direct connection node table 30 relating to road segments A, B and C. It can be seen that each entry identifies those road segments which are directly connected to the segment concerned. In indirect connection node table 32, entries are again shown for road segments A, B and C. For each road segment, a road segment connected directly to it is included in a second column headed "S1A", and a first road segment connected directly to the segment listed in column S1A is identified in column SiB. If a further road segment is directly connected to the segment identified in column SI A, the road segment is repeated in column S2A and the further segment connected to it is identified in column S2B, and so on.

Use of the node connection tables to process a sequence of road segments will now be described with reference to Figures 8 to 10.

In Figure 8, a sequence of journey points is represented by a number of stars 50. A, B and C denote road segments of a road network. Due to some inaccuracy in the positioning data, the journey points are offset slightly to the side of the road segments A and C along which the vehicle travelled. Segment B is a side road branching off from node 52 at which segments A and C are connected.

to It can be seen that a process of matching each journey point to the closest road segment would result in the sequence "AAABCCC". Inclusion of reference to B in a sequence recording the vehicle's journey would be inappropriate as in practice the vehicle travelled directly from road segment A to road segment C. This sequence should be corrected to "AAACCCC".

Analysis of this sequence with reference to the direct connection node table 30 would show that segment A is directly connected to segment C and that a single occurrence of road segment B in the sequence is likely to be erroneous. Similarly, analysis would recognise that a sequence "AAABAAA" should be corrected to "AAAAAAA".

In Figure 9, another sequence of journey points 56 is illustrated together with road segments D, E and F. E is a relatively short segment and mapping of the journey points onto the network of road segments would not result in inclusion of segment hi the sequence.

Analysis of the sequence with reference to indirect connection node table 32 would highlight that segment D is connected to segment F via segment E and show that segment E should therefore be inserted into the sequence so that it forms a complete record of all the road segments travelled along by the vehicle during its journey.

If it is desired to obtain a sequence of road segments representing a journey without repeatedly identifying each road segment associated with a plurality of consecutive journey points, the sequence can be processed to remove any such duplication. This is illustrated by way of example in Figure 10 in which sequence 60 is reduced to sequence 62 by de-duplication processing step 61. A further processing step 63 is also shown in which an anomalous entry B (generated by circumstances such as that shown in Figure 8) is removed.

In this embodiment, analysis of a sequence of road segments 62 is carried out after removal of duplicates. Analysis of sequence 62 with reference to direct connection road table 30 would indicate that segment A is connected directly to both segment B and subsequent segment C, suggesting that B is an anomalous entry in the sequence.

Preparation of the node connection tables for a given set of road network data facilitates efficient analysis of a sequence of road segments without having to search laboriously through the original road network data. The required information can be compiled into a table, enabling fast analysis to be carried out.

Claims

Claims 1. A method of matching a sequence of data records with

additional data, wherein each record comprises data fields representing a given time in the sequence and the position of an object at said given time, the method comprising the steps of: (a) providing a road portion data table comprising data which relates to a geographical area divided into regions, the area including road portions which together form a road network, wherein the table associates a group of the road portions with each region; and (b) foreachdatarecord: (i) identifying the region which contains the object position represented by the data record; and (ii) selecting a road portion from the group associated with the identified region in the road portion data table.
2. A method of claim I wherein a road portion is associated with a region if at least part of it is within the region, or it is outside the region but at least part of it is within a predetermined distance of the centre of the region.
3. A method of claim I or claim 2 wherein the geographical area is divided up into regions by mutually perpendicular lines and the region data table includes data which identifies each region by reference to the location of the same corner of each region.
4. A method of claim 3 wherein the mutually perpendicular lines are lines of latitude and longitude.
5. A method of claim 4 wherein the location of said corner of each region is represented in the region data table by co-ordinate values, and the geographical area is divided into the regions such that the values representing the location of each corner are a multiple of ten or a multiple of a power of ten.
6. A method of any preceding claim, wherein the road network is divided into road segments, each segment comprising at least one of the road portions, and the road portion data table identifies which road segment each road portion is in, the method including the step of: (c) for each data record, identifying the road segment which contains the road portion selected in step (b)(ii).
7. A method of claim 6 including the steps of: (d) adding a further data field to each data record which relates to the respective road segment to form a corresponding augmented data record; and (e) storing the sequence of augmented data records in electronic memory.
8. A method of claim 7 including the step of providing a road segment data table comprising data relating to each road segment, wherein the data included in the frirther data

field is derived from the road segment data table.
9. A method of analysing a sequence of road segments which represents a journey undertaken by an object, including the steps of: providing a direct connection node table comprising data relating to a road network formed of road segments, wherein the table identifies the road segments to which each road segment is directly connected in the road network; analysing the sequence of road segments with respect to the direct connection node table to identify an extra road segment in the sequence which is not part of the journey; and removing the extra road segment from the sequence.
10. A method of analysing a sequence of road segments which represents a journey undertaken by an object, including the steps of: providing an indirect connection node table comprising data relating to a road network formed of road segments, wherein the table identifies the road segments to which each road segment is connected in the road network via a single intervening road segment; analysing the sequence of road segments with respect to the indirect connection node table to identify a road segment missing from the sequence; and inserting the missing road segment at the appropriate place in the sequence.
11. A method of claim 7 or claim 8 including analysing the sequence of road segments included in the sequence of augmented data records according to a method of claim 9 or claim 10.
12. A method of claim 11 including a step of pre-processing the sequence of road segments included in the sequence of augmented data records before said analysis, by removing road segments from the sequence which duplicate the preceding road segment in the sequence.
13. A computer program comprising program instructions for causing a computer to perform a method of any preceding claim.
14. A computer program comprising program instructions for causing a computer to perform a method of any of claims 1 to 12 embodied on a record medium, stored in a computer memory, embodied in a read-only memory, or carried on an electrical carrier signal, or other carrier.
15. A computer programmed to perform a method of any of claims ito 12.