Patent Application
20240355196
The present disclosure is generally directed to a method and a system demand estimation and, more specifically, to a method of transportation demand estimation based on people flow data.
The growing urban population and changes in travel patterns necessitate for ways to match supply with demand in urban areas. With the emergence of ride-hailing services and other new demand responsive modes of transportation, it is necessary to develop advanced analytic models capable of capturing detailed behavior of travelers and passengers.
In addition to demand estimation, it is also necessary to classify/segment demand to different modes of transportation, because traveler choices can significantly affect the performance of supply elements. Accurate demand estimation and segmentation ensure the applicability of a fair platform where different parties can cooperate to provide seamless and reliable services for users.
Furthermore, recent advances in sensors and mobile devices have enabled an unprecedented increase in the availability and collection of urban trajectory data, thus increasing the demand for more efficient ways to analyze data and manage cities and resources. Various modes of transportation differ in terms of their specification, usage, purpose, and data. It is needed to understand the difference and develop analytic models accordingly.
In the related art, demand forecast is utilized, which is largely based on historical data of demand for a specific mode of transportation. There are a number of limitations that relate to these methods. Specifically, the demand forecast is only based on historical data, and thus doesn't consider the dynamic nature of cities, people behavior, and latent demand. Second, the methods have been developed in silo-mode for different parties and cannot capture potential demand shift between different modes of transportation. While focusing on a single mode allows for simpler analysis of structural patterns and similarities among cities, it is insufficient for characterizing the transportation system as a whole. The methods also do not involve any detailed and real-time data collection and big data analytics, and is mostly based on years of survey data. Most importantly, the methods do not involve real people flow as part of the demand forecast.
In the related art, people flow analytics are applied to focus on local flow estimation and is mostly based on camera-based systems, which can be expensive and can't be applied to thoroughly cover data collection representing an entire area. This is mostly useful for local analytics and flow management of stations and other available resources. In addition to camera-based flow estimation, vehicle occupation sensors have been be used to collect ridership data on vehicles. Although, occupancy data is useful and provides insights in terms of demand estimation, it doesn't capture the dynamic interaction between different modes of transportation as well as latent demand.
In the related art, scenario simulation is used to model transportation systems. The goal of simulation is to come up with new plans, schedules, and allocation methods that consider changes in infrastructure, modes of transportation, population, points of interest, and new business models. These simulations are limited to high level planning, and is difficult to apply and run simulations for micro planning and daily forecasts.
Aspects of the present disclosure involve an innovative method for demand estimation. The method may include collecting people flow data from a network of a plurality of sensors within an area of interest, wherein each sensor of the plurality of sensors is associated with a user device; processing the people flow data to generate movement trajectories; mapping the movement trajectories to existing transportation network; aggregating the movement trajectories associated with the network of the plurality of sensors to estimate movement flow density; for the people flow data representing less than entire population of the area of interest, performing data simulation to rescale the movement flow density; classifying the people flow data into different transportation types; and generating flow-demand matching by matching current demand with transportation resource information.
Aspects of the present disclosure involve an innovative non-transitory computer readable medium, storing instructions for demand estimation. The instructions may include collecting people flow data from a network of a plurality of sensors within an area of interest, wherein each sensor of the plurality of sensors is associated with a user device; processing the people flow data to generate movement trajectories; mapping the movement trajectories to existing transportation network; aggregating the movement trajectories associated with the network of the plurality of sensors to estimate movement flow density; for the people flow data representing less than entire population of the area of interest, performing data simulation to rescale the movement flow density; classifying the people flow data into different transportation types; and generating flow-demand matching by matching current demand with transportation resource information.
Aspects of the present disclosure involve an innovative server system for demand estimation. The server system may include collecting people flow data from a network of a plurality of sensors within an area of interest, wherein each sensor of the plurality of sensors is associated with a user device; processing the people flow data to generate movement trajectories; mapping the movement trajectories to existing transportation network; aggregating the movement trajectories associated with the network of the plurality of sensors to estimate movement flow density; for the people flow data representing less than entire population of the area of interest, performing data simulation to rescale the movement flow density; classifying the people flow data into different transportation types; and generating flow-demand matching by matching current demand with transportation resource information.
Aspects of the present disclosure involve an innovative system for demand estimation. The system may include means for collecting people flow data from a network of a plurality of sensors within an area of interest, wherein each sensor of the plurality of sensors is associated with a user device; means for processing the people flow data to generate movement trajectories; means for mapping the movement trajectories to existing transportation network; means for aggregating the movement trajectories associated with the network of the plurality of sensors to estimate movement flow density; for the people flow data representing less than entire population of the area of interest, means for performing data simulation to rescale the movement flow density; means for classifying the people flow data into different transportation types; and means for generating flow-demand matching by matching current demand with transportation resource information.
A general architecture that implements the various features of the disclosure will now be described with reference to the drawings. The drawings and the associated descriptions are provided to illustrate example implementations of the disclosure and not to limit the scope of the disclosure. Throughout the drawings, reference numbers are reused to indicate correspondence between referenced elements.
The following detailed description provides details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term “automatic” may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of the ordinary skills in the art practicing implementations of the present application. Selection can be conducted by a user through a user interface or other input means, or can be implemented through a desired algorithm. Example implementations as described herein can be utilized either singularly or in combination and the functionality of the example implementations can be implemented through any means according to the desired implementations.
In the example implementations, city level flow and resources are utilized to enrich accurate demand estimation and segmentation model generation. Passenger people flow data is used to capture both real and latent demand that can be used to accurately plan for different spatial and temporal horizons (e.g., micro and macro level).
The demand forecasting system provides comprehensive view of total demand including historical demand, demand related to emerging services and technologies, and latent demand (e.g., unseen by the system due to lack of proper planning and inaccurate supply-demand matching). Such data have important applications in transportation research fields, for instance, to detect the movement mode of travelers, calculate traffic flow in an area, and predict the traffic flow at a certain time in the future.
People flow data can be used to capture the overall flow in city level and segment demand into different categories. The segmented demand can then be analyzed to perform demand-supply matching for different modes of transportation. Accurate demand can be used to revisit mobility plans and redesign cities accordingly in multiple spatial and temporal scales.
The collected people flow data are then stored at databases of management system 102 for subsequent mapping. Aggregation of cellular locations or calculation of cell tower usage densities can then be performed by computing resources of the management system 102 based on movement associated with or tracked by the IT devices at a macro level. For example, observation of pedestrians moving from one intersection to another. The system then matches the flow data with infrastructure information, traffic information, and existing transportation plans associated with infrastructure 104. The matched data can then be used to generate demand forecasting.
At S206, map matching is then performed after trajectory preprocessing. Map matching matches recorded trajectories (people flow data) to a logical model of the real-world entities. Specifically, mapping dynamic behaviors of the people flow data as observed into edges of existing transportation network in a sorted list based on traveling device user or vehicle's time stamps.
Referring back to
Spatial indexing and temporal indexing are performed respectively at steps S214 and S216. Indexing is necessary in the development of scalable models. Spatial indexing involves generating hash for location referencing, and temporal indexing involves timestamping. Depending on the temporal scale and spatial scale, the flow may need to be aggregated over: (i) period of time (e.g., peak hour, late hour operations, etc.); and (ii) location specific analysis (e.g., near a station, at a select zip code, etc.) For development of scalable systems, it is necessary to index each trajectory in order so as to decrease the time it takes to locate features that match a spatial query. Example of a query can be the number of people moving from one predefined geological area to another area.
Referring back to
At S506, entity aggregation is performed to aggregate the flow, whether it is moving from one segment to another or staying in the segment in the next time step. At S508, simulation is performed over aggregated flow to rescale the flow. At S510, local movements are filtered out using distance filters. The local movements comprise displacements not associated with transportations and displacements within buildings.
At S510, data is read on modes of transportation specifications to match with flow (e.g., short-range, medium range, long range transportation, etc.) At S512, the flow is mapped based on the specifications to different transportation modes to classify the different transportations. At S514, temporal graphs of flow movement between segments are generated. The generated temporal graphs represent people movement at different time period (e.g., peak hour graphs, peak to late hour transition graphs, etc.) Each time-step has a corresponding temporal graph. At S516, contexts are provided to the people flow data. For example, associating movements to station, mode of transit, wait times (passive), etc. Local movement being filtered out from total flow for segment demand prediction generation. Each time step has its own origin-destination matrix (OD matrix) and together, temporal OD matrices are generated for different mobility needs at S518.
For mobile people flow data, the cleaned and smoothed people flow data then must be divided into activity, mode of transport, and trip segments. An activity is time spent at home, work, shopping, etc., and trip segments indicate travel between activities.
An activity segment may be identified by more than one method because of its time, density, signal interval features, and etc. Based on the speed and acceleration characteristics of trip, people flow data can be used to separate motorized-mode (car, bus, train) trips and nonmotorized mode (walk, bike) trips. Furthermore, it is possible to add inertial sensors to detect the activity type and modes of transportation more accurately.
At S706, conversion rate of flow is calculated. Conversion rate is the ratio of realized demand to latent demand. The conversion rate of flow indicates the actual utility of the latent demand. At S708, unaddressed flow is extracted. At S710, latent demand is separated from current demand. Latent demand is total addressable demand and current demand is actual service usage. The factors that are not reflected in the current demand calculated from observing a single mode or conventional parameters are represented by latent demand, which is evaluated from observing all transit-oriented activities and signals.
Referring back to
The foregoing example implementation may have various benefits and advantages. For example, the demand forecasting system provides comprehensive view of total demand including historical demand, demand related to emerging services and technologies, and latent demand (e.g., unseen by the system due to lack of proper planning and inaccurate supply-demand matching). The forecasting system detects transportation modes of travelers, calculates traffic flow in an area, and predicts the traffic flow at a later time in the future.
Computing device 805 can be communicatively coupled to input/user interface 835 and output device/interface 840. Either one or both of the input/user interface 835 and output device/interface 840 can be a wired or wireless interface and can be detachable. Input/user interface 835 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing/cursor control, microphone, camera, braille, motion sensor, accelerometer, optical reader, and/or the like). Output device/interface 840 may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input/user interface 835 and output device/interface 840 can be embedded with or physically coupled to the computing device 805. In other example implementations, other computing devices may function as or provide the functions of input/user interface 835 and output device/interface 840 for a computing device 805.
Examples of computing device 805 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and/or coupled thereto, radios, and the like).
Computing device 805 can be communicatively coupled (e.g., via IO interface 825) to external storage 845 and network 850 for communicating with any number of networked components, devices, and systems, including one or more computing devices of the same or different configuration. Computing device 805 or any connected computing device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or another label.
IO interface 825 can include but is not limited to, wired and/or wireless interfaces using any communication or IO protocols or standards (e.g., Ethernet, 802.11x, Universal System Bus, WiMax, modem, a cellular network protocol, and the like) for communicating information to and/or from at least all the connected components, devices, and network in computing environment 800. Network 850 can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, satellite network, and the like).
Computing device 805 can use and/or communicate using computer-usable or computer readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid-state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.
Computing device 805 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).
Processor(s) 810 can execute under any operating system (OS) (not shown), in a native or virtual environment. One or more applications can be deployed that include logic unit 860, application programming interface (API) unit 865, input unit 870, output unit 875, and inter-unit communication mechanism 895 for the different units to communicate with each other, with the OS, and with other applications (not shown). The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided. Processor(s) 810 can be in the form of hardware processors such as central processing units (CPUs) or in a combination of hardware and software units.
In some example implementations, when information or an execution instruction is received by API unit 865, it may be communicated to one or more other units (e.g., logic unit 860, input unit 870, output unit 875). In some instances, logic unit 860 may be configured to control the information flow among the units and direct the services provided by API unit 865, the input unit 870, the output unit 875, in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled by logic unit 860 alone or in conjunction with API unit 865. The input unit 870 may be configured to obtain input for the calculations described in the example implementations, and the output unit 875 may be configured to provide an output based on the calculations described in example implementations.
Processor(s) 810 can be configured to collect people flow data from a network of a plurality of sensors within an area of interest, wherein each sensor of the plurality of sensors is associated with a user device as illustrated in
The processor(s) 810 may also be configured to perform trajectory preprocessing to the movement trajectories to compensate for global positioning system (GPS) errors and provide data smoothing to the movement trajectories as illustrated in
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.
Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.
Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer readable storage medium or a computer readable signal medium. A computer readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid-state devices, and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.
Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.
As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general-purpose computer, based on instructions stored on a computer readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.
Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.
