一种处理订单的方法、装置、设备及存储介质与流程

本申请涉及互联网技术领域，尤其涉及一种处理订单的方法、装置、设备及存储介质。

背景技术：

随着互联网行业的迅猛发展，使用网约车的用户也越来越多。通常情况下，网约车平台在接到用户通过手机等智能终端发送的打车订单后，会以乘客定位点或上车点为中心，请求周围预设范围内所有网约车的位置，并直接根据网约车的位置计算每个司机的接驾时间，以将该订单派发给接驾时间最短的司机。

然而，上述派单方式会导致出现掉头单或绕路单(即，司机需要掉头或绕路去接驾的订单)的情况，进而导致耗费司机和乘客较多的时间，影响司机和乘客双方的体验。

技术实现要素：

有鉴于此，本申请提供一种处理订单的方法、装置、设备及存储介质，可以为司机和乘客节约时间，提升司机和乘客双方的体验。

具体地，本申请是通过如下技术方案实现的：

根据本申请的第一方面，提出了一种处理订单的方法，包括：确定以乘客出发地为中心的预设范围内的至少一个待调度车辆，所述乘客出发地包括所述乘客的打车订单中的出发地；

若所述待调度车辆符合车道检测条件，则检测所述待调度车辆的车道信息，并基于所述车道信息计算所述待调度车辆的接驾信息；

基于所述接驾信息确定与所述订单匹配的目标车辆。

在一实施例中，所述符合车道检测条件包括处于多车道的路口。

在一实施例中，所述符合车道检测条件还包括处于行驶速度低于预设速度阈值的行驶状态。

在一实施例中，所述检测所述待调度车辆的车道信息，包括：

对所述待调度车辆进行定位，得到所述待调度车辆的位置以及定位精度；

若所述定位精度高于或等于预设精度阈值，则根据所述位置从预设地图库中查询所述待调度车辆的车道信息。

在一实施例中，所述检测所述待调度车辆的车道信息，包括：

获得所述待调度车辆所处道路的路面图像；

从所述路面图像中识别导向车道线；

基于所述导向车道线确定所述待调度车辆的车道信息。

在一实施例中，所述检测所述待调度车辆的车道信息，包括：

输出请求司机输入车道信息的界面；

接收所述司机在所述界面输入的所述待调度车辆的车道信息。

在一实施例中，所述基于所述车道信息计算所述待调度车辆的接驾信息，包括：

基于所述车道信息和所述出发地确定所述待调度车辆的接驾导航路线；

基于所述接驾导航路线计算所述待调度车辆的接驾信息。

根据本申请的第二方面，提出了一种处理订单的装置，包括：

待调度车辆确定模块，用于确定以乘客出发地为中心的预设范围内的至少一个待调度车辆，所述乘客出发地包括所述乘客的打车订单中的出发地；

接驾信息确定模块，用于当所述待调度车辆符合车道检测条件时，检测所述待调度车辆的车道信息，并基于所述车道信息计算所述待调度车辆的接驾信息；

目标车辆确定模块，用于基于所述接驾信息确定与所述订单匹配的目标车辆。

根据本申请的第三方面，提出了一种处理订单的设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现上述任一所述的处理订单的方法。

根据本申请的第四方面，提出了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于执行上述任一所述的处理订单的方法。

由以上技术方案可见，本申请通过确定以乘客出发地为中心的预设范围内的至少一个待调度车辆，当所述待调度车辆符合车道检测条件时，检测所述待调度车辆的车道信息，并基于所述车道信息计算所述待调度车辆的接驾信息，进而，进而基于所述接驾信息确定与所述订单匹配的目标车辆，由于接驾信息的计算过程中考虑了符合车辆检测条件的车辆的车道信息，可以提高计算订单匹配车辆的接驾信息的合理性和准确性，可以有效避免出现掉头单和绕路单，为司机和乘客节约时间，提升司机和乘客双方的体验。

附图说明

图1是本申请一示例性实施例示出的一种处理订单的方法的流程图；

图2a是本申请一示例性实施例示出的如何确定待调度车辆的车道信息的流程图；

图2b是本申请一示例性实施例示出的输出请求司机输入车道信息的界面的应用场景示意图；

图3是本申请又一示例性实施例示出的如何确定待调度车辆的车道信息的流程图；

图4是本申请又一示例性实施例示出的如何确定待调度车辆的车道信息的流程图；

图5是本申请一示例性实施例示出的如何基于车道信息计算所述待调度车辆的接驾信息的流程图；

图6是本申请一示例性实施例示出的一种处理订单的装置的结构图；

图7是本申请又一示例性实施例示出的一种处理订单的装置的结构图；

图8是本申请一示例性实施例示出的一种处理订单的设备的结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1是本申请一示例性实施例示出的一种处理订单的方法的流程图；该实施例可以应用于网约车平台的服务端(包括一台服务器或多台服务器组成的服务器机器)，或者可以应用于具有打车订单处理功能的终端设备(如智能手机、平板电脑和台式笔记本等)，以下以应用于服务端为例进行示例性说明。如图1所示，该方法包括步骤s101-s105：

在步骤s101中，确定以乘客出发地为中心的预设范围内的至少一个待调度车辆，所述乘客出发地包括所述乘客的打车订单中的出发地。

在一实施例中，乘客在呼叫网约车时，会向服务端发送包含打车订单，该打车订单中可以包括该乘客的出发地。

值得说明的是，上述打车订单除包含乘客出发地之外，还可以包含其他相关信息，如用车时间和目的地等，本实施例对此不进行限定。

在一实施例中，上述乘客出发地可以为服务端根据乘客所在地(如，乘客的终端设备自动识别出的乘客所在地)推荐的上车地点，也可以为乘客手动输入的上车地点，也可为乘客的定位点，本实施例对此不进行限定。

在一实施例中，当服务端接到乘客通过手机等智能终端发送的打车订单后，可以确定该订单中的乘客出发地，进而可以确定以乘客出发地为中心的预设范围内的至少一个待调度车辆。

在步骤s102中，若所述待调度车辆符合车道检测条件，则检测所述待调度车辆的车道信息，并基于所述车道信息计算所述待调度车辆的接驾信息。

在一实施例中，当确定以乘客出发地为中心的预设范围内的至少一个待调度车辆，可以分别判断每个待调度车辆是否符合车道检测条件。

在一实施例中，上述车道检测条件可以由开发人员根据实际需要和业务经验等信息进行设置，例如可以设置为“处于多车道的路口”；

在一实施例中，可以基于预先获取的路网数据以及该待调度车辆的位置确定该待调度车辆当前所处的道路，进而可以确定该待调度车辆是否处于多车道的路口；如果是，则可以执行后续检测该车辆的车道信息的步骤。

在此基础上，所述符合车道检测条件还可以包括“处于行驶速度低于预设速度阈值的行驶状态”。

在一实施例中，可以通过司机端(即，司机的终端设备上安装的打车平台客户端)上传的待调度车辆的实时位置信息确定该待调度车辆的行驶速度，进而可以将该行驶速度与预设速度阈值进行比较，若其小于速度阈值，则可以确定该车辆处于行驶速度低于预设速度阈值的行驶状态(包括行驶速度为0，即静止的状态)，进而可以执行后续检测该车辆的车道信息的步骤。

可以理解是，将车道检测条件设置为“处于行驶速度低于预设速度阈值的行驶状态”，可以进一步提高检测待调度车道的车道信息的准确程度，进而可以提高后续基于车道信息确定待调度车辆的接驾信息的准确性。

在一实施中，若上述至少一个待调度车辆中存在第一待调度车辆符合上述车道检测条件，则可以检测该第一待调度车辆当前的车道信息，进而可以基于检测的车道信息计算该第一待调度车辆的接驾信息。

在一实施例中，上述接驾信息可以包括接驾时间、接驾距离或其他用于评价接驾代价的接驾参数等，本实施例对此不进行限定。

在一实施例中，可以基于司机端上传的第一待调度车辆的位置确定该第一待调度车辆当前的车道信息，或者，还可以直接向司机询问该第一待调度车辆当前的车道信息。

其中，上述车道信息可以为左转车道、直行车道或右转车道等，本实施例对此不进行限定。

值得说明的是，上述检测待调度车辆的车道信息的方式还可以参见下述图2a、图3或图4所示实施例，在此先不进行详述。

在另一实施例中，若上述至少一个待调度车辆中存在第二待调度车辆不符合上述车道检测条件，则可以基于现有技术中的算法计算该第二待调度车辆的接驾信息。在一实施例中，可以根据第二待调度车辆与乘客出发地之间的距离等信息计算该第二待调度车辆的接驾信息。

在一实施例中，上述接驾信息可以包括接驾时间、接驾距离或基于接驾时间和接驾距离确定的用于评价接驾代价的接驾参数等，本实施例对此不进行限定。

在步骤s103中，基于所述至少一个待调度车辆的接驾信息确定与所述订单匹配的目标车辆。

在一实施例中，当计算上述至少一个待调度车辆中每个待调度车辆的接驾信息后，可以基于该至少一个待调度车辆的接驾信息确定与所述订单匹配的目标车辆。

在一实施例中，当计算上述至少一个待调度车辆中每个待调度车辆的接驾信息后，可以对各待调度车辆的接驾信息的数值进行排序，进而可以将接驾信息的数值最小的待调度车辆确定为与上述订单匹配的目标车辆。

举例来说，若接驾信息为接驾时间，则当计算上述至少一个待调度车辆中每个待调度车辆的接驾时间后，可以对各待调度车辆的接驾时间的长度进行排序，进而可以将接驾时间最短的待调度车辆与上述订单进行匹配。

由上述描述可知，本实施例通过确定以乘客出发地为中心的预设范围内的至少一个待调度车辆，当所述待调度车辆符合车道检测条件时，检测所述待调度车辆的车道信息，并基于所述车道信息计算所述待调度车辆的接驾信息，进而，进而基于所述接驾信息确定与所述订单匹配的目标车辆，由于接驾信息的计算过程中考虑了符合车辆检测条件的车辆的车道信息，可以提高计算订单匹配车辆的接驾信息的合理性和准确性，可以有效避免出现掉头单和绕路单，为司机和乘客节约时间，提升司机和乘客双方的体验。

图2a是本申请一示例性实施例示出的如何确定待调度车辆的车道信息的流程图；本实施例在上述实施例的基础上，以如何确定待调度车辆的车道信息为例进行示例性说明。如图2a所示，上述步骤s102中所述检测所述待调度车辆的车道信息，包括以下步骤s201-s202：

在步骤s201中，输出请求司机输入车道信息的界面。

在步骤s202中，接收所述司机在所述界面输入的所述待调度车辆的车道信息。

在一实施例中，当所述待调度车辆符合车道检测条件时，服务端可以向司机端输出请求司机输入车道信息的界面，进而服务端可以接收该司机在所述界面中输入的所述待调度车辆的车道信息。

举例来说，图2b是本申请一示例性实施例示出的输出请求司机输入车道信息的界面的应用场景示意图。如图2b所示，服务端向司机端输出的请求司机输入车道信息的界面中包括“确认当前所在车道”的请求信息，以及“左转”、“直行”以及“右转”选项和对应的箭头标识。当司机看到该请求信息后，可以点击相应的选项，如“左转”，进而服务端可以确定该待调度车辆当前的车道信息为“左转车道”。

由上述描述可知，本实施例通过输出请求司机输入车道信息的界面，并接收所述司机在所述界面输入的所述待调度车辆的车道信息，可以直接确定待调度车辆的车道信息，提高确定待调度车辆的车道信息的准确性，为后续基于待调度车辆的车道信息计算接驾信息提供准确的依据。

图3是本申请又一示例性实施例示出的如何确定待调度车辆的车道信息的流程图；本实施例在上述实施例的基础上，以如何确定待调度车辆的车道信息为例进行示例性说明。如图3所示，上述步骤s102中所述检测所述待调度车辆的车道信息，包括以下步骤s301-s302：

在步骤s301中，对所述待调度车辆进行定位，得到所述待调度车辆的位置以及定位精度。

在一实施例中，可以采用预设定位方式对所述待调度车辆进行定位，以得到所述待调度车辆的位置和定位精度。

在一实施例中，上述预设定位方式可以由开发人员根据实际业务需要进行设置，如设置为gps、基站、蓝牙、wifi和ibeacon中的一种方式，或结合其中多种方式，本实施例对此不进行限定。

值得说明的是，获取待调度车辆的定位精度的方式可以参见现有技术中的解释和说明，本实施例对此不进行限定。

在步骤s302中，若所述定位精度高于或等于预设精度阈值，则根据所述位置从预设地图库中查询所述待调度车辆的车道信息。

在一实施例中，当确定待调度车辆的定位精度高于或等于预设精度阈值时，可以根据所述位置从预设地图库中查询所述待调度车辆的车道信息。

在一实施例中，上述预设精度阈值可以由开发人员根据实际业务需要进行设置，如设置为1m、2m或5m等，本实施例对此不进行限定。

举例来说，服务端确定待调度车辆当前的gps坐标点，且确定该gps坐标点的定位精度高于预设精度阈值后，可以基于该gps坐标点查询预设地图库，以从该地图库中查询出该待调度车辆当前的车道信息。

值得说明的是，上述预设地图库可以由开发人员根据实际需要进行选取，例如可以选择服务端的地图库或第三方地图库等，本实施例对此不进行限定。

在另一实施例中，当所述定位精度低于上述预设精度阈值时，可以参见上述图2a所示实施例的方式来确定车道信息，在此不进行赘述。

由上述描述可知，本实施例通过对所述待调度车辆进行定位，得到所述待调度车辆的位置以及定位精度，并当所述定位精度高于或等于预设精度阈值时，根据所述位置从预设地图库中查询所述待调度车辆的车道信息，可以实现准确地确定待调度车辆的车道信息，为后续基于待调度车辆的车道信息计算接驾信息提供准确的依据。

图4是本申请又一示例性实施例示出的如何确定待调度车辆的车道信息的流程图；本实施例在上述实施例的基础上，以如何确定待调度车辆的车道信息为例进行示例性说明。如图4所示，上述步骤s102中所述检测所述待调度车辆的车道信息，包括以下步骤s401-s403：

在步骤s401中，获得所述待调度车辆所处道路的路面图像。

在一实施例中，当确定待调度车辆符合上述车道检测条件，即确定待调度车辆当前处于多车道的路口和/或处于行驶速度低于预设速度阈值的行驶状态时，可以获得所述待调度车辆所处道路的路面图像。

在一实施例中，可以通过待调度车辆上安装的行车记录仪，或者待调度车辆当前所处道路上述预先安装的交通摄像头，或者待调度车辆上安装的其他硬件设备等装置获取所述待调度车辆所处道路的路面图像，本实施例对此不进行限定。

在步骤s402中，从所述路面图像中识别导向车道线。

在一实施例中，当获得所述待调度车辆所处道路的路面图像后，可以基于预设的图像识别方法从所述路面图像中识别导向车道线。

值得说明的是，上述图像识别方法可以由开发人员根据实际业务需要从现有图像识别方法中进行选取，本实施例对此不进行限定。

在一实施例中，上述导向车道线可以包括现有的用于引导方向的车道标线，其可以用于指示车辆在路口驶入段应按所指方向行驶。通常情况下，在车流大、车道多的交通路口会画有此类标线，其目的在于明确行车方向，减缓交通压力。

在步骤s403中，基于所述导向车道线确定所述待调度车辆的车道信息。

在一实施例中，当从所述路面图像中识别导向车道线后，可以基于所述导向车道线确定所述待调度车辆的车道信息。

在一实施例中，可以预先构建多种导向车道线与车道信息之间的对应关系，进而当从待调度车辆的路面图像中识别出导向车道线后，可以基于该预先构建的对应关系确定待调度车辆的车道信息。

举例来说，若预先构建了导向车道线1(如，左转箭头标识)与左转车道之间的对应关系，当从待调度车辆的路面图像中识别出左转箭头标识后，可以确定待调度车辆的车道信息为左转车道。

由上述描述可知，本实施例通过获得所述待调度车辆所处道路的路面图像，并从所述路面图像中识别导向车道线，进而基于所述导向车道线确定所述待调度车辆的车道信息，可以实现准确地确定待调度车辆的车道信息，为后续基于待调度车辆的车道信息计算接驾信息提供准确的依据。

图5是本申请一示例性实施例示出的如何基于车道信息计算所述待调度车辆的接驾信息的流程图；本实施例在上述实施例的基础上，以如何基于车道信息计算所述待调度车辆的接驾信息为例进行示例性说明。如图5所示，上述步骤s102中所述检测所述待调度车辆的车道信息，可以包括以下步骤s501-s502：

在步骤s501中，基于所述车道信息和所述出发地确定所述待调度车辆的接驾导航路线。

在一实施例中，当确定待调度车辆的车道信息后，可以基于所述车道信息和所述乘客出发地确定所述待调度车辆的接驾导航路线。

举例来说，若确定待调度车辆的车道信息为左转车道，则确定该待调度车辆的接驾导航路线是由待调度车辆当前所在的左转车道到上述乘客出发地的接驾导航路线。

值得说明的是，上述基于车道信息和乘客出发地确定待调度车辆的接驾导航路线的方式可以由开发人员根据实际业务需要选取现有的路线规划方法，本实施例对此不进行限定。

在步骤s502中，基于所述接驾导航路线计算所述待调度车辆的接驾信息。

在一实施例中，当基于所述车道信息和所述出发地确定所述待调度车辆的接驾导航路线后，可以基于所述接驾导航路线计算所述待调度车辆的接驾信息。

在一实施例中，可以基于接驾导航路线、待调度车辆的行驶速度、接驾导航路线经过的路段的路况信息等计算待调度车辆的接驾时间或接驾距离等。

由上述描述可知，本实施例基于所述车道信息和所述出发地确定所述待调度车辆的接驾导航路线，并基于所述接驾导航路线计算所述待调度车辆的接驾信息，可以实现准确地确定各待调度车辆的接驾信息，进而可以为后续基于待调度车辆的接驾信息确定与所述订单匹配的目标车辆奠定基础。

与前述方法实施例相对应，本申请还提供了相应的装置的实施例。

图6是本申请一示例性实施例示出的一种处理订单的装置的结构图；如

图6所示，该装置包括：待调度车辆确定模块110、接驾信息确定模块120以及目标车辆确定模块130，其中：

待调度车辆确定模块110，用于确定以乘客出发地为中心的预设范围内的至少一个待调度车辆，所述乘客出发地包括所述乘客的打车订单中的出发地；

接驾信息确定模块120，用于当所述待调度车辆符合车道检测条件时，检测所述待调度车辆的车道信息，并基于所述车道信息计算所述待调度车辆的接驾信息；

目标车辆确定模块130，用于基于所述接驾信息确定与所述订单匹配的目标车辆。

由上述描述可知，本实施例通过确定以乘客出发地为中心的预设范围内的至少一个待调度车辆，当所述待调度车辆符合车道检测条件时，检测所述待调度车辆的车道信息，并基于所述车道信息计算所述待调度车辆的接驾信息，进而，进而基于所述接驾信息确定与所述订单匹配的目标车辆，由于接驾信息的计算过程中考虑了符合车辆检测条件的车辆的车道信息，可以提高计算订单匹配车辆的接驾信息的合理性和准确性，可以有效避免出现掉头单和绕路单，为司机和乘客节约时间，提升司机和乘客双方的体验。

图7是本申请又一示例性实施例示出的一种处理订单的装置的结构图；其中，待调度车辆确定模块210、接驾信息确定模块220以及目标车辆确定模块230与前述图6所示实施例中的待调度车辆确定模块110、接驾信息确定模块120以及目标车辆确定模块130的功能相同，在此不进行赘述。

在一实施例中，符合车道检测条件可以包括处于多车道的路口。

在一实施例中，符合车道检测条件还可以包括处于行驶速度低于预设速度阈值的行驶状态。

在一实施例中，接驾信息确定模块220，可以包括：第一信息确定单元221；

第一信息确定单元221用于：

对所述待调度车辆进行定位，得到所述待调度车辆的位置以及定位精度；

当所述定位精度高于或等于预设精度阈值时，根据所述位置从预设地图库中查询所述待调度车辆的车道信息。

在一实施例中，接驾信息确定模块220，可以包括：第二信息确定单元222；

第二信息确定单元222用于：

获得所述待调度车辆所处道路的路面图像；

从所述路面图像中识别导向车道线；

基于所述导向车道线确定所述待调度车辆的车道信息。

在一实施例中，接驾信息确定模块，可以包括：第三信息确定单元223；

第三信息确定单元223用于：

输出请求司机输入车道信息的界面；

接收所述司机在所述界面输入的所述待调度车辆的车道信息。

在一实施例中，接驾信息确定模块220还可以包括：

接驾导航路线确定单元224，用于基于所述车道信息和所述出发地确定所述待调度车辆的接驾导航路线；

接驾信息确定单元225，用于基于所述接驾导航路线计算所述待调度车辆的接驾信息。

值得说明的是，上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本发明的处理订单的装置的实施例可以应用在网络设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的，其中计算机程序用于执行上述图1～图5所示实施例提供的处理订单的方法。从硬件层面而言，如图8所示，为本发明的处理订单的设备的硬件结构图，除了图8所示的处理器、网络接口、内存以及非易失性存储器之外，所述设备通常还可以包括其他硬件，如负责处理报文的转发芯片等等；从硬件结构上来讲该设备还可能是分布式的设备，可能包括多个接口卡，以便在硬件层面进行报文处理的扩展。另一方面，本申请还提供了一种计算机可读存储介质，存储介质存储有计算机程序，计算机程序用于执行上述图1～图5所示实施例提供的处理订单的方法。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。