Patent Description:
Modifications to a roadway network may result from traffic metrics related to traffic flow, driving behaviour, or another traffic/driver information. For example, to increase traffic flow at a heavily congested roadway section an additional lane(s) may be added, to reduce wait times at an intersection control signal timing may be modified, and to deter speeding on a portion of road a traffic calming device, (e.g., a speed bump), may be installed.

Various data collection techniques are employed for collecting traffic data. A first technique includes employment of manual counters positioned near a roadway section of interest, (i.e., people observing traffic, then measuring and manually recording vehicle movement. ) For instance, to collect traffic data related to interruption of traffic flow at an intersection, a person/people may time the duration each vehicle is stopped prior to entering the intersection. Such a method is manually intensive and prone to human error.

Another technique for collecting traffic data includes use of sensing equipment. For example, movement sensors, (e.g., pneumatic tubes, video cameras), are temporarily and/or permanently installed near a roadway section of interest to sense vehicle movement and collect traffic data. This technique requires the purchase or rental, installation, and potentially maintenance, of sensing equipment. Extracting traffic data from video footage necessitates image processing which is usually complex and resource intensive.

Yet another technique for collecting traffic data includes use of a GPS tracker device installed onboard a vehicle. Traffic data collected via this technique is limited to the data collected by the particular devices, thus multiple passes through a roadway section of interest are needed to gather a sufficient amount of data for the data to be meaningful. Once collected, data from the devices must be uploaded for analysis/processing. The non-patent publication "<NPL>et al. and the <CIT> represent relevant prior art.

According to a first broad aspect there is a method for identifying a plurality of sample vehicle ways, for each sample vehicle way of the plurality of sample vehicle ways, defining a plurality of zones, each thereof comprising a corresponding sample vehicle way and each comprising a plurality of contiguous subzones, selecting vehicle data indicative of vehicle operating conditions for a plurality of corresponding vehicles, for each of the plurality of contiguous subzones of each zone of the plurality of zones, generating a plurality of features based on the vehicle data, for each of the plurality of contiguous subzones of each of the plurality of zones, generating training data comprising the plurality of features for each contiguous subzone; and using at least one machine learning technique with the training data to define a classifier for classifying a subzone as one of a portion of a vehicle way and not a portion of a vehicle way.

In an embodiment classifying by the classifier the subzone as one of a portion of a vehicle way and not a portion of a vehicle way comprises classifying the subzone for a type of vehicle way indicative of one of the types of vehicle ways of the plurality of sample vehicle ways.

In an embodiment the vehicle way comprises at least one bridge element coupled to at least one employed element, the at least one bridge element for traversal by a vehicle for transitioning therebetween, and the at least one employed element comprising an area for maneuvering of the vehicle.

In an embodiment the vehicle way comprises a parking lot and maneuvering of the vehicle comprises movement of the vehicle and parking of the vehicle. In another embodiment the vehicle way comprises an intersection and maneuvering of the vehicle comprises movement of the vehicle.

In an embodiment defining the plurality of zones includes, for at least one zone, defining an area encompassing a corresponding sample vehicle way of the plurality of sample vehicle ways.

In an embodiment defining the plurality of zones comprises, for at least one zone: obtaining geographic coordinate data indicating a location of a reference point proximate the corresponding sample vehicle way, defining a reference area relative to the location of the reference point for encompassing the corresponding sample vehicle way; and partitioning the reference area into the plurality of contiguous subzones.

In an embodiment partitioning the reference area comprises partitioning all portions of the reference area into the plurality of contiguous subzones. In another embodiment defining the reference area comprises defining the reference area at a same relative location to the reference point proximate the corresponding sample vehicle way. In another embodiment defining the reference area comprises defining the reference area at a distance substantially <NUM> radially from the reference point.

In an embodiment defining a plurality of zones comprises defining each of the plurality of contiguous subzones of each zone of the plurality of zones by latitude and longitude pairs.

In an embodiment partitioning the reference area into contiguous subzones comprises subdividing the reference area into a grid of latitude and longitude lines. In another embodiment partitioning the reference area into contiguous subzones comprises subdividing the reference area into contiguous subzones according to a hierarchical geospatial indexing system.

In an embodiment subdividing the reference area into contiguous subzones according to a hierarchical geospatial indexing system comprises subdividing the reference area into contiguous subzones according to a Geohash indexing system. In another embodiment subdividing the reference area into contiguous subzones according to a Geohash indexing system comprises subdividing the reference area into contiguous subzones according to the Geohash indexing system having a Geohash precision of substantially <NUM>. In yet another embodiment subdividing the reference area into contiguous subzones according to a hierarchical geospatial indexing system comprises subdividing the reference area into contiguous subzones according to a H3 hierarchical geospatial indexing system.

In an embodiment partitioning the reference area into the plurality of contiguous subzones comprises defining a first subzone encompassing the reference point and building a grid of contiguous subzones therefrom until all portions of the reference area are partitioned by the grid of contiguous subzones.

In an embodiment generating a plurality of features based on vehicle data indicative of vehicle operating conditions for a plurality of corresponding vehicles comprises generating a plurality of features based on vehicle data indicative of at least one of position, speed, and ignition state of a vehicle, the ignition state indicating a state of one of ON or OFF.

In an embodiment generating a plurality of features based on vehicle data comprises generating a plurality of features based on date and time data indicative of a date and time vehicle operating conditions is logged.

In an embodiment selecting vehicle data comprises selecting vehicle data corresponding to a location within the plurality of zones. In another embodiment selecting vehicle data comprises selecting vehicle data corresponding to a position within at least one traffic zone encompassing at least one zone of the plurality of zones. In yet another embodiment wherein selecting vehicle data comprises selecting vehicle data corresponding to a position within at least one traffic zone encompassing each zone of the plurality of zones.

In an embodiment vehicle data includes a subset of raw vehicle data or the subset of raw vehicle data and data interpolated therefrom. In another embodiment the data interpolated from the subset of raw vehicle data is dependent on the dimensions of each of the plurality of contiguous subzones.

In an embodiment there is a method including removing data from the vehicle data indicative of an outlier or duplicate or both.

In an embodiment generating the plurality of features includes generating subzone-related features from a first subset of vehicle data corresponding to a location within the contiguous subzone.

In an embodiment generating subzone-related features comprises generating subzone-related features selected from the group of: minimum vehicle speed, maximum vehicle speed, average vehicle speed, median vehicle speed, standard deviation of vehicle speed, minimum ignition, maximum ignition, total number of ignitions on, total number of ignitions off, average number of ignitions, ignition ratio, minimum number of vehicle visits/day, maximum number of vehicle visits/day, average number of vehicle visits/day, median number of vehicle visits/day, standard deviation of number of vehicle visits/day, minimum unique number of vehicle visits/day, maximum unique number of vehicle visits/day, median unique number of vehicle visits/day, standard deviation of unique number of vehicle visits/day, average unique number of vehicle visits/day, total number of vehicle visits, total number of unique vehicle visits, and average number of visits/vehicle.

In an embodiment wherein generating the plurality of features comprises generating subzone-related features from the first subset of vehicle data and a second subset of vehicle data including vehicle data for a same vehicle temporally subsequent thereto.

In an embodiment generating the subzone-related features comprises generating subzone-related features selected from the group of: average time to park, minimum time to park, maximum time to park, median time to park, and standard deviation of time to park.

In an embodiment generating the plurality of features comprises generating subzone-related features from the first subset of vehicle data and the second subset of vehicle data further including vehicle data for a same vehicle temporally preceding and subsequent thereto.

In an embodiment generating the subzone-related features comprises generating subzone-related features selected from the group of: average dwell time, minimum dwell time, maximum dwell time, median dwell time, and standard deviation of dwell time.

In an embodiment generating the plurality of features comprises generating zone-related features from a third subset of vehicle data instances corresponding to a position within a zone or from a portion of the subzone-related features.

In an embodiment generating zone-related features comprises generating zone-related features selected from the group of: zone minimum ignition off, zone maximum ignition off, zone average vehicle speed, zone maximum vehicle speed, zone minimum vehicle speed, zone average number of unique visits/day, zone minimum number of unique visits/day, zone maximum number of unique visits/day, zone average median number of unique visits/day, and zone total average number of unique visits/day.

In an embodiment generating zone-related features comprises generating zone-related features from the portion of the subzone-related features and are selected from the group of: zone average time to park, zone maximum time to park, zone minimum time to park, zone maximum dwell time, zone minimum dwell time, zone median dwell time, zone average dwell time, zone minimum number of unique visits, zone average number of unique visits, zone maximum number of unique visits, zone average total number of visits, zone maximum total number of visits, and zone minimum total number of visits.

In an embodiment generating zone-related features comprises generating zone-related features from the third subset of vehicle data instances corresponding to a position within a zone and are selected from the group of: zone total number of visits and zone total number of unique visits.

In an embodiment generating the plurality of features comprises generating subzone-zone-related features from a relationship of a portion of the plurality of subzone-related features to a portion of the zone-related features.

In an embodiment generating subzone-zone-related features comprises generating the subzone-zone-related features selected from the group of: minimum vehicle speed ratio, average vehicle speed ratio, maximum vehicle speed ratio, minimum ignition off ratio, maximum ignition off ratio, maximum dwell time ratio, minimum dwell time ratio, average median dwell time ratio, average dwell time ratio, minimum time to park ratio, average time to park ratio, maximum time to park ratio, minimum number of unique vehicle visits ratio, maximum number of unique vehicle visits ratio, average number of unique vehicle visits ratio, total number of vehicle unique visits ratio, minimum unique number of vehicle visits/day ratio, maximum unique number of vehicle visits/day ratio, average unique number of vehicle visits/day ratio, total unique number of vehicle visits/day ratio, average median unique number of vehicle visits/day ratio, minimum total number of vehicle visits ratio, maximum total number of vehicle visits ratio, average total number of vehicle visits ratio, and total number of vehicle visits ratio.

In an embodiment there is a method including, for each contiguous subzone of the plurality of contiguous subzones of the plurality of zones, obtaining spatial relationship data for each thereof to a corresponding zone and generating at least one feature from the spatial relationship data.

In an embodiment there is a method including, for each contiguous subzone of a plurality of contiguous subzones of the plurality of zones, obtaining spatial relationship data for each thereof to the plurality of subzones and generating at least one feature from the spatial relationship data.

In an embodiment obtaining spatial relationship data comprises obtaining spatial relationship data indicative of the distance between the subzone and a centre point of a corresponding zone.

In an embodiment obtaining spatial relationship data comprises obtaining spatial relationship data indicative of the distance between a centre point of the subzone and a centre point of the corresponding zone.

In an embodiment obtaining spatial relationship data comprises obtaining spatial relationship data indicative of the number of adjacent subzones to a subzone.

In an embodiment obtaining spatial relationship data comprises obtaining spatial relationship data indicative of the number of neighbours of a Geohash.

In an embodiment generating training data comprises generating training data indicative of the subzone as one of a vehicle way class or a not-vehicle way class.

In an embodiment there is a method including, for two or more zones of the plurality of zones having one or more common subzones, associating the one or more common subzones with a unique zone of the two or more zones.

In an embodiment associating the one or more common subzones with a unique zone comprises calculating the distance between each subzone of the one or more common subzones and a location of a centre point of the two or more zones and assigning the one or more common subzones to the zone of which the distance is shortest.

In an embodiment defining the reference area at a same relative location to the reference point proximate the corresponding sample vehicle way comprises defining the same relative location to the reference point by classifier data associated with the classifier.

In an embodiment there is a method including defining subzone dimensions by the classifier data.

In an embodiment there is a method including defining Geohash precision by the classifier data.

In an embodiment obtaining spatial relationship data comprises obtaining spatial relationship data indicative of the number of adjacent subzones to a subzone having vehicle data corresponding to a location therein.

In an embodiment obtaining spatial relationship data comprises obtaining spatial relationship data indicative of the number of neighbours of a Geohash having vehicle data corresponding to a location therein.

Embodiments of the invention are now described by way of non-limiting example and are illustrated in the following figures in which like reference numbers indicate like features, and wherein:.

Telematics is a method of monitoring a vehicle using an onboard monitoring device for gathering and transmitting vehicle operation information. For instance, fleet managers employ telematics to have remote access to real time operation information of each vehicle in a fleet. A vehicle may include a car, truck, recreational vehicle, heavy equipment, tractor, snowmobile or other transportation asset. A monitoring device may detect environmental operating conditions associated with a vehicle, for example, outside temperature, attachment status of an attached trailer, and temperature inside an attached refrigeration trailer. A monitoring device may also detect operating conditions of an associated vehicle, such as position, (e.g., geographic coordinates), speed, and acceleration, among others.

In an exemplary telematics system, raw vehicle data, including vehicle operation information indicative of a vehicle's operating conditions, is transmitted from an onboard monitoring device to a remote subsystem, (e.g., server). Raw vehicle data may include information indicating the identity of the onboard monitoring device (e.g., device identifier, device ID) and/or the identity of the associated vehicle the onboard monitoring device is aboard. Specific and non-limiting examples of raw vehicle data includes device ID data, position data, speed data, ignition state data, (e.g. indicates whether vehicle ignition is ON or OFF), and date and time data indicative of a date and time vehicle operating conditions were logged by the monitoring device. Raw vehicle data transmitted and collected over a period of time forms historical vehicle data which may be stored by the remote subsystem for future analysis of a single vehicle or fleet performance. In practise, a single fleet may comprise many vehicles, and thus large volumes of raw vehicle data (e.g., terabytes, petabytes, exabytes. ) may be transmitted to, and stored by, a remote subsystem. Telematics systems are discussed in further detail below with reference to <FIG>, <FIG>, <FIG> and <FIG>.

Processing historical vehicle data corresponding to positions within a roadway section of interest may provide an alternative technique for obtaining traffic data and/or traffic metrics that avoid some of the drawbacks of existing techniques described in the foregoing. For example, a method for obtaining traffic data and/or traffic metrics from historical vehicle data may include obtaining a location (e.g., boundary coordinates) of a roadway section of interest. For instance, a road agency may store geographic data describing a roadway system comprising the roadway section of interest on a publicly accessible server, such as a server accessible via the Internet. The geographic data may be in the form of a geospatial file (e.g., shape file (. shp), GeoJSON (. geojson)), or other file format, from which geographical coordinates of boundaries delineating roads forming the roadway system may be extracted. In this example, a geospatial file including boundary coordinates of the roadway section of interest is accessed, and latitude, longitude (Lat/Long) coordinates of a plurality of points defining the boundaries thereof are extracted from the geospatial file. Next, a plurality of raw vehicle data instances corresponding to a position within boundaries of the roadway section of interest are selected from the historical vehicle data and processed for providing traffic data and/or traffic metrics relating to the roadway section of interest.

In an exemplary implementation, obtaining traffic data and/or traffic metrics for a roadway section of interest from historical vehicle data includes obtaining and processing vehicle speed data for determining an average speed of vehicles traversing a roadway section of interest. In this example, the roadway section of interest is in the form of a portion of a road (i.e., a road portion. ) Firstly, the location of the road portion is determined. For instance, geographical coordinates of boundaries of the road portion are extracted, for example, from a shape file (. shp) or a GeoJSON file (.

As described in the foregoing, historical vehicle data comprises raw vehicle data instances corresponding to a plurality of vehicles which may be indicative of device ID, vehicle position, speed, and date & time the vehicle position and speed were logged. A subset of raw vehicle data instances corresponding to a location within the boundaries of the road portion are selected from historical vehicle data and a cumulative speed of all vehicles that have traversed the road portion are divided by the number thereof to provide an average speed traffic metric. This is only one method of obtaining traffic data and/or traffic metrics from historical vehicle data and is not intended to limit embodiments to this example.

In practise, locations and/or boundaries of roadway sections of interest are not readily available. For instance, some geographic information systems (GISs), (e.g., geographical information systems available from ESRI® of Redlands, California, USA), and web mapping services (e.g., Google Maps, developed by Google® of Mountain View, California, USA), among others, have compiled geospatial information describing locations, (e.g., boundary information) of roadway systems. However, such systems and services have invested significant resources to do so. For instance, high volumes of different data types are collected via a variety of data collection techniques. This data is then processed to provide geospatial information. Some exemplary data collection techniques include aerial and satellite image capture, video recording, Light Detection and Ranging (LiDAR), road surveying, and crowdsourcing.

In general, implementing similar techniques for obtaining roadway section locations would be time consuming, complex, computationally intensive, and costly. Some web mapping services, (e.g., Google Maps) may provide geospatial roadway-related information, such as Lat/Long coordinates of road boundaries, via interactive maps. However, such functionality is not designed to enable easy extraction of boundary information in large quantities and/or in a suitable machine-readable data format. Alternatively, roadway boundary information may be available in a suitable machine-readable data format a GIS, for example, however, at a cost.

Described herein are alternative techniques for defining locations of roadway sections that may avoid some issues of known techniques described in the foregoing. Upon definition of a location of a roadway section of interest, related traffic data and/or traffic metrics related thereto may be determined by processing raw vehicle data instances corresponding to positions within a roadway section of interest, as described above.

In general, techniques described herein may be used to determine a location of any area frequently used by vehicles. Such areas are discussed in further detail below in reference to <FIG> and <FIG>.

Described herein are various embodiments of systems and methods for defining an area frequently used by vehicles, (i.e., an area on the Earth's surface repeatedly employed by vehicles), hereinafter referred to as a 'vehicle way'. A vehicle way may include an area used by vehicles for movement and/or parking. Specific and non-limiting examples of vehicle ways include traffic-designated areas, such as by road agencies, for channeling traffic flow (e.g., roads, traffic junctions), and for parking (e.g., street parking spaces, commercial parking lots). Vehicle ways may also include areas that are not traffic-designated areas. For instance, areas that have not been created and/or maintained by a road agency or commercial entity for vehicle use, nonetheless are repeatedly used thereby. For example, a vehicle way includes an ad hoc vehicle way. An example of an ad hoc vehicle way includes a beaten path created by frequent flow of vehicles for accessing a natural attraction, such as a lake, river, or forested area, for which no access road was available. Another example of an ad hoc vehicle way includes a portion of a field frequently used to accommodate overflow vehicles of a nearby parking lot.

Illustrated in <FIG> are simplified diagrams of various exemplary types of vehicle ways, including: circular traffic junction <NUM>, (i.e., roundabout) having circular road segment <NUM> and road segments <NUM>, <NUM>, <NUM> and <NUM> for channeling vehicles therethrough; three way traffic junction <NUM> (i.e., intersection) having road segments <NUM>, <NUM>, and <NUM> for channeling vehicles therethrough; traffic junction <NUM> (i.e., highway off-ramp) having road segments <NUM>, <NUM>, and <NUM> for channeling vehicles therethrough; parking lot <NUM>, having parking area <NUM> and entry/exit <NUM> for channelling vehicles in and out thereof; road portion <NUM> having opposing lanes 643a and 643b; and on-street parking space <NUM>. The exemplary vehicle ways of <FIG> are provided for example purposes only and embodiments are not intended to be limited to the examples described herein.

A defined vehicle way may be described by any data format provided the data indicates the location (e.g., the unique location of the vehicle way on the Earth's surface) occupied thereby. For example, a vehicle way may be defined by a plurality of points defining the boundaries of the vehicle way. The geographic coordinates of the plurality of points may be, for example, stored in a text file, such as a comma-separated values (. In another example, boundaries may be described in a geospatial file, for instance a shape file (. shp) or a GeoJSON file (. geojson), from which geographic coordinates of vehicle way boundaries may be obtained. In yet another example, the location occupied by a vehicle way may be described in accordance with a geospatial indexing system, such as Geohash. Geohash is a known public domain hierarchical geospatial indexing system which uses a Z-order curve to hierarchically subdivide the latitude/longitude grid into progressively smaller cells of grid shape. For instance, a Geohash string indicates a unique geographical area (e.g., cell). A vehicle way may be described by data indicative of a plurality of Geohash strings indicating the Geohash cells occupied by the vehicle way. A vehicle way may be described in numerous data formats and embodiments are not intended to be limited to examples described herein.

Some embodiments described herein relate to techniques for defining a vehicle way comprising processing data indicative of vehicle operation conditions of a plurality of vehicles that have travelled within a known area, that is, an area of which the location thereof is defined. Processing such data may provide an indication as to whether the known area is a portion of the vehicle way. In other words, processing such data may provide an indication as to whether the vehicle way occupies the known area.

Processing data may also include processing other data indicative of vehicle operation conditions of another plurality of vehicles that have travelled within other known areas proximate the known area. Furthermore, processing data may also include processing spatial relationship data of the known area to other known areas proximate thereto.

Some embodiments described herein relate to defining a vehicle way by defining a relationship between vehicle operating conditions of vehicles that have operated proximate known areas and the likelihood the known areas are portions of a vehicle way.

Some embodiments described herein relate to techniques for defining a vehicle way using machine learning techniques using historical vehicle data, (e.g., raw vehicle data), and/or data derived therefrom to define the location of the vehicle way.

In example implementations, a traffic analytics system may be configured to access historical vehicle data associated with known areas and define one or more classification models that are related to operating conditions of corresponding vehicles, and then operate in accordance with the one or more models. In general, each such classification model may receive as input, data (i.e., features), derived from historical vehicle data related to vehicles that have operated within a known area, within a plurality of known areas, and a spatial relationship of the known area to the other known areas, and output an indication the known area is a portion of a vehicle way.

As described in the foregoing, a vehicle way includes areas frequently used and/or employed by vehicles. The phrases 'frequently used' and 'repeatedly employed' are relative to the time period of logging of the historical vehicle data. For example, data (i.e., features), derived from historical vehicle data related to vehicles that have travelled within a known area are input to a classification model for use thereof. However, if there is little raw vehicle data corresponding to a vehicle way of interest within the historical vehicle data, the output of the classifier may not provide meaningful data when applied for defining the vehicle way of interest.

Illustrated in <FIG> is a simplified diagram of an exemplary network configuration <NUM> with which some embodiments may operate. Network configuration <NUM> includes telematics system <NUM>, traffic analytics system <NUM>, remote system <NUM>, and communication network <NUM>. Communication network <NUM> may be communicatively coupled to telematics system <NUM>, traffic analytics system <NUM>, and remote system <NUM>, enabling communication therebetween.

For example, traffic analytics system <NUM> may communicate with telematics system <NUM>, and remote system <NUM> for receiving historical vehicle data or a portion thereof via communication network <NUM>. <FIG> is a simplified diagram of network configuration <NUM> illustrating communication path <NUM> between traffic analytics system <NUM> and telematics system <NUM> and communication path <NUM> between traffic analytics system <NUM> and remote system <NUM>.

<FIG> is a simplified diagram of another exemplary network configuration <NUM> with which some embodiments may operate. Network configuration <NUM> includes telematics system <NUM>, traffic analytics system <NUM>, remote system <NUM>, data management system <NUM> and communication network <NUM>. Communication network <NUM> may be communicatively coupled to telematics system <NUM>, traffic analytics system <NUM>, remote system <NUM>, and data management system <NUM>, enabling communication therebetween.

For example, telematics system <NUM> may transmit raw vehicle data and/or historical vehicle data to data management system <NUM> for the storage thereof, as illustrated by communication path <NUM>. Traffic analytics system <NUM> may be configured for communicating with data management system <NUM>, for receiving historical vehicle data or a portion thereof via communication network <NUM>, as illustrated by communication path <NUM>. Traffic analytics system <NUM> may also be configured for communicating with remote system <NUM>.

Remote system <NUM> may be another telematics system from which traffic analytics system <NUM> receives historical vehicle data. Alternatively, remote system <NUM> may store historical vehicle data collected by one or more telematics systems and/or similar vehicle monitoring systems.

Alternatively, remote system <NUM> may provide external data to traffic analytics system <NUM>. For example, remote system <NUM> is a map service provider that provides geospatial information regarding roadway systems, traffic control equipment, and/or jurisdictional boundary information, among other geospatial information to traffic analytics system <NUM>.

In yet another example, remote system <NUM> may be a customer system to which traffic analytics system <NUM> transmits output data in the form of raw data, a web page, or in another data format.

Communication network <NUM> may include one or more computing systems and may be any suitable combination of networks or portions thereof to facilitate communication between network components. Some examples of networks include, Wide Area Networks (WANs), Local Area Networks (LANs), Wireless Wide Area Networks (WWANs), data networks, cellular networks, voice networks, among other networks, which may be wired and/or wireless. Communication network <NUM> may operate according to one or more communication protocols, such as, General Packet Radio Service (GPRS), Universal Mobile Telecommunications Service (UMTS), GSM, Enhanced Data Rates for GSM Evolution (EDGE), LTE, CDMA, LPWAN, Wi-Fi, Bluetooth, Ethernet, HTTP/S, TCP, and CoAP/DTLS, or other suitable protocol. Communication network <NUM> may take other forms as well.

Illustrated in <FIG> is a simplified block diagram of an exemplary telematics system for gathering and storing vehicle operation information. Telematics system <NUM> comprises telematics subsystem <NUM> (e.g., server) having a first network interface <NUM> and onboard monitoring devices <NUM>, <NUM>, and <NUM> communicatively coupled therewith via communication network <NUM>.

Telematics system <NUM> may comprise another network interface <NUM> for communicatively coupling to another communication network, such as communication network <NUM>. Telematics subsystem <NUM> may comprise a plurality of servers, data stores, and other devices, configured in a centralized, distributed or other arrangement.

Also shown in <FIG> are vehicles <NUM>, <NUM> and <NUM>, each thereof having aboard the onboard monitoring devices <NUM>, <NUM>, and <NUM>, respectively. A vehicle may include a car, truck, recreational vehicle, heavy equipment, tractor, snowmobile, or other transportation asset. Onboard monitoring devices <NUM>-<NUM> may transmit raw vehicle data associated with vehicles <NUM>-<NUM>. Raw vehicle data transmitted and collected over a period of time forms historical vehicle data which may be stored by remote subsystem <NUM>.

In practise, a monitoring device is associated with a particular vehicle. For example, during configuration of monitoring devices <NUM>-<NUM>, each thereof may be assigned a unique device ID that is uniquely associated with a vehicle information number (VIN) of vehicles <NUM>-<NUM>, respectively. This enables an instance of received raw vehicle data to be associated with a particular vehicle. As such, vehicle-specific raw vehicle data may be discernable among other raw vehicle data in the historical vehicle data.

Three monitoring devices are described in this example for explanation purposes only and embodiments are not intended to be limited to the examples described herein. In practise, a telematics system may comprise many vehicles, such as hundreds, thousands and tens of thousands or more. Thus, huge volumes of raw vehicle data may be received and stored by remote telematics subsystem <NUM>.

In general, monitoring devices comprise sensing modules configured for sensing and/or measuring a physical property that may indicate an operating condition of a vehicle. For example, sensing modules may sense and/or measure a vehicle's position, (e.g., GPS coordinates), speed, direction, rates of acceleration or deceleration, for instance, along the x-axis, y-axis, and/or z-axis, altitude, orientation, movement in the x, y, and/or z direction, ignition state, transmission and engine performance, among others. One of ordinary skill in the art will appreciate that these are but a few types of vehicle operating conditions that may be detected.

Monitoring device <NUM> may comprise a sensing module for determining vehicle position. For instance, the sensing module may utilize Global Positioning System (GPS) technology (e.g., GPS receiver) for determining the geographic position (Lat/Long coordinates) of vehicle <NUM>. Alternatively, the sensing module utilizes another a global navigation satellite system (GNSS) technology, such as, GLONASS or BeiDou. Alternatively, the sensing module may further utilize another kind of technology for determining geographic position. In addition, sensing module may provide other vehicle operating information, such as speed.

Alternatively, vehicle position information may be provided according to another geographic coordinate system, such as, Universal Transverse Mercator, Military Grid Reference System, or United States National Grid.

In general, a vehicle may include various control, monitoring and/or sensor modules for detecting vehicle operating conditions. Some specific and non-limiting examples include, an engine control unit (ECU), a suspension and stability control module, a headlamp control module, a windscreen wiper control module, an anti-lock braking system module, a transmission control module, and a braking module. A vehicle may have any combination of control, monitoring and/or sensor modules. A vehicle may include a data/communication bus accessible for monitoring vehicle operating information, provided by one or more vehicle control, monitoring and/or sensor modules. A vehicle data/communication bus may operate according to an established data bus protocol, such as the Controller Area Network bus (CAN-bus) protocol that is widely used in the automotive industry for implementing a distributed communications network. Specific and non-limiting examples of vehicle operation information provided by vehicle monitoring and/or sensor modules include, ignition state, fuel tank level, intake air temp, and engine RPM among others.

Monitoring device <NUM> may comprise a monitoring module operable to communicate with a data/communication bus of vehicle <NUM>. Monitoring module may communicate via a direct connection, such as, electrically coupling, with a data/communication bus of vehicle <NUM> via a vehicle communication port, (e.g., diagnostic port/communication bus, OBDII port). Alternatively, monitoring module may comprise a wireless communication interface for communicating with a wireless interface of the data/communication bus of vehicle <NUM>. Optionally, a monitoring module may communicate with other external devices/systems that detect operating conditions of the vehicle.

Monitoring device <NUM> may be configured to wirelessly communicate with telematics subsystem <NUM> via a wireless communication module. In some embodiments, monitoring device <NUM> may directly communicate with one or more networks outside vehicle <NUM> to transmit data to telematics subsystem <NUM>. A person of ordinary skill will recognize that functionality of some modules may be implemented in one or more devices and/or that functionality of some modules may be integrated into the same device.

Monitoring devices <NUM>-<NUM> may transmit raw vehicle data, indicative of vehicle operation information collected thereby, to telematics subsystem <NUM>. The raw vehicle data may be transmitted at predetermined time intervals, (e.g. heartbeat), intermittently, and/or according to other predefined conditions. Raw vehicle data transmitted from monitoring devices <NUM>-<NUM> may include information indicative of device ID, position, speed, ignition state, and date and time operating conditions are logged, for instance, in an onboard data store. One of ordinary skill in the art will appreciate that raw vehicle data may comprise data indicative of numerous other vehicle operating conditions. Raw vehicle data may be transmitted from a monitoring device when a vehicle is moving, stationary, and during both ON and OFF ignition states.

In an exemplary implementation, raw vehicle data received and stored by a subsystem over a period of time forms historical vehicle data. In an exemplary implementation, historical vehicle data may be stored by telematics subsystem <NUM> in a database, such as database <NUM>, as shown. A period of time may include, for example, <NUM> months, <NUM> months, <NUM> months, or another duration of time.

Illustrated in <FIG> there are two exemplary traffic analytics systems <NUM> including traffic analytics system 104a and traffic analytics system 104b, as shown respectively.

<FIG> is a simplified block diagram of exemplary traffic analytics system 104a comprising a processing resource <NUM>, data store <NUM>, and network interface <NUM>. For example, processing resource <NUM> and data store <NUM> may be communicatively coupled by a system communication bus, a wired network, a wireless network, or other connection mechanism and arranged to carry out various operations described herein. Optionally, two or more of these components may be integrated together in whole or in part.

Network interface <NUM> may be interoperable with communication network <NUM> and may be configured to receive data from various network components of the network configuration <NUM>, <NUM> such as telematics system <NUM>, remote system <NUM>, data management system <NUM>, and possibly other network components. Traffic analytics system 104a, 104b may communicate with one or more of these network components for obtaining historical vehicle data, or portions thereof. For instance, once received, data store <NUM> may store subsets of raw vehicle data in a database, such as database <NUM>.

In an exemplary implementation, traffic analytics system 104a is configured to interoperate with data management system <NUM> for obtaining historical vehicle data and/or a portion thereof. For example, data management system <NUM> may manage and store large volumes (e.g., big data) and multiple types of data. Data management system <NUM> may comprise a relational database, for storing historical vehicle data, or a portion thereof, collected by one or more telematics or vehicle monitoring systems. Data management system <NUM> may include a web service that enables interactive analysis of large datasets stored in a remote data store. Traffic analytics system 104a may be configured to interoperate with such a data management system for obtaining raw vehicle data from historical vehicle data stored therein and managed thereby. An example of such a data management system is a managed cloud data warehouse for performing analytics on data stored therein, such as BigQuery™, available from Google® of Mountain View, California, USA.

<FIG> is a simplified block diagram of second exemplary traffic analytics system 104b comprising processing resource <NUM>, data store <NUM>, data management system <NUM> and network interface <NUM>. For example, processing resource <NUM>, data store <NUM>, and data management system <NUM> may be communicatively coupled by a system communication bus, a wired network, a wireless network, or other connection mechanism and arranged to carry out various operations described herein. Optionally, two or more of these components may be integrated together in whole or in part. Data management system <NUM> may comprise a data store including database for storing historical vehicle data or a portion thereof. Optionally data management system <NUM> stores and manages large volumes (e.g., big data) and multiple types of data. For example, data management system <NUM> may comprise a relational database, for storing historical vehicle data collected by one or more telematics or vehicle monitoring systems, or a portion thereof. In another example, database <NUM> of data management system <NUM> stores subsets of raw vehicle data from historical vehicle data for processing by analytics system 104b. Alternatively, data management system <NUM> may include and/or access a web service that enables interactive analysis of large datasets stored in a remote data store. An example of such a data management system is a managed cloud data warehouse for performing analytics on data stored therein, such as BigQuery.

According to an embodiment, exemplary traffic analytics system 104b receives and stores historical vehicle data in data management system <NUM> and operates on subsets of historical vehicle data in accordance with operations described herein.

Processing resource <NUM> may include one or more processors and/or controllers, which may take the form of a general or a special purpose processor or controller. In exemplary implementations, processing resource <NUM> may be, or include, microprocessors, microcontrollers, application specific integrated circuits, digital signal processors, and/or other data processing devices. Processing resource <NUM> may be a single device or distributed over a network.

Data store <NUM> may be or include one or more non-transitory computer-readable storage media, such as optical, magnetic, organic, or flash memory, among other data storage devices and may take any form of computer readable storage media. Data store <NUM> may be a single device or may be distributed over a network.

Processing resource <NUM> may be configured to store, access, and execute computer-readable program instructions stored in data store <NUM>, to perform the operations of traffic analytics system 104a, 104b described herein. For instance, processing resource <NUM> may be configured to receive historical vehicle data and may execute a classification model for defining a vehicle way. Other functions are described below.

Traffic analytics system 104a, 104b may be configured to access, receive, store, analyze and process raw vehicle data for defining a classification model and/or executing a classification model. For example, traffic analytics system 104a, 104b may select and process raw vehicle data of a plurality of vehicles corresponding to a known area, for determining whether the known area is likely to be a portion of a vehicle way. Other examples and corresponding operations are also possible.

In some example implementations, traffic analytics system 104a, 104b may include and/or communicate with a user interface. The user interface may be located remote from traffic analytics system 104a, 104b. For instance, traffic analytics system 104a, 104b may communicate with a user interface via network interface <NUM>.

For the ease of description, traffic analytics system 104a, 104b is shown as a single system, however, it may include multiple computing systems, such as servers, storage devices, and other distributed resources, configured to perform operations/processes described herein. Operations and processes performed by traffic analytics system 104a, 104b described herein may be performed by another similarly configured and arranged system.

In an exemplary implementation, traffic analytics system 104a, 104b is configured to obtain, store and process historical vehicle data. For example, traffic analytics system 104a, 104b obtains first historical vehicle data <NUM> from telematics system <NUM> and stores it in database <NUM>. <FIG> is a conceptual diagram of database <NUM>. In this example, traffic analytics system 104a, 104b organizes first historical vehicle data <NUM> by vehicle, via associated device ID. For instance, datasets <NUM>-<NUM> of database <NUM> comprise raw vehicle data indicative of vehicle operation information of vehicles <NUM>-<NUM>, respectively.

Shown in <FIG> is a conceptual diagram of dataset <NUM>. In this example, each row thereof represents a first raw vehicle data instance <NUM> indicative of vehicle operation information collected by monitoring device <NUM> at different points in time. First raw vehicle data instances <NUM> of dataset <NUM> are organized sequentially in time, from DT0 to DT5. In this example, a first raw vehicle data instance <NUM> includes device ID data, speed data, position data, (e.g., LAT/LONG), ignition state data, and date and time data, (e.g., timestamp), as shown.

Now referring to <FIG>, shown is a conceptual diagram of vehicle <NUM>'s path <NUM> within geographic area <NUM> corresponding to vehicle position data <NUM> of dataset <NUM>. Vehicle-position data points <NUM> represents a position of vehicle <NUM> at different points in time, DT0-DT5. As shown, the position of vehicle <NUM> changes position at each temporally subsequent point in time.

For ease of description, database <NUM> comprising first historical vehicle data <NUM> is described as organized into vehicle-specific datasets <NUM>-<NUM>. One of ordinary skill appreciates that historical vehicle data may be organized in numerous manners.

An intelligent telematics system includes aspects of a telematics system and a traffic analytics system, such as, telematics system <NUM> and traffic analytics system 104a, 104b.

<FIG> is a simplified diagram of an alternative embodiment with which some embodiments may operate. Shown in <FIG> is intelligent telematics system 500a comprising onboard monitoring devices <NUM>, <NUM>, and <NUM>, telematics subsystem <NUM> (e.g., server), traffic analytics system 104a, communicatively coupled via communication network <NUM>. Intelligent telematics system 500a may also include network interface <NUM> compatible for interfacing with a communication network for communicating with other network components. For example, network interface <NUM> may be interoperable with communication network <NUM> and may be configured to receive data from various network components of the network configuration <NUM>, <NUM> such as remote system <NUM>.

In this example monitoring devices <NUM>-<NUM> may be configured to wirelessly communicate with telematics subsystem <NUM> via a wireless communication module. In some embodiments, monitoring devices <NUM>-<NUM> may directly communicate with one or more networks outside respective vehicles to transmit data to telematics subsystem <NUM>. A person of ordinary skill will recognize that functionality of some modules may be implemented in one or more devices and/or that functionality of some modules may be integrated into the same device.

Monitoring devices <NUM>-<NUM> may transmit raw vehicle data, indicative of vehicle operation information collected thereby, to telematics subsystem <NUM>, as represented by communication path <NUM>. In an exemplary implementation, raw vehicle data received and stored by telematics subsystem <NUM> over a period of time forms historical vehicle data. For instance, historical vehicle data may be stored by telematics subsystem <NUM> in database <NUM>. A period of time may include, for example, <NUM> months, <NUM> months, <NUM> months, or another duration of time. In an exemplary embodiment, subsets of raw vehicle data selected from historical vehicle data stored in database <NUM> may be stored in another database, for instance, database <NUM> for processing by traffic analytics system 104a. In this example raw vehicle data is transmitted by telematics subsystem <NUM> and received by traffic analytics system 104a via communication path <NUM>, as shown.

<FIG> is a simplified diagram of another alternative embodiment with which some embodiments may operate. Shown in <FIG> is intelligent telematics system 500b comprising onboard monitoring devices <NUM>, <NUM>, and <NUM> and traffic analytics system 104b, communicatively coupled therewith via communication network <NUM>.

Intelligent telematics system 500b may also include network interface <NUM> compatible for interfacing with a communication network for communicating with other network components. For example, network interface <NUM> may be interoperable with communication network <NUM> and may be configured to receive data from various network components of the network configuration <NUM>, <NUM>, such as remote system <NUM>.

In this example monitoring devices <NUM>-<NUM> may be configured to wirelessly communicate with traffic analytics system 104b via a wireless communication module. In some embodiments, monitoring devices <NUM>-<NUM> may directly communicate with one or more networks outside respective vehicles to transmit data to traffic analytics system 104b. A person of ordinary skill will recognize that functionality of some modules may be implemented in one or more devices and/or that functionality of some modules may be integrated into the same device.

Monitoring devices <NUM>-<NUM> may transmit raw vehicle data, indicative of vehicle operation information collected thereby, to traffic analytics system 104b via communication path <NUM>, as shown. In an exemplary implementation, raw vehicle data received and stored by traffic analytics system 104b over a period of time forms historical vehicle data. For instance, historical vehicle data may be stored by traffic analytics system 104b in database <NUM> in data management system <NUM>. A period of time may include, for example, <NUM> months, <NUM> months, <NUM> months, or another duration of time. In an exemplary embodiment, subsets of raw vehicle data selected from historical vehicle data stored in database <NUM> may be stored in another database, for instance, database <NUM> for processing by traffic analytics system 104b. In this example raw vehicle data is transmitted by telematics subsystem <NUM> and received by traffic analytics system 104a. Traffic analytics system 104b may be configured to perform operations of telematics system <NUM> as described herein.

In some example implementations, intelligent telematics system 500a, 500b may be configured to include and/or communicate with a user interface. The user interface may be located remote therefrom. For instance, intelligent telematics system 500a, 500b may communicate with a user interface via network interface <NUM>.

According to an embodiment, a classifier defining a relationship between operation of a plurality of vehicles having operated in a known area and a probability the known area is a portion of a vehicle way may be defined by processing corresponding historical vehicle data. For example, such processing may provide features (e.g., data indicative of variables/attributes, or measurements of properties) of the known area. A machine learning algorithm may be trained with training data comprising features to recognize patterns therein and generalize a relationship between the features and an outcome that the known area is occupied by the vehicle way.

Shown in <FIG> is a flow diagram of a process <NUM> for defining a classifier for use in defining a vehicle way according to some embodiments. In particular, a classifier is for providing an indication that a known area is, or is not, a portion of a vehicle way. A classifier may provide as output a likelihood (e.g., probability) a known area is a portion of a vehicle way. Alternatively, a classifier may output an indication (e.g., binary value) that a known area is, or is not, a portion of a vehicle way.

Process <NUM> is described below as being carried out by traffic analytics system 104a. Alternatively, process <NUM> may be carried out by telematics-analytic system 104b, intelligent telematics system 500a, 500b, another system, a combination of other systems, subsystems, devices or other suitable means provided the operations described herein are performed. Process <NUM> may be automated, semi-automated and some blocks thereof may be manually performed.

Process <NUM> begins at block <NUM>, wherein a plurality of sample vehicle ways is identified. According to an embodiment, a classifier may be defined according to a type and/or subtype of vehicle way that is to be defined using the classifier. Specific and non-limiting examples of types of vehicle ways include, traffic junctions, road segments, parking lots, and ad hoc vehicle ways. Specific and non-limiting examples of subtypes of vehicle ways include: subtypes of traffic junctions, including roundabouts, intersections, on-ramps, and off-ramps; subtypes of parking lots including single entry and single exit parking lots, single entry and multiple exit parking lots, and multiple entry and single exit parking lots; and subtypes of road segments including one way, two way, multi-lane, and divided highways. A subtype may be considered another type of vehicle way. A subtype may be considered another type of vehicle way. Block <NUM> will be further described below in reference to <FIG>.

In an exemplary implementation, a plurality of sample vehicle ways of only parking lot type is identified for defining a classifier for use in defining parking lots. In another exemplary implementation, a plurality of sample vehicle ways for defining a classifier for use in defining a vehicle way in the form of a traffic junction comprises traffic junctions only. For example, the plurality of sample vehicle ways may include one or more of the following traffic junctions, <NUM>-way intersections, <NUM>-way intersections, n-way intersections, roundabouts, and any other portion of a road system where multiple roads intersect allowing vehicular traffic to change from one road to another.

Alternatively, a plurality of sample vehicle ways for defining a classifier for use in defining a subtype of a traffic junction in the form of an intersection only comprises intersections (e.g., <NUM>-way intersections, <NUM>-way intersections). Defining a classifier for use for defining a particular type or subtype of vehicle way may provide a more accurate classifier.

Furthermore, a classifier defined with sample vehicle ways of only one type and/or one subtype of vehicle way may be suitable for use in defining vehicle ways of a different type and/or subtype of vehicle way.

Alternatively, a classifier may be defined for defining all types of vehicle ways.

In an exemplary implementation, a classifier for use in defining a vehicle way in the form of an intersection is defined according to process <NUM>. In <FIG>, shown is a simplified diagram of area <NUM> comprising a roadway system including a plurality of sample vehicle ways in the form of sample intersections 802a-802f. Area <NUM> also comprises parking lots <NUM>, roadway sections <NUM>, and non-traffic designated areas <NUM> (e.g., greenspace, sidewalks). For ease of description, only six sample intersections are described in this example. In practise, however, the number of sample vehicle ways may include other than six sample vehicle ways.

In this example, sample intersections 802a-802f are also shown to be part of the same roadway network. However, sample vehicle ways may be selected from different roadway systems located in different cities, countries and/or continents. One of ordinary skill in the art appreciates that selection of an appropriate number and type(s) of sample vehicle ways will become apparent during definition (e.g., training and verification) of the classifier.

Once a plurality of sample vehicle ways has been identified, a plurality of associated zones for each of the plurality of sample vehicle ways, is defined in block <NUM>. Block <NUM> will be further described below in reference to <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>.

A zone includes an area encompassing an associated vehicle way. For example, shown in <FIG> is a conceptual diagram of elements of a vehicle way, including a bridge element <NUM> coupled to an employed element <NUM>. For instance, bridge element <NUM> comprises an area for traversal of a vehicle for transitioning therefrom to employed element <NUM>. Employed element <NUM> comprises an area in which the vehicle manoeuvres, such as for moving and/or parking. A vehicle way may have one or more of each of bridge elements and employed elements.

Shown in <FIG> are conceptual diagrams of some specific and non-limiting examples of zones encompassing the vehicle ways of <FIG>.

For example, zone <NUM> encompasses circular traffic junction <NUM>. Elements of circular traffic junction <NUM> include bridge elements <NUM> of road segments <NUM>-<NUM> and employed element <NUM> of circular road segment <NUM>. A vehicle traverses one of bridge elements <NUM> to enter (i.e., transition into) employed element <NUM>. Once inside employed element <NUM>, the vehicle moves therethrough (i.e., maneuvers) and exits (i.e., transitions) employed element <NUM> via a bridge element <NUM>. In this example circular traffic junction <NUM> comprises four bridge elements <NUM> and one employed element <NUM>.

Zone <NUM> encompasses intersection <NUM>. Elements of intersection <NUM> includes three bridge elements <NUM> for instance, road segments <NUM>, <NUM>, and <NUM> and one employed element <NUM> where road segments <NUM>, <NUM> and <NUM> intersect.

Zone <NUM> encompasses traffic junction <NUM>. Elements of traffic junction <NUM> includes two bridge elements <NUM> including off-ramp portion <NUM> and main road <NUM> portion and one employed element such as off-ramp portion <NUM>.

Zone <NUM> encompasses parking lot <NUM>. Elements of parking lot <NUM> includes a bridge element <NUM> of entry/exit <NUM> and an employed element <NUM> including parking area <NUM>.

Zone <NUM> encompasses road portion <NUM>. Elements of road portion <NUM> includes two bridge elements <NUM> of road portions <NUM> and an employed element <NUM> of road portion <NUM>.

Zone <NUM> encompasses a bridge element <NUM> of on-street parking space <NUM> and an employed element <NUM> of on-street parking space <NUM>.

In some instances, elements may include physical boundaries of a road surface such as a sidewalk, road shoulder, and lane divider, among others. In other instances, a vehicle way may not have any physical boundaries, such as a beaten path created by frequent flow of vehicles for accessing a natural attraction as described above.

One of ordinary skill in the art appreciates that the dimensions of a zone is selected to encompass and include elements of a vehicle way. A dimension that is too small and does not include the elements, or includes partial elements, of a vehicle way should be avoided. For example, referring to <FIG>, shown is zone <NUM> encompassing partial elements of intersection <NUM> - only portions of bridge elements <NUM> and employed element <NUM>. In this instance, as zone <NUM> encompasses an insufficient portion of intersection <NUM>, only a portion of historical vehicle data associated therewith will be processed for defining a classifier. As such, the performance of the defined classifier may be poor.

Alternatively, a dimension that is too large should also be avoided. For instance, a zone should be large enough to encompass a vehicle way, however, not too large such that it includes extraneous areas. For example, a zone that is too large may result in unnecessary processing of extraneous historical vehicle data. Furthermore, dimensions of a zone may affect computing resources and processing time for defining and/or using a classification model. One of ordinary skill will appreciate that optimal zone dimensions will become apparent during definition of the classifier.

Continuing at block <NUM>, each zone encompassing a vehicle way comprises a plurality of contiguous known areas, also referred to herein as subzones. Each subzone may have boundaries defined in accordance with a geographic coordinate system representing a unique two-dimensional space on the Earth's surface. For example, a zone may be partitioned by subdividing the zone into a grid of contiguous subzones bound by pairs of latitude and longitude lines. As such, the unique location of each subzone known. Each subzone in the plurality of contiguous subzones within a zone shares a boundary with at least one other subzone. The plurality of contiguous subzones serves to facilitate organization of all points therein as each subzone comprises an aggregate of a portion of points within a zone. A point located within boundaries of a subzone may be uniquely associated therewith.

Optionally, a subzone may include a portion of a vehicle way overlapping another portion of a vehicle way. For instance, the subzone may represent a portion of an overpass that overlaps a portion of a roadway thereunder. Optionally, a subzone may include a portion of a vehicle way overlapped by another portion of a vehicle way. For instance, the subzone may represent a portion of a roadway that is overlapped by a portion of an overpass.

In some exemplary implementations, zone dimensions may be determined according to the shape and size of an associated vehicle way. <FIG> is a simplified diagram of a plurality exemplary zones 908a-908f defined for sample intersections 802a-802f, respectively. In this example, the dimensions of each zone are such that the elements of each associated vehicle way are encompassed thereby. As sample vehicle ways, e.g., sample intersections 802a-802f vary relatively in shape and size, so may respective zones 908a-908f.

Each of the plurality of zones 908a-908f is partitioned into a plurality of contiguous subzones 910a-910f. For instance, each of zones 908a-908f may be subdivided into a grid of contiguous subzones bound by pairs of latitude and longitude lines. As each of zones 908a-908f may be different in dimension, each thereof may comprise a different number of subzones 910a-910f, as shown. For example, zone 908b is smaller than zone 908f and accordingly, has fewer subzones 910b than the number of subzones 910f in zone 908f.

In some embodiments geographic coordinate data of a location (e.g., LAT/LONG) of a reference point proximate each of the sample vehicle ways is obtained by traffic analytics system 104a. A reference point indicates a general area in which a vehicle way may be located.

In an exemplary implementation, a user may view a georeferenced map of area <NUM> on a display and manually identify a reference point proximate sample intersection 802a. For instance, the georeferenced map may be accessed via a web page of an online map service, such as a Google Maps. The user may choose reference point 803a on or near sample intersection 802a, as shown in <FIG>. The location of reference point 803a may be obtained, by the user selecting point 803a on the georeferenced map with a pointer, causing text indicating geographic coordinates, (e.g., LAT/LONG), thereof to appear on the display. Alternatively, a location of a reference point proximate a vehicle way may be obtained through use of a GPS enabled device or another geographic coordinate sensing device. One of ordinary skill in the art appreciates that there are various ways to obtain a location of a point. Point data indicative of the location of reference point 803a may be provided to traffic analytics system 104a, for example, via a user interface or data file accessed by traffic analytics system 104a. The reference point may be at or near the centre point of a zone.

In an exemplary implementation, a zone may be defined by subdividing a reference area into a grid of contiguous subzones according to a hierarchical geospatial indexing system, such as Geohash. Geohash is a known public domain hierarchical geospatial indexing system which uses a Z-order curve to hierarchically subdivide the latitude/longitude grid into progressively smaller cells of grid shape. Each cell is rectangular and represents an area bound by a unique pair of latitude and longitude lines corresponding to an alphanumeric string, known as a Geohash string and/or Geohash code.

In a Geohash system the size of a cell depends on a user defined length of a string. The hierarchical structure of Geohash grids progressively refines spatial granularity as the length of string increases. For example, shown in <FIG> is table <NUM> defining the relationship between string length and approximate cell dimensions. As string length increases, cell dimensions decrease, as shown. Cell size is also influenced by a cell's longitudinal location. Cell width reduces moving away from the equator (to <NUM> at the poles) due to the nature of longitudinal lines converging as they extend away therefrom. Table <NUM> provides an approximation of Geohash cell dimensions located along the equator.

Some exemplary Geohash system functions will now be described below in reference to <FIG>. <FIG> is a simplified conceptual diagram of cell <NUM>, defined by latitude and longitude lines <NUM> and <NUM>, respectively. Shown in <FIG> is a simplified functional block diagram of an exemplary Geohash encode function <NUM>, for mapping a point to a cell. For example, LAT/LONG coordinates, '<NUM>, - <NUM>,' of point <NUM> of <FIG> and a user defined length = <NUM> are input to encode function <NUM> which maps point <NUM> to cell <NUM>. Encode function <NUM> outputs string 'ezs42' corresponding to cell <NUM> having dimensions <NUM> × <NUM>. One of ordinary skill appreciates that encode function <NUM> will map any point within cell <NUM> to the same string, 'ezs42.

<FIG> is a simplified functional block diagram of an exemplary Geohash decode function <NUM> for resolving a string to the centre point of the corresponding cell. For example, string 'ezs42' is input to decode function <NUM> and decoded to cell <NUM> centre point <NUM> at LAT/LONG coordinates '<NUM>, -<NUM>. ' In contrast to encode function <NUM>, decode function <NUM> resolves an input string to LAT/LONG coordinates of one point only, specifically, the centre point of the corresponding cell.

<FIG> is a simplified functional block diagram of an exemplary Geohash bounds function <NUM> for resolving a string into °N/°S, °W/°E line pairs that bound the corresponding cell. For example, string 'ezs42' is input to bounds function <NUM> which outputs (<NUM>°N, <NUM>°N), (-<NUM>°E, -<NUM>°E) line pairs bounding cell <NUM>, as shown in <FIG>.

<FIG> is a simplified functional block diagram of an exemplary Geohash neighbours function <NUM> for determining the closest <NUM> neighbouring (e.g., adjacent) cells to a given cell. For example, string 'ezs42' is input into neighbours function <NUM> which outputs strings of the closest <NUM> neighbouring cells at relative positions NW, W, NE, W, E, SW, S, and SE to cell <NUM>. <FIG> is a simplified conceptual of cell <NUM> and its <NUM> closest neighbouring cells <NUM>.

In an exemplary implementation, each of the plurality of zones 908a-908f of <FIG> is partitioned into a plurality of contiguous subzones 910a-910f, respectively, in the form of Geohash cells. As mentioned above, sample vehicle ways may be selected from various locations and thus may be located at different longitudes. As such, dimensions of Geohash cells across a plurality of zones may differ at different longitudes.

In some exemplary implementations, zone dimensions may be dependent on dimensions that are likely to encompass most vehicle ways to be defined using a classifier. For example, shown in <FIG>, is a simplified diagram of a plurality of reference areas 1008a-1008f of a same dimension defined for sample intersections 802a-802f, respectively. Dimensions of reference areas 1008a-1008f are approximated to encompass most intersections within an intersection population that may be defined by a classifier. In this example, reference areas 1008a-1008f are circular in shape having a radius R. In some instances, a reference area may be defined relative to the location of the reference point of the vehicle way. For instance, reference areas 1008a-1008f are centred about reference points 803a-803f of sample intersections 802a-802f. Accordingly, reference areas 1008a-1008f are defined by radius R extending from the reference points 803a-803f respectively.

In an exemplary implementation, the inventor determined a reference area defined radially <NUM> from the reference point encompasses most intersections within an intersection population of interest whilst avoiding extraneous areas.

As noted above, for a plurality of different types and/or subtypes of vehicle ways a plurality of classifiers may be defined. As such, optimal zone dimensions may vary according to the classifier. One of ordinary skill will appreciate that an optimal zone dimensions will become apparent during definition of the classifier.

<FIG> is a simplified conceptual diagram of a plurality of exemplary zones 1010a-1010f imposed on sample intersections 802a-802f, each comprising a plurality of contiguous subzones 1011a-1011f. In this example, reference areas 1008a-1008f of <FIG> are partitioned into a plurality of contiguous subzones in the form of Geohash cells. <FIG> is a flow diagram of one exemplary process <NUM> for subdividing a reference area into a grid of Geohash cells.

Subdividing a reference area into a grid of Geohash cells process <NUM> begins at block <NUM> wherein a reference point of a sample vehicle way is mapped to a Geohash cell. For example, LAT/LONG coordinates of reference point 803a is input into encode function <NUM> and the corresponding Geohash string is output thereby. Shown in <FIG> is a simplified diagram of reference area 1008a, including reference point 803a and cell <NUM>, the Geohash cell to which reference point 803a was mapped. Geohash cell <NUM> serves as a centre cell from which a grid of contiguous Geohash cells for subdividing reference area 1008a is formed.

Next at block <NUM>, a plurality of Geohash neighbours of the centre cell is determined. For instance, the Geohash string of the centre cell <NUM> is input to neighbours function <NUM>, and corresponding strings of neighbour cells <NUM> of Geohash cell <NUM> are output. <FIG> is a simplified conceptual diagram of centre cell <NUM> and its <NUM> closest neighbouring cells <NUM>. Block <NUM> repeats a similar step of determine neighbouring cells of neighbouring cells until reference area 1008a is completely subdivided into a grid of contiguous Geohash cells, as shown in <FIG>. Block <NUM> may utilize Geohash bounds function <NUM> to determine when to stop process <NUM>. For example, coordinates for the boundary of reference area <NUM> may be input into bounds function <NUM> to determine which Geohash cells in the grid include the boundary. Once the entire boundary is within a Geohash process <NUM> may stop. One of ordinary skill appreciates that there are other methods to manipulate or divide space using a Geohash system.

Once reference areas are partitioned into a plurality of contiguous subzones, the associated zone may be defined by peripheral edges of the plurality of contiguous subzones. For instance, once reference areas 1008a-1008f are defined, they are partitioned into a plurality of contiguous subzones 1010a - 1010b and the peripheral edges <NUM> of each thereof define zones 1011a-1011f.

In general, subzones are not limited to a particular dimension, size or shape. However, these attributes may affect processing time and resources for defining and/or using a classification model. For instance, higher precision subzones, will increase the number of subzones for processing in comparison to lower precision subzones for a given zone.

Embodiments described herein are not limited to partitioning a zone with Geohashes. For example, a zone may be partitioned according to another hierarchical geospatial indexing system, e.g., H3 - Uber's Hexagonal Hierarchical Spatial Index, or other system. Alternatively, a zone may be partitioned according to another method for subdividing geographical space.

One of skill in the art will appreciate that a zone may be defined in multiple ways. For instance, a plurality of contiguous subzones may be defined by creating a zone of a shape unique to a corresponding sample vehicle way, as shown in <FIG>. In another instance, a reference area may be partitioned into a plurality of contiguous subzones to create a zone, as shown in <FIG>. The methods for defining a zone described herein are examples only and are not intended to limit embodiments.

According to some embodiments, for each of the plurality of zones, subzone data may be formed. For each subzone, subzone data may comprise information indicating a unique identifier and location (e.g., geographic coordinates of boundaries) of the subzone. Subzone data may also comprise information indicating the closest neighbours of the subzone and/or other subzone related information.

<FIG> is a simplified conceptual diagram of exemplary subzone data <NUM> formed for zone 1010a. In this example subzone data <NUM> comprises Geohash string data which serves as a unique identifier of each subzone. As described above, the location of a Geohash cell (i.e. subzone) may be determined from a Geohash string, such as by inputting a Geohash string into Geohash system bounds function <NUM>.

Alternatively, subzone data may comprise unique ID data which serves as a unique identifier of each subzone and boundary coordinates of boundaries thereof, such as LAT/LONG pairs. For example, <FIG> is a simplified conceptual diagram of subzone data <NUM> formed for zone 1010a comprising Geohash string data which serves as a unique identifier of each subzone and LAT/LONG pairs defining boundaries of each Geohash.

Optionally, subzone data may include information indicative of a Geohash cell's <NUM> closest neighbours.

In some instances, two or more of a plurality of zones may overlap, for example, zones 1010d and 1010f of <FIG>. However, in such instances, a subzone within more than one zone may skew training and/or output of a classification model. For example, vehicle data associated with subzones within multiple zones may be overrepresented in training and result in a biased classifier.

Next, at block <NUM>, a subzone common to multiple zones may be associated with a unique zone and then each of the multiple zones is redefined to include a new unique plurality of subzones. For example, subzone data of the multiple zones are modified in accordance with the redefinition thereof. Block <NUM> will be described in further detail below with reference to <FIG>, <FIG>, and <FIG>.

In an exemplary implementation, the distance between the common subzone and each of the centre subzones of the multiple zones is calculated. The common subzone is uniquely associated with the zone having a centre subzone that is the shortest distance thereto.

For example, shown in <FIG>, is a simplified conceptual diagram of zones 1010d and 1010f comprising centre subzones <NUM> and <NUM> respectively, and a plurality of common subzones located within overlapping portion <NUM> thereof. <FIG> is an enlarged view of a portion of zones 1010d and 1010f comprising overlapping portion <NUM> that includes subzone <NUM>. Distance D1 between common subzone <NUM> and centre subzone <NUM> of zone 1010d is shorter than distance D2 between common subzone <NUM> and centre subzone <NUM> of zone 1010f, as shown. As such, common subzone <NUM> is uniquely associated with zone 1010d and zone 1010f is redefined to not include common subzone <NUM>. Each subzone within portion <NUM> is analyzed and then uniquely associated with one of zones 1010d and 1010f followed by the redefinition thereof. <FIG> is a simplified conceptual diagram of redefined zones 1010d and 1010f.

<FIG> is a simplified conceptual diagram of zone 1010a comprising vehicle-position data points <NUM> representing positions of vehicles indicated by raw vehicle data. Now referring to <FIG>, shown is an enlarged view of portion <NUM> of area <NUM> imposed on the diagram of <FIG>. Vehicle-position data points <NUM> are present within sample vehicle way 802a, areas <NUM> in parking lots <NUM>, portion <NUM> of side street <NUM>, as well as in portions <NUM> of green space areas <NUM>, as shown. Vehicle-position data points found in portions <NUM> may be due to GPS error or other position sensing technology error. As described above, a classifier for identifying subzones as portions of a vehicle way will be defined based on raw vehicle data associated with the subzones and corresponding zone. <FIG> illustrates how vehicle traffic may be dispersed in a zone in practise. However, a classifier may be used to identify only those subzones that are occupied by the vehicle way based on raw vehicle data associated with the entire zone.

<FIG> shows an enlarged view of portion <NUM> of area <NUM> comprising sample intersection 802a and paths <NUM>, <NUM> and <NUM> of one or more vehicles that have traversed therethrough. A same vehicle may have traversed sample intersection 802a at three different time intervals. Alternatively, three unique vehicles may have traversed sample intersection 802a. Paths <NUM>, <NUM> and <NUM> may be have been traversed by any combination of one or more vehicles.

Now referring to <FIG>, shown is conceptual diagram of zone 1010a and vehicle position-data points <NUM> representing position data of raw vehicle data instances that correspond to a position along paths <NUM>, <NUM> and <NUM>. As shown in <FIG>, no vehicle-position data points correspond to path <NUM>. Data collected by a monitoring device when inside a zone may depend on various factors, such as, the frequency a monitoring device collects operation information, the size of the zone, or other predefined criteria for collecting data, among others. As a result, there may be instances when a monitoring device collects little-to-no data when traversing a zone. Accordingly, there may be occasions when selecting raw vehicle data based on vehicle position data indicating a position within a zone may not provide enough meaningful information that relates to all vehicles that have entered the zone. It would be advantageous to maximize information available in historical vehicle data related to vehicles that have entered a zone.

Next, at block <NUM>, a subset of raw vehicle data associated with each of the plurality of zones is selected from historical vehicle data. In an exemplary implementation, traffic analytics system 104a may access historical vehicle data, such as historical vehicle data in database <NUM>, for selecting the subset stored by traffic analytics system 104a via communication network <NUM>.

According to an embodiment, the subset of raw vehicle data may be selected based on positions inside a zone. Optionally, the subset of raw vehicle data may be selected based on positions inside and outside the zone. <FIG> illustrates vehicle position-data points corresponding to positions within portion <NUM> of area <NUM>. Including raw vehicle data corresponding to positions both inside and outside zone 1010a in the subset enables inclusion of raw vehicle data corresponding to the positions on path <NUM>, represented by vehicle-position data points <NUM>. This also enables inclusion of more raw vehicle instances corresponding to paths <NUM> and <NUM>, represented by vehicle-position data points <NUM>.

Next, in block <NUM> interpolating data instances from the subset of raw vehicle data may be performed. For example, <FIG> illustrates vehicle-position data points <NUM> corresponding to interpolated data instances. Selecting raw vehicle data corresponding to locations inside and outside a zone, at block <NUM>, and then interpolating data therefrom at block <NUM>, may provide more meaningful data for the purpose of training a machine learning algorithm in comparison to training based on raw vehicle data instances corresponding to locations inside a zone only. Block <NUM> is described further below with reference to <FIG>, <FIG>, and <FIG>.

Optionally, data instances are interpolated in dependence on the dimensions of subzones of a zone. For example, interpolating data such that there is one of an interpolated instance or raw vehicle data instance corresponding to a position in each subzone along a given path of a vehicle. Referring to <FIG>, shown is a conceptual diagram of zone 1010a comprising plurality of subzones 1011a of approximate dimension <NUM> x <NUM>. In this example, data instances are interpolated such that there is at least one of an interpolated instance or raw vehicle data instance corresponding to a location in each subzone.

Alternatively, data may be interpolated from raw vehicle data corresponding to positions only inside a zone. Such as interpolated data instances corresponding to vehicle-position data points <NUM>, along portions <NUM> and <NUM> of paths <NUM> and <NUM>, as shown in <FIG>.

Alternatively, there may be a sufficient amount of meaningful raw vehicle data corresponding to locations inside a zone that selecting raw vehicle data corresponding to locations outside a zone is unnecessary. Alternatively, there may be a sufficient amount of meaningful raw vehicle data in historical vehicle data that interpolation is unnecessary.

According to some embodiments, the subset of raw vehicle data associated with a zone comprises raw vehicle data corresponding to positions within a traffic zone. In some instances, a traffic zone may encompass a unique zone. In other instances, a traffic zone may encompass more than one zone. <FIG> is a simplified diagram of an exemplary implementation of traffic zone <NUM> encompassing zones 1010a-1010f. For instance, geographic coordinates of boundaries <NUM> of traffic zone <NUM> are provided to traffic analytics system 104a for defining traffic zone <NUM>.

<FIG> is a simplified block diagram of process 1800a for obtaining data, hereinafter referred to as vehicle data, for generating features. Vehicle data may be indicative of vehicle operating conditions for a plurality of corresponding vehicles. As mentioned above, such data may be a subset of raw vehicle data selected from first historical vehicle data <NUM> that corresponds to a location within a zone and/or traffic zone. For example, boundary data <NUM> comprises zone boundary data and/or traffic zone data indicative of locations of boundaries of a zone and/or a traffic zone, respectively. In block <NUM>, raw vehicle data is selected from first historical vehicle data <NUM> based on boundary data <NUM> to form first vehicle data <NUM>.

<FIG> is a simplified block diagram of an alternative process 1800b for obtaining vehicle data for generating features. Such data may be a subset of raw vehicle data selected from first historical vehicle data <NUM> that corresponds to a location within a zone and/or traffic zone. For example, boundary data <NUM> comprises zone boundary data and/or traffic zone data indicative of locations of boundaries of a zone and traffic zone, respectively. In block <NUM>, raw vehicle data is selected from first historical vehicle data <NUM> based on boundary data <NUM>. Next, in block <NUM>, data is interpolated from the raw vehicle data selected in block <NUM> and first vehicle data <NUM> comprising the raw vehicle data and the data interpolated therefrom is formed.

Optionally, raw vehicle data selected from first historical vehicle data <NUM> may be selected based on date and time operating conditions are logged. For instance, raw vehicle data corresponding to a particular date and/or time range is selected. For example, only raw vehicle data collected over the last <NUM> months may be selected.

Optionally, at block <NUM>, the selected data is pre-processed, the selected data is pre-processed, such as, by removing outliers (e.g., unlikely speed values), duplicate values, and the like.

Next, in block <NUM>, features for each of the plurality of subzones of each of the plurality of zones are extracted from vehicle data. Features of the types described herein may include features that are present in a vehicle data instance or a subset of vehicle data instances and/or features derived therefrom. Features present in an instance or a subset of instances may include numeric values that are explicitly set out therein. Specific and non-limiting examples of such features include, a minimum or maximum numeric value in the subset (where a minimum/maximum may be absolute and/or relative). The minimum or maximum data value may require some analysis, such as a comparison of values, but the minimum/maximum value itself will be a value found within the subset. For instance, a plurality of vehicle data instances in a vehicle data subset may be analyzed to determine a maximum speed of the subset. Block <NUM> is further described below with reference to <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>.

Derived features may describe an instance or subset of vehicle data instances, but include a value not found therein. Instead, a value of a derived feature may be derived from the instance or subset, such as obtained through performing one or more computations on the instance or subset. Specific and non-limiting examples of derived features include average speed, total number of vehicle visits and ignition ratio. Optionally, a derived feature may describe a first derived feature forming a second derivative of the first derived feature. Additional derivatives of features may also be possible.

The features may additionally or alternatively be derived from the performance of one or more statistical computations on a vehicle data subset. For instance, a derived feature that may be employed may include standard deviation, mean, and median of values found in a vehicle data subset. For example, standard deviation, mean, and/or median of speed values of vehicles that have traversed a subzone. Features will be described in greater detail below.

The features may be prepared for use in training the model, for instance, by traffic analytics system 104a. Preparing the data may include various functions such as removing outliers (e.g., unlikely speed values), duplicate values, and the like.

<FIG> is a conceptual block diagram of a feature extraction function for generating features from vehicle data. In block <NUM>, a subset of vehicle data for each of the plurality of subzones of the plurality of zones may be selected from vehicle data based on subzone data. Once selected, the subset of vehicle data is analyzed and/or computations are performed thereon to extract/generate subzone features <NUM>. For each subzone in each zone, a plurality of features is generated. These features may be used to identify patterns in the features by a machine learning algorithm during training for defining a classifier.

For example, a subset of vehicle data is be selected from first vehicle data <NUM> based on subzone data <NUM> for each of the plurality of subzones of zones 1010a-1010f. Once selected, the subset of vehicle data instances is analyzed and/or computations are performed thereon to extract/generate features <NUM>. For instance, for each Geohash in zones 1010a-1010f, a plurality of features, (e.g., F1-Fn) are generated. <FIG> is an exemplary table <NUM> representing data comprising a plurality of features for each Geohash.

According to an embodiment, a plurality of subzone-related features is based on and/or derived from a subset of vehicle data associated with each subzone.

In a first exemplary implementation, the subset is a first subset of vehicle data corresponding to a position within a subzone. Subzone-related features indicate measurements/attributes of vehicle operating conditions of at least one vehicle that has operated in the subzone.

For example, <FIG> is a conceptual diagram of portion <NUM> of zone 1010a as demarcated by line 1250A-1250A of <FIG>. Portion <NUM> comprises subzone <NUM>, as shown. An enlarged view of subzone <NUM> is depicted in <FIG> comprising vehicle-position data points <NUM> each thereof indicative of a position of one or more vehicles that have entered subzone <NUM> at one point in time.

Illustrated in <FIG> is a simplified functional block diagram of a function that may be implemented at block <NUM>. First vehicle data <NUM> and subzone <NUM> subzone data <NUM> is provided in block <NUM> and a first subset of vehicle data corresponding to a position within subzone <NUM> may be selected. The first subset of vehicle data is represented by the vehicle-position data points <NUM> shown in <FIG>. Once selected, the first subset of vehicle data is processed at block <NUM>. For instance, the first subset of vehicle data instances may be analyzed and/or have computations performed thereon at block <NUM> to form at least one feature <NUM>.

<FIG> is a table <NUM> representing an example of a first subset of vehicle data corresponding to a position within subzone <NUM>. Position data <NUM> of each instance <NUM> is represented by vehicle-position data points <NUM> as shown in <FIG>. Subzone-related features formed from processing the first subset of vehicle data are indicative of attributes/measurements of vehicle operating data of vehicles with corresponding device IDs ID1, ID2, ID3, ID4, when operating in subzone <NUM>. These subzone-related features may be used by the ML algorithm to identify patterns. For descriptive purposes, only <NUM> vehicles are shown to have entered subzone <NUM>, in this example. In practice however, the number of vehicles that may enter a subzone may be more or less than four.

Some specific and non-limiting examples of the subzone-related features are provided in Table <NUM> below.

Other subzone-related features may be based on and/or are derived from the first subset of vehicle data instances. Embodiments are not intended to be limited to the example features described herein. <FIG> is a table of exemplary subzone-related features and feature values based on the subset of vehicle data instances. Other features may be based on and/or be derived from the first subset of vehicle data.

Ignition state indicates whether a vehicle is in a driveable state or not. For example, an internal combustion engine (ICE) vehicle has an ignition state of on when the engine is on. An ICE vehicle has an ignition state of off when the engine is off, even if electrical power is provided to vehicle circuitry by the battery. In another example, an electric vehicle (EV) has an ignition state of on when electricity is provided to the EV's electric motor, whereas the ignition state is off when no electricity is provided to the EV's electric motor.

The minimum ignition feature of a subzone has a value of <NUM> only when all vehicles that have entered a subzone have an ignition state of <NUM>. This may indicate that the vehicle way is not employed as a parking area.

The maximum ignition feature has a value of <NUM> only when all vehicles in a subzone have an ignition state of off. This may indicate that the subzone is a portion of vehicle way employed as a parking area.

The ignition ratio feature is defined as,
<MAT>.

In a second exemplary implementation, subzone-related features may be based on and/or derived from the first subset of vehicle data and a second subset of vehicle data including vehicle data temporally preceding and/or subsequent thereto for a same vehicle.

For instance, the first and second subsets of vehicle data may be processed for providing subzone-related features indicative of dwell time of a vehicle within a given subzone. Shown in <FIG> is a simplified diagram of subzone <NUM> and vehicle-position data point <NUM> representing a vehicle position at T1 according to vehicle data. A dwell time of a vehicle within subzone <NUM> may be determined by obtaining vehicle data corresponding to the same vehicle at a preceding point in time, T0, and a subsequent point in time, T2, represented by vehicle-position data points <NUM> and <NUM> respectively. As geographic coordinates of boundaries of subzone <NUM> are known, the time TA (<NUM>) between the time a vehicle enters subzone <NUM> and arrives at position <NUM>, and the time TB (<NUM>) between the time the vehicle leaves position <NUM> and exits subzone <NUM> may be determined. The dwell time, (e.g., how long the vehicle is in a subzone) may be calculated by, TDWELL = TA + TB. For each vehicle that enters subzone <NUM> a dwell time is calculated and features, average dwell time, minimum dwell time, maximum dwell time, median dwell time and standard deviation of dwell time are based thereon or derived therefrom.

In a third exemplary implementation, subzone-related features may be based on and/or derived from the first subset of vehicle data and a third subset of vehicle data including vehicle data corresponding to vehicle data temporally subsequent thereto for a same vehicle. In this example subzone-related features relates to the travel time of a vehicle between a location within a subzone and the first location the vehicle ignition state is off. In other words, the travel time between a position within a subzone and position the vehicle parks, i.e., time to park.

<FIG> is a simplified diagram of a path of a vehicle that has traversed subzone <NUM> having a related vehicle data instance corresponding to vehicle-position data point <NUM> at time T1, as shown. Each temporally subsequent vehicle data instance is represented by a vehicle-position data points <NUM> at times T1 - T14 each representing a new location of a same vehicle at consecutive points in time as the vehicle travels along path <NUM>. Vehicle-position data point <NUM> at T14 represents the first location the vehicle ignition is turned off, indicating that the car has parked. The time to park from position <NUM> to <NUM> may be calculated as TTIMETOPARK = T14-T1. For each vehicle that enters subzone <NUM> the time to park is calculated to provide subzone-related features such as, average time to park, minimum time to park, maximum time to park, median time to park, and standard deviation of time to park.

Table <NUM> of <FIG> represents a third subset of vehicle data corresponding to vehicle-position data points <NUM> at times T1-T14.

In some cases, a vehicle ignition is ON and the speed is <NUM>/hr, such as at T9. For example, when a vehicle is not moving yet the ignition is on. For instance, at red lights, stop signs, heavy traffic (stop-and-go), picking up passengers, going through a drive through, among others.

According to an embodiment, zone-related features may be based on and/or derived from a fourth subset of vehicle data instances associated with the zone and/or subzone-related features. Table <NUM> lists specific and non-limiting examples of such zone-related features. These zone-related features may be determined for each subzone of the plurality of subzones for each zone of the plurality of zones.

In a first exemplary implementation, zone average speed may be determined by selecting a subset of vehicle data instances corresponding to a position within a zone and calculating the average speed therefrom.

In a second exemplary implementation, zone average speed may be determined by calculating an average of the average speed subzone-related features of all subzones in a zone.

According to an embodiment, other zone-related features may be based on and/or derived from a fifth subset of vehicle data instances associated with the zone. Table <NUM> lists specific and non-limiting examples of such zone-related features. These zone-related features may be determined for each subzone of the plurality of subzones for each zone of the plurality of zones.

In an exemplary implementation, zone total number of visits may be determined by selecting a subset of vehicle data instances corresponding to a position within a zone and calculating the total number of vehicles that correspond to the zone.

According to an embodiment, other zone-related features may be based on and/or derived from another portion of subzone-related features. Table <NUM> lists specific and non-limiting examples of such zone-related features. These zone-related features may be determined for each subzone of the plurality of subzones for each zone of the plurality of zones.

For example, zone average dwell time may be determined by calculating an average of the average dwell time subzone-related features of all subzones in a zone.

According to an embodiment, subzone-zone-related features may be based on and/or derived from a portion of subzone-related features in relationship to a portion of zone-related features. Subzone-zone-related features are determined for each subzone of the plurality of subzones for each zone of the plurality of zones.

Specific and non-limiting examples of relationship-based features are listed in Table <NUM> below.

In an exemplary implementation, subzone-zone-related feature average speed ratio may be determined by calculating the ratio of subzone-related feature average speed to zone-related feature, zone average speed.

As described above, raw vehicle data may be selected from historical vehicle data based on a particular date and/or time period. As such, values of features described herein may vary accordingly.

According to an embodiment, spatial-related features may be based on and/or derived from spatial relationship data of a subzone to the zone. According to an embodiment, spatial-related features may be based on and/or derived from a spatial relationship data of a subzone to the plurality of subzones, or a portion thereof, of a zone.

In a first exemplary implementation, for each subzone, a spatial-related feature may be based on and/or derived from the distance of the subzone to the centre point of a zone. For instance, one method for determining the distance between a subzone and the centre point of a zone comprises, determining a location of a centre point of the subzone and the location of the centre point of the centre subzone of a zone. Next, the distance therebetween is calculated. For example, shown in <FIG> is a simplified diagram of portion <NUM> including centre point <NUM> of subzone <NUM>, and reference point 803a, which may be a centre point, of zone 1010a. The distance <NUM> between centre point <NUM> and reference point 803a is determined, for instance, by using the Haversine formula.

In a second exemplary implementation, for each subzone, a feature may be based on and/or derived from the number of subzones adjacent the subzone (e.g., number of Geohash neighbours). <FIG> is a simplified conceptual diagram of portion <NUM> including subzone <NUM> having <NUM> adjacent subzones <NUM>. <FIG> is also a simplified conceptual diagram of portion <NUM> including subzone <NUM> having <NUM> adjacent subzones <NUM>. In these examples, the features for subzones <NUM> and <NUM> may have values <NUM> and <NUM> respectively. Alternatively, features for subzones <NUM> and <NUM> may have values be derived therefrom.

In a third exemplary implementation, for each subzone, a feature may be based on and/or derived from the number of subzones adjacent the subzone (e.g., number of Geohash neighbours) having vehicle data corresponding to a location therein. <FIG> shows subzone <NUM> having <NUM> adjacent subzones <NUM>. If no vehicle data corresponds to <NUM> of those adjacent subzones the value of the feature is <NUM>. In other words, if vehicles did not enter <NUM> of the <NUM> subzones, the number of adjacent subzones having vehicle data corresponding to a location therein is <NUM>.

Spatial-related features are determined for each subzone of the plurality of subzones for each zone of the plurality of zones.

Example features are not intended to limit embodiments to the features described herein.

In block <NUM> training data is formed. For instance, for each subzone, above described features are determined to create training data. Training data further includes an indication of the class of each subzone.

Shown in <FIG> is a conceptual diagram of a portion of sample vehicle way in the form of sample intersection 802a and zone 1010a imposed thereon. Shaded subzones <NUM> of zone 1010a indicate that they are portions of sample intersection <NUM>, whereas the unshaded subzones <NUM> are not portions of sample intersection. Table <NUM> of <FIG> represents training data including subzone ID, a plurality of features generated for each associated subzone, and a class label, indicating a subzone is one of a 'vehicle way' class, (e.g., a portion of sample vehicle way, such as sample intersection 802a) or a 'not-vehicle way' class (e.g., not a portion of a sample vehicle way).

Finally, in block <NUM>, a machine learning technique, such as random forest technique, is implemented using training data to define a classifier for classifying a subzone as one of a vehicle way class or not-vehicle way class. The training data used may include all or a portion of the features described herein. Optionally, other features may be included in the training data.

For example, <FIG> is a high-level flow diagram of an exemplary process <NUM> for using a machine learning technique to define a classifier for classifying subzones. Process <NUM> begins at block <NUM> where training data, such as training data represented by table <NUM>, is input to a machine learning algorithm. Next, at block <NUM>, a classifier that is generated by training the ML algorithm is verified, and at block <NUM> the performance of the classifier is evaluated. If the classifier meets performance criteria, (e.g., passes verification) process <NUM> ends at block <NUM>. However, if the performance criteria are not met, (e.g., fails verification), the process <NUM> continues to block <NUM> where modifications to training data or machine learning algorithm parameters may be performed and process <NUM> continues until the defined classifier meets the required performance criteria.

Optionally, modifications to other parameters may also be performed should performance criteria not be met. Such as, the relative position of the reference areas from the reference points and/or subzone dimensions (e.g., Geohash precision). When performance criteria are met, classifier data associated with the classifier may be generated. Such classifier data may be indicative of the relative position of the reference areas from the reference points that were used for defining the classifier. The classifier data may also be indicative of subzone dimensions (e.g., Geohash precision) of subzones used for defining the classifier. This classifier data may be useful when using the classifier for defining a vehicle way. Each classifier may have unique classifier data associated therewith.

Included in the discussion above are a series of flow charts showing the steps and acts of various processes. The processing and decision blocks of the flow charts above represent steps and acts that may be included in algorithms that carry out these various processes. Algorithms derived from these processes may be implemented as software integrated with and directing the operation of one or more processors, may be implemented as functionally-equivalent circuits such as a Digital Signal Processing (DSP) circuit, a Field Programmable Gate Array (FPGA), an Application-Specific Integrated Circuit (ASIC), or may be implemented in any other suitable manner. It should be appreciated that the flow charts included herein do not depict the syntax or operation of any circuit or of any programming language or type of programming language. Rather, the flow charts illustrate the functional information one skilled in the art may use to fabricate circuits or to implement computer software algorithms to perform the processing of an apparatus carrying out the types of techniques described herein. It should also be appreciated that, unless otherwise indicated herein, the sequence of steps and/or acts described in each flow chart is merely illustrative of the algorithms that may be implemented and can be varied in implementations and embodiments of the principles described herein.

Accordingly, in some embodiments, the techniques described herein may be embodied in computer-executable instructions implemented as software, including as application software, system software, firmware, middleware, embedded code, or any other suitable type of computer code. Such computer-executable instructions may be written using any of several suitable programming languages and/or programming or scripting tools and may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.

Computer-executable instructions implementing the techniques described herein may, in some embodiments, be encoded on one or more computer-readable media to provide functionality to the media. Computer-readable media include magnetic media such as a hard disk drive, optical media such as a Compact Disk (CD) or a Digital Versatile Disk (DVD), Blu-Ray disk, a persistent or non-persistent solid-state memory (e.g., Flash memory, Magnetic RAM, etc.), or any other suitable storage media. As used herein, "computer- readable media" (also called "computer-readable storage media") refers to tangible storage media. Tangible storage media are non-transitory and have at least one physical, structural component. In a "computer-readable medium," as used herein, at least one physical, structural component has at least one physical property that may be altered in some way during a process of creating the medium with embedded information, a process of recording information thereon, or any other process of encoding the medium with information. For example, a magnetization state of a portion of a physical structure of a computer-readable medium may be altered during a recording process.

While not illustrated in <FIG>, <FIG>, traffic analytics system 104a, 104b and intelligent telematics system 500a, 500b may additionally have one or more components and peripherals, including input and output devices. As another example, traffic analytics system 104a, 104b and intelligent telematics system 500a, 500b may receive input information through speech recognition or in other audible format.

Embodiments have been described where the techniques are implemented in circuitry and/or computer-executable instructions. It should be appreciated that some embodiments may be in the form of a method or process, of which at least one example has been provided. The acts performed as part of the method or process may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments. Various aspects of the embodiments described above may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and is therefore not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.

Claim 1:
A method (<NUM>) for defining a classifier for use in defining a vehicle way, which method (<NUM>) being carried out by a traffic analytics system (104a),
the traffic analytics system (104a) comprising a processing resource (<NUM>), a data store (<NUM>) and a network interface (<NUM>), the processing resource (<NUM>) and the data store (<NUM>) being communicatively coupled and arranged for carrying out the operations of the method (<NUM>), and the network interface (<NUM>) being interoperable with a communication network (<NUM>) and configured for obtaining historical vehicle data from network components, which historical vehicle data, once received, being stored as subsets of raw vehicle data by the data store (<NUM>) in a database (<NUM>) of the traffic analytics system (104a);
the method (<NUM>) comprising:
identifying (<NUM>) a plurality of sample vehicle ways (802a - 802f);
for each sample vehicle way of the plurality of sample vehicle ways (802a - 802f), defining (<NUM>) a plurality of zones (908a - 908f; 1010a - 1010f), with each zone thereof comprising a corresponding sample vehicle way and each comprising a plurality of contiguous subzones (910a - 910f; 1011a - 1011f), with each subzone thereof having boundaries defined in accordance with a geographic coordinate system presenting a unique two-dimensional space on the Earth's surface;
selecting (<NUM>) from historical vehicle data indicative of vehicle operating conditions for a plurality of corresponding vehicles, a subset of raw vehicle data associated with each of the plurality of zones (908a - 908f; 1010a - 1010f);
for each of the plurality of contiguous subzones (910a - 910f; 1011a - 1011f) of each zone of the plurality of zones (908a - 908f; 1010a - 1010f), extracting (<NUM>) a plurality of features from the subset of raw vehicle data;
for each of the plurality of contiguous subzones (910a - 910f; 1011a - 1011f) of each zone of the plurality of zones (908a - 908f; 1010a - 1010f), generating (<NUM>) training data comprising the plurality of features for each contiguous subzone and an indication of the class of each subzone; and
using at least one machine learning technique with the training data to define a classifier (<NUM>) for classifying a subzone as one of a vehicle way class or not-vehicle way class.