CN114881728A - 一种拼车方法和装置 - Google Patents

Abstract

本发明公开了一种拼车方法和装置，包括：获取乘客端的专车订单请求，并创建专车订单；基于预设分类规则对专车订单进行分类；发送拼单请求至属于同一类专车订单下的乘客端；将接受拼单请求的专车订单转换为拼车订单。对于这些乘车需求相同的乘客，基于现有的乘车模式，通过预设分类规则识别这些乘车需求相同的乘客端，将这些乘客端的专车订单汇集，并发送拼单请求至乘客端，将接受拼单请求的专车订单转换为拼车订单，可节省网约车的运力，同时也给司机带来更多收入，节省每个乘客乘车费用。

Description

一种拼车方法和装置

技术领域

本发明属于网约车技术领域，具体涉及一种拼车方法和装置。

背景技术

在日常生活中，网约车有两种打车模式，一种为专车出行，另一种为拼车出行。在专车出行中，乘客端发起专车订单请求，网约车系统给该乘客端创建专车订单，并搜索乘客端附近的司机端，指定一司机端专车接送该乘客，并在接送该乘客的路途中，该司机端不再接收其他订单；在拼车出行中，乘客端发起拼车订单请求，司机端前往拼车订单的起点，在司机端驾驶机动车前往拼车订单的起点过程中，司机端可接收其他乘客的拼车订单，并且在司机端在接送该乘客端的路途中，也可接收其他乘客的拼车订单。

一般来说，对于乘客端来说，专车出行花费的时间更短，拼车出行花费的金额较少，对于赶时间的乘客来说，更愿意选择专车出行。而对于司机端来说，为了节省成本，会一次接更多的拼车订单，直至达到乘车人数阈值。

为了避免拼车时等待与绕路的问题，许多乘客即使时间充足，也宁愿选择专车出行而不选择拼车出车。而实际上这些乘客的附近存在大量相同需求的乘客，这些乘客的起点和终点相差距离不远，但每个乘客端均需配置对应的司机端，造成了现阶段网约车运力的浪费，特别是在乘车高峰期，还容易造成交通拥堵。

发明内容

本发明的目的是要解决上述的技术问题，提供一种拼车方法和装置。

为了解决上述问题，本发明按以下技术方案予以实现的：

第一方面，本发明提供了一种拼车方法，包括：

获取乘客端的专车订单请求，并创建专车订单；

基于预设分类规则对专车订单进行分类；

发送拼单请求至属于同一类专车订单下的乘客端；

将接受拼单请求的专车订单转换为拼车订单。

结合第一方面，本发明还提供了第一方面的第1种实施方式，将接受拼单请求的专车订单转换为拼车订单后，还包括：

获取司机端的乘车人数阈值；

统计拼车订单的乘客总数，按照拼车订单的乘客总数匹配对应的司机端。

结合第一方面，本发明还提供了第一方面的第2种实施方式，还包括：

获取司机端的乘车人数阈值；

统计同一类专车订单中的乘客总数，按照同一类专车订单中的乘客总数匹配对应的司机端，并将专车订单的匹配状态设定为预匹配状态。

结合第一方面，本发明还提供了第一方面的第3种实施方式，还包括：

将拼车订单的匹配状态转换为已匹配状态，并按照预匹配状态分配对应的司机端；

将未转换为拼车订单的专车订单的匹配状态转换为未匹配状态，并重新分配司机端给专车订单。

结合第一方面，本发明还提供了第一方面的第4种实施方式，在基于预设分类规则对专车订单进行分类，具体包括：

获取专车订单的起点数据和终点数据，并将起点数据和终点数据映射至网格地图中；所述网格地图将地图划分为若干网格；

将网格地图中起点和终点均位于同一网格的专车订单分为同一类，并建立类别数据集。

第一方面，本发明提供了一种拼车装置，包括：

订单创建模块，所述订单创建模块用于获取乘客端的专车订单请求，并创建专车订单；

订单分类模块，所述订单分类模块用于基于预设分类规则对专车订单进行分类；

拼单请求发送模块，所述拼单请求发送模块用于发送拼单请求至属于同一类专车订单下的乘客端；

订单转换模块，所述订单转换模块用于将接受拼单请求的专车订单转换为拼车订单。

结合第二方面，本发明还提供了第二方面的第1种实施方式，还包括：

第一获取模块，所述第一获取模块用于获取司机端的乘车人数阈值；

匹配模块，所述匹配模块用于统计拼车订单的乘客总数，按照拼车订单的乘客总数匹配对应的司机端。

结合第二方面，本发明还提供了第二方面的第2种实施方式，还包括：

第二获取模块，所述第二获取模块用于获取司机端的乘车人数阈值；

匹配状态设定模块，所述匹配状态设定模块用于统计同一类专车订单中的乘客总数，按照同一类专车订单中的乘客总数匹配对应的司机端，并将专车订单的匹配状态设定为预匹配状态。

结合第二方面，本发明还提供了第二方面的第3种实施方式，还包括：

第一转换模块，所述第一转换模块用于将拼车订单的匹配状态转换为已匹配状态，并按照预匹配状态分配对应的司机端；

第二转换模块，所述第二转换模块用于将未转换为拼车订单的专车订单的匹配状态转换为未匹配状态，并重新分配司机端给专车订单。

结合第二方面，本发明还提供了第二方面的第4种实施方式，所述订单分类模块包括：

映射单元，所述映射单元用于获取专车订单的起点数据和终点数据，并将起点数据和终点数据映射至网格地图中；所述网格地图将地图划分为若干网格；

划分单元，所述划分单元用于将网格地图中起点和终点均位于同一网格的专车订单划分为同一类，并建立类别数据集。

与现有技术相比，本发明的有益效果是：

本实施例中，对于这些乘车需求相同的乘客，基于现有的乘车模式，通过预设分类规则识别这些乘车需求相同的乘客端，将这些乘客端的专车订单汇集，并发送拼单请求至乘客端，将接受拼单请求的专车订单转换为拼车订单，可节省网约车的运力，同时也给司机带来更多收入，节省每个乘客的乘车费用。

附图说明

下面结合附图对本发明的具体实施方式作进一步详细的说明，其中：

图1是本发明的拼车方法的流程示意图；

图2是本发明的拼车装置的结构示意图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

下面将参照附图更详细地描述本公开的优选实施例。虽然附图中显示了本公开的优选实施例，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

在本文中使用的术语“包括”及其变形表示开放性包括，即“包括但不限于”。除非特别申明，术语“或”表示“和/或”。术语“基于”表示“至少部分地基于”。术语“一个示例实施例”和“一个实施例”表示“至少一个示例实施例”。术语“另一实施例”表示“至少一个另外的实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

现有网约车的拼车模式通常为：乘客甲发起拼车订单A，司机端接收该拼车订单A，并开车前往订单A开始位置去接取乘客甲，在拼车订单A成立时并会搜索开始位置的附近的其他乘客发起的拼车订单B，或在送往乘客甲的途中搜索路途中的拼车订单C。在这种拼车模式中，等待和接送其他乘客会浪费大量时间。当时间充足时，人们乐意选择“拼车”方案以节省乘车费用，但是当乘客赶时间时，通常会选择专车接送，避免等待接送其他乘客的时间。

在生活中，越来越多乘客选择放弃拼车模式而选择专车接送，每个乘客均占用一辆网约车。但是生活中一部分乘客的起点和终点均较为接近，选择专车接送时容易造成网约车平台的运力不足，特别是在乘车高峰期，还容易造成交通拥堵。例如，在下班时，同一栋大楼下班的乘客甲和乘客乙分别选择专车接送以前往同一地铁站搭车回家，实际上乘客甲和乘客乙仅需一辆网约车，分别选择专车接送造成了网约车运力的浪费。

实施例1

如图1所示，本发明所述的一种拼车方法，包括以下步骤：

步骤S1：获取乘客端的专车订单请求，并创建专车订单；

步骤S2：基于预设分类规则对专车订单进行分类；

步骤S3：发送拼单请求至属于同一类专车订单下的乘客端；

步骤S4：将接受拼单请求的专车订单转换为拼车订单。

本实施例中，对于这些乘车需求相同的乘客，本申请基于现有的乘车模式，通过预设分类规则识别这些乘车需求相同的乘客端，将这些乘客端的专车订单汇集，并发送拼单请求至乘客端，将接受拼单请求的专车订单转换为拼车订单，可节省网约车的运力，同时也给司机带来更多收入，节省每个乘客的乘车费用。

步骤S1：获取乘客端的专车订单请求，并创建专车订单。

在此模式中，乘客端以正常的专车模式生成专车订单，在建立专车订单之前，乘客需填写乘车需求，包括乘车起点、乘车终点、乘车人数等数据，网约车系统根据乘车需求生成专车订单。

步骤S2：基于预设分类规则对专车订单进行分类。

通过预设分类规则，识别出专车订单中乘车需求相同的乘客，乘车需求相同可表现为：乘车起点相近、乘车终点相近或在同一条行车轨迹上，将这些相同乘车需求的专车订单归属于同一类并建立集合，便于同一配置网约车司机。

在一优选实施例中，在基于预设分类规则对专车订单进行分类，具体包括：

步骤S201：获取专车订单的起点数据和终点数据，并将起点数据和终点数据映射至网格地图中；所述网格地图将地图划分为若干网格；

步骤S202：将网格地图中起点和终点均位于同一网格的专车订单分为同一类，并建立类别数据集。

在步骤S201～S202中，对所选城市建立网格地图，按照分层网格系统，将所选城市地图铺满多边形网格，并按照实时路况信息，对经纬度进行编码，按照不同发网格精度，变成不同位数的编码，在同一多边形网格的经纬度坐标编码相同。若两个专车订单的起点编码和终点编码均相同，可表明这两个专车订单的乘客端的乘车需求相同，可将这两个专车订单归属于同一类。多边形网格的宽度可根据实际乘车情况进行灵活调节，例如：正常工作日的上班和下班时间段内，多边形网格的宽度较小，属于同一多边形网格的起点位置和终点位置更接近，反应的乘客端的乘车需求更接近；在节假日，乘客出行目的更多为逛街或购物，此时可将多边形网格的宽度调大一点。本实施例中多边形网格优选为六边形网格，由于六边形的面积周长比较低，可减少由于网格形状的边界效应带来的样本偏差，且六边形网格与其周围网格之间质心的距离相等，六边形网格铺满整个时空区域后没有间隙。

在一优选实施例中，根据实时路况，将属于同一条街道的经纬度坐标设置相同编码，由于多边形网格的宽度是设定的，不会随实时路况进行改变，可能将属于同一条街道划分进两个多边形网格，甚至更多。而实时路况中存在大量单行道，司机在行车时需跑完整条街道，不存在接送另一个人出现绕路的问题，即使这两个经纬度坐标分别位于不同的两个多边形网格，但一个订单的行车轨迹为另一个订单行车轨迹的延续路段，也将这两个专车订单划分为同一类。

在一优选实施例中，本实施例仅针对预设路程的短程专车订单。例如，用户A和用户B均为起点和终点均在同一网格内，且订单路程均在2.5KM内。

步骤S3：发送拼单请求至属于同一类专车订单下的乘客端。

步骤S4：将接受拼单请求的专车订单转换为拼车订单。

在步骤S3～S4中，当两个或以上的专车订单归属于同一类时，通过乘客端app发送拼单请求给乘客端，并在拼单请求中表明拼单的其他乘客信息，若该乘客同意该拼单请求，并将该乘客的专车订单转换为拼车订单，若该乘客不同意拼车订单，则为该乘客匹配其他司机端。

在一实施例中，将接受拼单请求的专车订单转换为拼车订单后，还包括：

步骤S5：获取司机端的乘车人数阈值。

步骤S6：统计拼车订单的乘客总数，按照拼车订单的乘客总数匹配对应的司机端。

在步骤S5～S6中，在此实施例中，先撮合接收拼单请求的乘客端，再为这些乘客匹配对应的司机端。在司机端注册网约车平台作为该网约车平台的司机时，需上传对应网约车的相关信息，其中包含该网约车的座位总数，而一般网约车司机占用一个司机座，剩余作为座位作为乘客座，一般网约车的乘客座的数量为3～5。统计属于同一类拼车订单的总人数，按照司机端的座位数量给这些拼车订单分配司机端，确保拼车后的每个乘客在搭乘该网约车时有座位可座。

在一优选实施例中，若乘客端专车订单的人数超过3人时，不再向该乘客端发送拼车请求，由于该专车订单的乘客总数已满足网约车的乘客座数，避免其他拼单乘客无座位可坐，同时也避免给司机带来经济上的损失，保证司机端的利益。

在另一实施例中，还包括：

步骤S7：获取司机端的乘车人数阈值。

步骤S8：统计同一类专车订单中的乘客总数，按照同一类专车订单中的乘客总数匹配对应的司机端，并将专车订单的匹配状态设定为预匹配状态。

步骤S9：将拼车订单的匹配状态转换为已匹配状态，并按照预匹配状态分配对应的司机端；

步骤S10：将未转换为拼车订单的专车订单的匹配状态转换为未匹配状态，并重新分配司机端给专车订单。

在步骤S7～S10中，在此实施例中，给订单添加匹配状态标签，按照同一类专车订单中的乘客总数匹配对应的司机端，并将专车订单的匹配状态设定为预匹配状态。若在设定时间内，存在相同乘车需求的其他专车订单，先向最早建立专车订单的用户发送拼车请求，再向该乘客端发送拼车请求，若该乘客接收拼车请求，则将该乘客的专车订单转换为拼车订单，并将该拼车订单的状态转换为已匹配状态，若其他乘客也接收拼单请求，也同样将其他乘客的专车订单转换为拼车订单并将拼车订单的状态转换为已匹配状态。若第一个乘客端不同意拼车请求，或在设定时间内无相同乘车需求的其他专车订单，则将该专车订单从预匹配状态转换为未匹配状态，并为该专车订单分配专车司机端。

综上所述，当本发明方法执行时，一方面，通过预设分类规则识别这些乘车需求相同的乘客端，将这些乘客端的专车订单汇集，并发送拼单请求至乘客端，将接受拼单请求的专车订单转换为拼车订单，可节省网约车的运力，同时也给司机带来更多收入，每个乘客节省乘车费用。另一方面，通过多边形网格建立的网格地图可灵活调整多边形宽度的大小，并结合实时路况信息，对经纬度进行编码，精准查询乘车需求相同的乘客端。

本发明所述拼车方法的其它步骤参照现有技术。

实施例2

如图2所示，第二方面，本发明公开了一种拼车装置，包括订单创建模块M1、订单分类模块M2、拼单请求发送模块M3和订单转换模块M4。

所述订单创建模块M1用于获取乘客端的专车订单请求，并创建专车订单；

所述订单分类模块M2用于基于预设分类规则对专车订单进行分类；

所述拼单请求发送模块M3用于发送拼单请求至属于同一类专车订单下的乘客端；

所述订单转换模块M4用于将接受拼单请求的专车订单转换为拼车订单。

针对第二方面，还包括第1种优选实施，还包括第一获取模块M5和匹配模块M6。

所述第一获取模块M5用于获取司机端的乘车人数阈值；

所述匹配模块M6用于统计拼车订单的乘客总数，按照拼车订单的乘客总数匹配对应的司机端。

针对第二方面，还包括第2种优选实施，还包括第二获取模块M7和匹配状态设定模块M8。

第二获取模块M7用于获取司机端的乘车人数阈值；

所述匹配状态设定模块M8用于统计同一类专车订单中的乘客总数，按照同一类专车订单中的乘客总数匹配对应的司机端，并将专车订单的匹配状态设定为预匹配状态。

针对第二方面，还包括第3种优选实施，还包括第一转换模块M9和第二转换模块M10。

所述第一转换模块M9用于将拼车订单的匹配状态转换为已匹配状态，并按照预匹配状态分配对应的司机端；

所述第二转换模块M10用于将未转换为拼车订单的专车订单的匹配状态转换为未匹配状态，并重新分配司机端给专车订单。

针对第二方面，还包括第4种优选实施，所述订单分类模块M2包括：

映射单元，所述映射单元用于获取专车订单的起点数据和终点数据，并将起点数据和终点数据映射至网格地图中；所述网格地图将地图划分为若干网格；

划分单元，所述划分单元用于将网格地图中起点和终点均位于同一网格的专车订单划分为同一类，并建立类别数据集。

综上所述，本实施例所述装置在运行时，能实现实施例1中所述的拼单方法的全部步骤，以实现实施例1中所达到的技术效果。

本实施例所述的拼单装置的其它结构参见现有技术。

实施例3

本发明还公开一种电子设备，至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，所述至少一个处理器执行指令时，具体实现以下的步骤：

获取乘客端的专车订单请求，并创建专车订单；

基于预设分类规则对专车订单进行分类；

发送拼单请求至属于同一类专车订单下的乘客端；

将接受拼单请求的专车订单转换为拼车订单。

实施例4

本发明还公开一种存储介质，存储有计算机程序，所述计算机程序被处理器执行时，具体实现以下步骤：

获取乘客端的专车订单请求，并创建专车订单；

基于预设分类规则对专车订单进行分类；

发送拼单请求至属于同一类专车订单下的乘客端；

将接受拼单请求的专车订单转换为拼车订单。

本公开可以是方法、装置、系统和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本公开的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，上述编程语言包括面向对象的编程语言—诸如Smalltalk、C++、Java等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。

以上已经描述了本公开的各实施方式，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施方式。在不偏离所说明的各实施方式的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施方式的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文披露的各实施方式。

Claims (10)

1.一种拼车方法，其特征在于，包括：

获取乘客端的专车订单请求，并创建专车订单；

基于预设分类规则对专车订单进行分类；

发送拼单请求至属于同一类专车订单下的乘客端；

将接受拼单请求的专车订单转换为拼车订单。

2.根据权利要求1所述的一种拼车方法，其特征在于，将接受拼单请求的专车订单转换为拼车订单后，还包括：

获取司机端的乘车人数阈值；

统计拼车订单的乘客总数，按照拼车订单的乘客总数匹配对应的司机端。

3.根据权利要求1所述的一种拼车方法，其特征在于，还包括：

获取司机端的乘车人数阈值；

统计同一类专车订单中的乘客总数，按照同一类专车订单中的乘客总数匹配对应的司机端，并将专车订单的匹配状态设定为预匹配状态。

4.根据权利要求3所述的一种拼车方法，其特征在于，还包括：

将拼车订单的匹配状态转换为已匹配状态，并按照预匹配状态分配对应的司机端；

将未转换为拼车订单的专车订单的匹配状态转换为未匹配状态，并重新分配司机端给专车订单。

5.根据权利要求1所述的一种拼车方法，其特征在于，在基于预设分类规则对专车订单进行分类，具体包括：

获取专车订单的起点数据和终点数据，并将起点数据和终点数据映射至网格地图中；所述网格地图将地图划分为若干网格；

将网格地图中起点和终点均位于同一网格的专车订单分为同一类，并建立类别数据集。

6.一种拼车装置，其特征在于，包括：

订单创建模块，所述订单创建模块用于获取乘客端的专车订单请求，并创建专车订单；

订单分类模块，所述订单分类模块用于基于预设分类规则对专车订单进行分类；

拼单请求发送模块，所述拼单请求发送模块用于发送拼单请求至属于同一类专车订单下的乘客端；

订单转换模块，所述订单转换模块用于将接受拼单请求的专车订单转换为拼车订单。

7.根据根据权利要求6所述的一种拼车装置，其特征在于，还包括：

第一获取模块，所述第一获取模块用于获取司机端的乘车人数阈值；

匹配模块，所述匹配模块用于统计拼车订单的乘客总数，按照拼车订单的乘客总数匹配对应的司机端。

8.根据权利要求6所述的一种拼车装置，其特征在于，还包括：

第二获取模块，获取司机端的乘车人数阈值；

匹配状态设定模块，所述匹配状态设定模块用于统计同一类专车订单中的乘客总数，按照同一类专车订单中的乘客总数匹配对应的司机端，并将专车订单的匹配状态设定为预匹配状态。

9.根据权利要求8所述的一种拼车装置，其特征在于，还包括：

第一转换模块，所述第一转换模块用于将拼车订单的匹配状态转换为已匹配状态，并按照预匹配状态分配对应的司机端；

第二转换模块，所述第二转换模块用于将未转换为拼车订单的专车订单的匹配状态转换为未匹配状态，并重新分配司机端给专车订单。

10.根据权利要求6所述的一种拼车方法，其特征在于，所述订单分类模块包括：

映射单元，所述映射单元用于获取专车订单的起点数据和终点数据，并将起点数据和终点数据映射至网格地图中；所述网格地图将地图划分为若干网格；

划分单元，所述划分单元用于将网格地图中起点和终点均位于同一网格的专车订单划分为同一类，并建立类别数据集。

Images