CN113383351A

CN113383351A - 运输方法和装置

Info

Publication number: CN113383351A
Application number: CN201980090572.4A
Authority: CN
Inventors: 阿禹石·伽; 彭俊凯; 蝉丹库码·阿伽瓦
Original assignee: Grabtaxi Holdings Pte Ltd
Current assignee: Grabtaxi Holdings Pte Ltd
Priority date: 2019-01-28
Filing date: 2019-01-28
Publication date: 2021-09-10
Also published as: KR20210114987A; SG11202107972UA; WO2020159431A1; EP3918543A1; JP2022521665A; TW202034277A; EP3918543A4; US20220114609A1

Abstract

一种运输系统由多个邻接的地理小区构成。基于位于地理小区中的一个或多个中的合格运输服务提供者的数量来计算运输服务用户的有效服务可用性。这些计算可以考虑每个服务提供者与用户之间的距离。

Description

运输方法和装置

本发明属于数据处理的一般领域。一些实施例涉及收集、分析和显示表示运输系统中的服务提供的数据。一些实施例涉及打车类型系统。

背景技术

打车业务的最简形式是关于将寻找一定运输模式的用户与能够提供这种运输的服务提供者进行匹配。与实际和预测的服务提供和服务需求相关的数据可以成为机器学习算法的主题，并且一些系统的目的是以确保用户在希望时获得运输、并且用户与离他们最近的服务提供者相匹配的目标来微调机器学习算法。然而，服务提供者通常倾向于始终在移动，并且在任何一个时刻，在相对小的区域内会有数百个用户请求运输。这意味着有时最近的可用的服务提供者可能距离太远而不能快速提供所需的运输。

期望通过明确定义的度量大规模分析这些实例。

一些实施例的目的是确定在任何给定区域和时间的供需关系。

发明内容

在一个方面，提供了一种操作运输系统的方法，该系统包括多个邻接的地理小区，该方法包括基于位于所述小区中的一个或多个中的合格服务提供者来计算至少一个用户的有效服务可用性。

在一种布置中，该方法包括考虑从多个服务提供者中的每一个到用户的距离。

在一种布置中，该方法还包括确定该多个邻接的地理小区中的每一个的需求参数。

在另一方面，披露了用于操作运输系统的装置，该装置被配置为基于位于所述小区中的一个或多个中的合格服务提供者的数量来计算每个用户的有效供应，所述小区包括所述用户位于其中的小区。

在实施例中，该装置被配置为从服务提供者设备接收指示合格服务提供者的位置的数据。在实施例中，使用推送技术接收指示服务提供者的位置的数据。在实施例中，指示服务提供者位置的数据被异步接收并且被流式传输到提供者消息队列中以进行同步处理。

在实施例中，该装置被配置为接收指示用户位置的数据。在实施例中，指示用户位置的数据被异步接收并且被流式传输到用户消息队列中以进行同步处理。

在实施例中，该装置包括服务器设备，该服务器设备被配置为从提供者消息队列同步接收提供者数据和从用户消息队列同步接收用户数据，将同步提供者数据聚合成聚合的提供者数据流，以及将同步用户数据聚合成聚合的用户数据流。

在实施例中，该装置包括空间数据库，该空间数据库被配置为使用来自聚合的提供者流的数据来进行寻址。

在实施例中，该装置包括处理器设备，该处理器设备被配置为执行存储在存储器中的指令以实现以下算法。

1.收集参数组(用户；提供者；距离；小区位置)

2.按提供者分组＝>提供者((用户1,距离1,小区),(用户2,距离2,小区2)

3.针对每个提供者，计算提供者对每个用户的贡献比率(通过对以上距离1、距离2求和进行加权)，并发射(用户1,地理散列1,比率1)

4.按小区分组＝>小区1((用户1,比率1),(用户2,比率2))

5.对每个小区的所有用户求和以获得总需求

6.对每个小区的所有比率求和以获得总供应

7.针对每个小区，将总需求除以总供应＝>S/D度量

8.写入输出数据。

在另一方面，提供了一种操作具有多个移动资源和多个消费者的地理分布式运输系统的方法，该方法包括从至少一个消费者接收消费者位置数据和从至少一个资源接收资源位置数据，使用资源位置数据作为空间数据库的索引来确定指示资源位置周围的点的数据，以及处理消费者位置数据和指示资源周围的点的数据以围绕每个资源进行分组，从而确定每个消费者的有效资源供应。

在实施例中，移动资源是服务提供者，例如驾驶员。在实施例中，消费者是服务用户，例如乘客。

在另一方面，披露了在运输系统操作系统中具有多个用户和多个服务提供者，每个用户形成需求单元，每个服务提供者形成供应单元，该运输系统包括共同定义操作区域的多个地理小区，用于确定每个用户的有效供应的方法包括以下步骤：-

确定在时隙内位于每个小区中的需求单元；

确定在所述时隙内位于每个小区中的供应单元；

基于至少一个参数确定合格供应单元；

识别每个合格供应单元的位置周围的需求单元；

计算每个合格供应单元-需求单元对之间的直线距离；以及

通过以下步骤获得有效供应：-

a计算每个合格供应单元-需求单元对的直线距离比

b.计算每对的权重

c.求每对的计算权重的倒数

d.计算倒数计算权重的比例作为有效供应。

在替代方案中，可以计算路线或道路距离而不是计算直线距离。这可能在不同的迭代中。

尝试确定供应和需求的传统方法是驾驶员和乘车者数量的简单比率。这可能会导致许多不准确(比如，在定义区域边界上的服务请求者可能靠近该定义边界另一侧的服务提供者)。

实施例可以被布置为获得更准确的在空间和时间上的供需图片。

附图说明

在附图中：

图1是展示了用于操作运输系统的第一示例性通信服务器装置的示意性框图；

图2示出了打车系统(ride-hailing system)的一部分的简化图，在这种情况下展示了九个小区，其中有一个服务提供者设备和三个请求服务的用户；

图3示出了展示针对图2的部分系统的简单计算的图；

图4是新加坡地图，以典型的一天的供需差距为例；

图5是类似于图4的地图，但示出了供需分布；

图6是新加坡小型住宅区在一天中的典型供需分布的图；

图7示出了来自用户设备上的需求微件(Widget)的示例性图形显示，示出了在河谷(新加坡)进行预订的最佳时间；

图8是部分框图，展示了用于打车系统的一部分的系统的架构的一些方面；以及

图9示出了由图8的系统的处理器执行的部分流程图。

具体实施方式

首先参考图1，展示了通信系统100。通信系统100包括通信服务器装置102、服务提供者通信设备104和用户通信设备106。这些设备通过实施例如互联网通信协议的相应的通信链路110、112、114而在通信网络108(例如互联网)中连接。通信设备104、106能够通过其他通信网络(比如公共交换电话网络(PSTN网络)，包括移动蜂窝通信网络)来通信，但是为了清楚起见，从图1中省略这些通信网络。

通信服务器装置102可以是如图1中示意性展示出的单个服务器，或者可以具有由服务器装置102执行并且跨多个服务器组件分布的功能。

在图1的示例中，通信服务器装置102可以包括多个单独的组件，包括但不限于：一个或多个微处理器116、用于加载可执行指令120的存储器118(例如，易失性存储器，比如RAM)，可执行指令定义了服务器装置102在处理器116的控制下执行的功能。通信服务器装置102还包括允许服务器通过通信网络108进行通信的输入/输出模块122。用户接口124被提供用于用户控制，并且可以包括例如常规外围计算设备，比如显示监视器、计算机键盘等等。服务器装置102还包括数据库126，该数据库的目的将通过以下讨论变得更显而易见。

服务提供者通信设备104(下文称为“服务提供者设备”)可以包括多个单独的组件，包括但不限于：一个或多个微处理器128、用于加载可执行指令132的存储器130(例如，易失性存储器，比如RAM)，可执行指令定义了服务提供者设备104在处理器128的控制下执行的功能。服务提供者设备104还包括允许服务提供者设备104通过通信网络108进行通信的输入/输出模块134。用户接口136被提供用于用户控制。如果服务提供者设备104是例如智能电话或平板设备，则用户接口136将具有在许多智能电话和其他手持设备中普遍存在的触摸面板显示器。可替代地，如果服务提供者设备是例如常规台式计算机或膝上型计算机，则用户接口可具有例如常规外围计算设备，比如显示监视器、计算机键盘等等。

用户通信设备106(下文称为“用户设备”)可以是例如具有与服务提供者设备104的硬件架构相同或相似的硬件架构的智能电话或平板设备。

在实施例中，为了提供打车服务，用户使用用户设备106来请求乘车。应该注意的是，术语“乘车”是为了简单而使用的——该术语不旨在是限制性的，而是旨在涵盖多种不同的场景——例如，用户请求服务提供者提取某一物品并将其配送到特定地址。在该实施例中，用户设备106运行在设备上提供图形用户界面的应用程序，从而允许用户例如通过指定目的地来请求乘车。在一些情况下，需要输入起始位置，可以规定输入乘车时间，该时间当然可以是“尽快”。

该信息经由通信网络108被传输到服务器装置102，在服务器装置中，信息被存储在数据库126中。实施例中的服务器102运行使乘车请求信息能够被转发到特定服务提供者设备104的程序。在该实施例中，服务器装置102被编程为基于从每个服务提供者设备104推送到服务器装置102的信息来选择特定服务提供者设备104，该信息指示每个服务提供者设备的位置和服务提供者的可用状态。因此，在该实施例中，服务器装置102被编程为选择最近的合格服务提供者的服务提供者设备(其中“合格”意味着空闲或即将变得空闲)。

服务提供者具有接受或不接受工作的选项。

假设特定服务提供者接受向用户提供服务的工作，则该信息从提供者设备104被提供到服务器装置102，这使得该信息被存储在数据库126中，并且还仅向发出请求的用户的用户设备发送服务确认。在实施例中，还发送在提供者可以到达用户处之前的预测延迟。

服务器装置102被编程为收集关于用户和服务提供者的位置的信息并存储指示该信息的数据。在本实施例中，该数据是高度详细的并且包括每个旅程、每个乘车者、每个服务提供者的细节。

上面的描述涉及一种简单的布置，其中服务提供者通常很容易可用，并且潜在用户是顺从的，在无法快速找到可用的服务提供者的情况下，这些用户将接受在将来的某个时间进行乘车。

然而，在现实世界中，如上所述，服务提供者可能始终在移动，并且在任何一个时间点，在同一区域内都可能有数百个用户请求服务。这意味着有时最近的可用服务提供者可能距离太远而无法提供令人满意的服务。

本文描述的布置处理存储在数据库126中的信息和来自服务提供者设备的实时数据中的一者或两者，以影响提供给在服务器装置102上运行或由服务器装置运行的其他进程的信息。例如，这些其他进程可能会向空闲的服务提供者建议他们可以移动到哪里以增大工作的可能性或增大高收入工作的可能性的。所描述的布置的结果可以另外或替代地提供供需之间的关系的显示。

在以下描述中，单个供应单元是在确定的时间段(下文称为时隙)开始时在线并且空闲(当前未在工作)的服务提供者。在每个这样的时隙开始时来自每个服务提供者设备的GPS ping被视为他或她的位置。

非限制性示例时隙持续时间是120秒。

单个需求单元是在同一时隙内查看服务(例如运输)价格的用户。在实施例中，用户的位置被选择为所输入的接载地址。在另一个实施例中，该位置是由用户设备传输的实际当前位置。

参考图2，在以下披露内容中，地理区域——例如城市及其周围郊区的——被划分为多个小区。在一些实施例中，这些小区由所谓的“地理六边形(geohex)”(地理散列(geohash)的六边形等效方案)定义。在其他情况下，小区由地理散列定义。在一个这样的实施例中，位置以精度y聚合为地理散列(编码成字母和数字的字符串的地理位置)，其中y指的是地图上尺寸非常小的多边形空间。在非限制性示例中，小区大小是1.2km×609.4m(地理散列6)。

设想小区可以具有不同的形状和大小。

然后，将每个供应单元映射到供应所在的小区内的所有需求单元，在这种情况下，映射到贴近的外侧小区，如图2所示。

然后向按距离倒数地加权的相邻小区中的每个需求单元分配每个供应单元的一定分数，这些分数的总和为一(unity)。从本质上讲，这意味着服务提供者对于较近的用户比较远的用户更加可用。

在该实施例中，使用直线距离作为路线距离的代替物，以降低算法的复杂度。在另一个实施例中，使用路线距离本身。

用于确定每个用户(即每个需求单元)的有效供应的方法如下：

1.确定位于每个区域-时隙的需求单元(含纬度和经度)

2.确定位于每个区域-时隙的供应单元(含纬度和经度)

3.识别每个合格供应单元的位置周围的需求单元

4.计算每个合格供应单元-需求单元对之间的直线距离

5.通过以下步骤获得有效供应：-

a计算每个合格供应单元-需求单元对的直线距离比

b.计算每对的权重

c.求每对的计算权重的倒数

d.计算倒数计算权重的比例作为有效供应

在一个实施例中，“合格供应单元”是参考需求单元确定的，其为在与需求单元的小区相同的小区中的供应单元以及在与需求单元的小区邻接的小区中的供应单元。在另一个实施例中，小区的接近程度不随位置而恒定，因此在高峰时段商业区(CBD)中，合格的供应单元可能会在邻接小区之外的小区中找到。在又一其他实施例中，用于确定合格的小区随时间变化。

针对每个用户，将对该小区中用户可用的所有提供者的分数求和得到每个用户的有效供应。将特定用户的所有这些相加得到该用户在该时隙被服务得如何的指示。图2描绘了所展示的汽车为每个用户服务得如何；每个用户共享供应的一定分数。

在多个小区i和时隙j组合上聚合需求和有效供应，产生两个简单的聚合度量：供需比和供需差(图3)。

在一些实施例中，不在所有小区和所有时隙上执行聚合。由于距离而产生的服务提供者的分数分布会在小区域和时间上产生供应和需求的粒度(granular)图片。如果聚合到更大的区域，则会丢失由于服务提供者处于该区域中间的位置而产生的分布。

在一系列实施例中，所有价格查看和提供者位置的数据被历史地存储在数据库中。使用多层SQL查询，所提及的度量是针对历史数据导出的。

在另一系列实施例中，类似的逻辑在生产(工程系统)中被复制，其中，输入数据(价格查看和提供者位置)经由实时消息队列流入。因此，如果需要，可以实时计算度量(或延迟2至5分钟)。通过这种方式，数据可以实时用于app中的如热图、定价、激励的特征。

在一些实施例中，仅针对当前情况，即当前时隙执行计算。这允许监督供应/需求情况。

在其他实施例中，在每个时隙发生时针对其进行计算，并且将有效供应和需求的值存储在数据库126中。然后，在合适的时间，例如在每个时钟小时结束时，将供需比和供/需差求和以提供性能指示。

因此，在针对此基本形式的以下等式中，“有效供应”的总和是在该时隙中该小区中(i＝1，j＝1)所有用户的有效供应值的总和。这考虑了关于多于一辆汽车的用户的“有效供应”。因此，对于特定小区中有三个用户并且有两辆汽车能够为这三个用户中的每一个提供服务的场景，计算用户1利用汽车1、用户2利用汽车1、用户3利用汽车1、用户1利用汽车2、用户2利用汽车2、用户3利用汽车2的有效供应得分。有效供应得分是针对汽车1和2中的每一个，用户1、2和3的所有有效供应得分的总和。

以下等式1a和1b展示了当在当前时隙在多个地理小区上进行聚合时的聚合。

等式1a和1b

相比之下，等式2a和2b展示了当在多个地理小区和多个时隙上进行聚合时的聚合。

等式2a和2b

等式3a和3b

等式3a和3b示出了在时隙j＝0至j＝n上聚合的针对单个指定地理小区的计算。

如果供/需比大于1，则这表明供过于求。如果供需比小于1，则这表明供不应求。供需差指示供过于求/供不应求的程度(大小/尺度)。

此外，可以根据“供需差”计算来确定是否存在供过于求或供不应求(只要还考虑结果是正数还是负数即可)。例如，如果结果产生正数，则这表明供过于求，并且如果结果产生负数，则这表明供不应求。

处理数据

虽然所产生的度量可能看起来像简单的比率和差值，但计算有效供应是相当繁重的计算，这需要在相邻空间中映射每个驾驶员和乘客。

在整个地区中，在任何给定时间点可能有成千上万的乘客在寻求乘车。算法的实施例不仅识别每个需求单元和供应单元及其位置，还将每个供应单元映射到同一邻域中的所有需求单元以输出每个乘客可用的分数供应。

每个额外的供应单元或需求单元都会基本上提高算法的计算能力要求。

通过上面讨论的度量，可以规划需求和供应之间的差距在一天之中会如何发展。图3显示了在典型的一天中新加坡的供需差距，在这种情况下为从16个工作日导出的平均值。

每个气泡都指示地图上的区域。每个气泡的大小指示该区域中的供需差异——气泡越大，差距越大。气泡是有色的，以便指示供/需比，其中红色表示供不应求，绿色表示供过于求。

为了实现确保用户在希望时总是能找到车的目标，需要平衡需求和供应。一方面，这通过寻找将供过于求的部分移动到需求较高的区域的方式来解决，并且另一方面通过将时间不敏感的需求转移到远离高峰时隙来解决。

在一天的任何给定时间，在一个区域可能存在驾驶员供过于求，而在其他区域可能存在供不应求。

如图5所示，在大多数乘车旅程在CBD结束(这导致该地区中供过于求)的早高峰时段之后，这在新加坡是很常见的。这种场景在诸如机场(例如樟宜机场)的排队点也是很常见的。

为了解决这种地理时间错位，在实施例中，在服务提供者设备上显示的热图鼓励驾驶员移动远离供过于求的区域去往具有更高需求的区域。

图6是新加坡小型住宅区在典型工作日中的供应和需求的聚合表示。

图6中的突出显示的区域600描绘了需求(水平时间轴上方)与供应(水平时间轴下方)不匹配的时间段。使用历史数据，已知需求可能由于预期因素(比如通常的高峰时段)和较不可预测的因素(比如突然的大雨)而达到高峰。然而，供应会在稍后的时间、通常是需求已经消退时增长。

为了解决这种不平衡，在实施例中，可以操作用户设备示出各小时的可能需求分布。这是使用所谓的微件来实现的，其中微件被定义为图形用户界面(GUI)显示信息(比如图7的信息)的元件。微件基于用户具体位置的历史数据总结来示出需求趋势。这里的目标是鼓励时间不敏感的需求(不需要立即乘车的用户)推迟他们的旅程而在需求较少时的时间进行预定。这帮助具有更急迫需求的乘客更容易被分配，并且还允许时间不敏感的用户看到旅程费用更高的高需求时间。

现在参考图8描述平台的一部分的示例。该图示出了示例架构，该架构不旨在是限制性的。

图8的图示出了两个服务提供者和单个意向用户，每个服务提供者具有相应的服务提供者app 510a、510b，并且意向用户具有用户app 520。当然，通常将有许多服务提供者和许多潜在用户，但是为了便于理解，在此采用较小的数字。

服务提供者app 510a、510b和用户app 520被布置为例如经由比如互联网等无线链路连接到由第一服务器设备512和第二服务器设备522组成的输入服务器设备。

服务器设备512、522被配置为经由导电链路将信号输出到消息队列514、524，消息队列进而经由导电链路连接到第一消费者服务器设备516和第二消费者服务器设备526。

第一消费者服务器设备516经由导电链路连接到空间数据库538；第二消费者服务器526经由导电链路连接到实时事件消息队列536。

实时事件消息队列536和空间数据库838都导电地连接到实时事件框架540，并且该实时事件框架进而连接到缓存542以向其输出数据。

尽管上面提到了导电链路，但是这些导电链路并不是本发明必不可少的，并且可设想其他连接。

数据以异步方式从服务提供者设备510a、510b(例如驾驶员设备上的app)和意向用户(例如乘客)的用户app 520二者到达服务器设备512、522。为了允许进行同步处理，将这两个异步数据流形成为相应的消息队列。

在该实施例中，每个服务提供者设备510a、510b如在本文档中的其他位置描述的运行app，并且该app周期性地将相应的消息511a、511b推送到处理设备500的第一服务器512。在示例中，app每10秒推送数据，尽管该时间纯粹是示例，并且可设想其他时段。第一服务器512将来自消息511a、511b的数据作为分组数据流513流式传输，以存储在第一消息队列514中。在实施例中，处于非常高级别的每个数据单元看起来如此->(providerID,location,state)，其中，location＝(latitude,longitude)，state可以是(online,available,on_job)中的任何一个。因此，所传送的数据包括指示服务提供者设备的位置的信息和指示相应服务提供者的状态的数据。

在其他实施例中，如其他地方所述，系统可以轮询服务提供者设备以获得状态和其他数据，而不是使用推送技术。

当潜在用户使用他的用户设备520访问打车系统例如查看车费或查看其他信息时，将该访问传递到第二服务器522。服务器522周期性地将消息521的内容作为分组数据流而流式传输到第二消息队列524。

处于非常高级别的每个数据单元看起来像(PassengerID,pickUplocation,time_when_fare_was_checked)。

来自两个消息队列521和523的数据515、525传递到提供后端服务的相应的消费者服务器516、526。在实施例中，这些消费者服务器以语言“Go”编程。

消费者服务器526聚合所有潜在用户，例如，那些在每小区基础上——例如使用数据525在每小区(或地理散列)的基础上——查看车费的用户，并且将分组聚合数据535流式传输到实时事件消息队列536。在实施例中，聚合数据535包括在指定时间窗口(在示例中2分钟窗口)每地理散列的累积车费查看。在实施例中，每个分组是：-

Cell 1[{UserID1,PickUpLocation},{UserID2,PickUpLocation}]。

消费者服务器516将分组数据537传递到空间数据库538，数据537是从数据515导出的，并且表示在线和空闲的服务提供者。因此，在空间数据库538中为这些服务提供者编制索引。

优化空间数据库538以存储和查询表示在几何空间中定义的对象的数据。这使用索引以基于空间索引快速查找值，并提供找到和输出在流537的每个输入索引值的指定半径内的所有点的能力。空间数据库538的输出流539以及来自实时事件队列536的数据541被传递到实时数据处理框架540。

实时事件框架540接收数据541(乘客列表和他们按地理散列的位置)，并且使用数据539针对每个乘客按地理散列找到在1km的半径内的所有驾驶员。

示例算法遵循：

收集参数(乘客,驾驶员,距离,地理散列)

按驾驶员分组＝>驾驶员1((乘客1,距离1,地理散列1),(乘客2,距离2,地理散列2))*

针对每个驾驶员，计算驾驶员对每个乘客的贡献比率(通过对以上距离1、距离2求和进行加权)，并发射(乘客1,地理散列1,比率1)

按地理散列分组＝>地理散列1((乘客1,比率1),(乘客2,比率2))

对每个地理散列的所有乘客求和以获得总需求

对每个地理散列的所有比率求和以获得总供应

针对每个地理散列，将总需求除以总供应＝>S/D度量

将输出写入缓存

*这表示此驾驶员(驾驶员1)是供应来源的所有乘客的集合

该算法在图9中更完整地示出。

来自实时事件框架的数据539被输出到缓存540以供存储，从而实现对各种应用(未示出)的快速写入(来自539)和读取。此类应用包括驾驶员热图、定价上涨和需求预测。

在另一系列实施例中，有效供应的确定不是在时隙结束时直接执行，而是在另一个时间执行。在这些其他实施例之一，在需求较少的夜间时段期间执行对整个前一天的计算。

应当理解，仅通过示例的方式描述了本发明。在不脱离所附权利要求的精神和范围的情况下，可以对本文描述的技术进行各种修改。所披露的技术包括可以以独立方式或彼此组合的形式提供的技术。因此，关于一种技术描述的特征也可以以与另一种技术组合来呈现。

Claims

1.一种操作运输系统的方法，该系统由多个邻接的地理小区构成，该方法包括基于位于所述地理小区中的一个或多个中的合格服务提供者的数量来计算至少一个用户的有效服务可用性。

2.根据权利要求1所述的方法，包括考虑从每个服务提供者到该用户或每个所述用户的距离。

3.根据权利要求1所述的方法，进一步包括确定该多个邻接的地理小区中的每一个的需求参数。

4.一种用于操作运输系统的服务器装置，该服务器装置包括处理器和存储器，该通信服务器装置被配置为在该处理器的控制下执行存储在该存储器中的指令：基于位于所述小区中的一个或多个中的合格服务提供者的数量来计算每个用户的有效供应，所述小区包括所述用户位于其中的小区。

5.一种运输系统操作系统，具有多个用户和多个服务提供者，每个用户形成需求单元，每个服务提供者形成供应单元，该运输系统包括共同定义操作区域的多个地理小区、以及具有处理器和存储器的服务器装置，该服务器装置被配置为在该处理器的控制下执行存储在该存储器中的指令，以通过以下步骤确定每个用户的有效供应：-

确定在时隙内位于每个小区中的需求单元；

确定在所述时隙内位于每个小区中的供应单元；

基于至少一个参数确定合格供应单元；

识别每个合格供应单元的位置周围的需求单元；

计算每个合格供应单元-需求单元对之间的直线距离；以及

通过以下步骤获得有效供应：-

a计算每个合格供应单元-需求单元对的直线距离比

b.计算每对的权重

c.求每对的计算权重的倒数；以及

d.计算倒数计算权重的比例作为有效供应。

6.一种用于操作运输系统的装置，该装置被配置为基于位于所述小区中的一个或多个中的合格服务提供者的数量来计算每个用户的有效供应，所述小区包括所述用户位于其中的小区。

7.根据权利要求6所述的装置，被配置为使用推送技术从服务提供者设备接收指示合格服务提供者的位置的数据。

8.根据权利要求6所述的装置，被配置为使得指示异步接收的位置的数据流能够被流式传输到提供者消息队列中以进行同步处理。

9.根据权利要求6所述的装置，被配置为异步地接收指示用户位置的数据，以将该用户位置数据流式传输到用户消息队列中以进行同步处理。

10.根据权利要求6所述的装置，包括服务器设备，该服务器设备被配置为从提供者消息队列接收同步提供者数据和从用户消息队列接收同步用户，将该同步提供者数据聚合成聚合的提供者数据流，以及将该同步用户数据聚合成聚合的用户数据流。

11.根据权利要求10所述的装置，包括空间数据库，该空间数据库被配置为使用来自该聚合的提供者流的数据来进行寻址。

12.根据权利要求6所述的装置，包括处理器设备，该处理器设备被配置为执行存储在存储器中的指令以实现以下算法。

1.收集参数(用户,提供者,距离,小区位置)

4.按小区分组＝>小区1((用户1,比率1),(用户2,比率2))

5.对每个小区的所有用户求和以获得总需求

6.对每个小区的所有比率求和以获得总供应

7.针对每个小区，将总需求除以总供应＝>S/D度量

8.写入输出。