CN116167539A - 一种基于接驾实时路况优化网约车上车点的方法及系统 - Google Patents

Abstract

本发明公开了一种基于接驾实时路况优化网约车上车点的方法，所述方法包括以下步骤：获取出行订单的接驾路线和接驾点，监测所述接驾路线是否存在拥堵；识别接驾路线中的连续拥堵路段，所述连续拥堵路段的道路终点为所述接驾点；基于连续拥堵路段计算预估第一通行时间；当连续拥堵路段或第一通行时间满足第一预设规则时，根据接驾点和实时道路状况，获取优化上车点；将优化上车点推送至所述出行订单的乘客端。本发明通过在司机开车去乘客上车点进行接驾时，根据实时路况若接驾路线存在拥堵则计算原上车点的周边是否存在更优上车点，通过优化上车点，实现司机过去会更快去到接乘客。

Description

一种基于接驾实时路况优化网约车上车点的方法及系统

技术领域

本发明属于网约车数据处理技术领域，具体涉及一种基于接驾实时路况优化网约车上车点的方法及系统。

背景技术

网络约车逐步融入人们的生活。随着网约车技术的发展，网络车已成为人们出行的首选方式。现有技术中，乘客下单生成出行订单后，由提供服务的司机接单并提供出行服务。网约车平台会根据司机的当前位置和出行订单的接驾点生成接驾线路，分别发送到乘客和司机的客户端上。司机根据接驾线路前往接驾点，而乘客则在接驾点等待司机的到来。

经申请人研究发现，在网约车服务过程中存在如下技术问题：

然而，当乘客接驾点所在的道路存在拥堵因素时，会导致司机抵达接驾点所需的时间较长。不清楚原因的乘客，会觉得等待时间过长，使得乘客对网约车平台的用户体验降低，乘客还可能会对司机进行差评，损害司机的个人好评度并被网约车平台处罚。而因接驾点是司机无法变更的，也只能沿着拥堵道路继续前往接驾点。可见，现有技术存在影响司乘两端用户体验的问题。

现有的上车点位置推送方案，仅由网约车平台在乘客下单时进行上车点推荐，一般都是乘客常用、便于上车、距离最近的点，而普遍是以减少乘客步行距离为主的。为此，现有技术对上车点推送的其他维度考虑较少，无法更好的协调并帮助司乘两端确定上车点。

发明内容

本发明的目的是要解决上述的技术问题，提供一种基于接驾实时路况优化网约车上车点的方法及系统。

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

第一方面，本发明提供了一种基于接驾实时路况优化网约车上车点的方法，所述方法包括以下步骤：

获取出行订单的接驾路线和接驾点，监测所述接驾路线是否存在拥堵；

识别接驾路线中的连续拥堵路段，所述连续拥堵路段的道路终点为所述接驾点；

基于连续拥堵路段计算预估第一通行时间；

当连续拥堵路段或第一通行时间满足第一预设规则时，根据接驾点和实时道路状况，获取优化上车点；

将优化上车点推送至所述出行订单的乘客端。

结合第一方面，本发明还提供了第一方面的第1种实施方式，具体的，在监测所述接驾路线是否存在拥堵之前，还包括：

识别当前所述接驾路线的待行驶里程；

当所述待行驶里程满足预设里程区间时，监测所述接驾路线是否存在拥堵；所述预设距离区间为1～3km、1.5～3km或2～3km。

结合第一方面，本发明还提供了第一方面的第2种实施方式，具体的，所述第一预设规则包括：

所述连续拥堵路段的小于预设长度阈值，第一通行时间大于预设阈值时间。

结合第一方面，本发明还提供了第一方面的第3种实施方式，具体的，根据接驾点和实时道路状况，获取优化上车点，具体包括：

根据预设半径，在电子地图上以接驾点为圆心画圆，得到步行可达区域；

从步行可达区域中获取多个第一推荐点和多个第二推荐点；其中，所述第一推荐点为关联该连续拥堵路段的岔口的附近点；所述第二推荐点为所述连续拥堵路段的对向车道的途经点；

根据所述接驾路线，计算司机抵达接驾点的第一预估接驾时间；

根据所述接驾路线，逐一计算司机分别抵达多个第一推荐点的第二预估接驾时间，逐一计算司机分别抵达多个第二推荐点的第三预估接驾时间；

获取出行订单的第一预估出行时间；

根据所述接驾路线，逐一计算多个第一推荐点分别抵达出行订单终点的第二预估出行时间，逐一计算多个第二推荐点分别抵达出行订单终点的第三预估出行时间；

利用第一预估出行时间、多个第二预估出行时间和多个第三预估出行时间，根据第二预设规则算出最优解，得到优化上车点。

结合第一方面，本发明还提供了第一方面的第4种实施方式，具体的，所述预设半径为100～300m。

结合第一方面，本发明还提供了第一方面的第5种实施方式，具体的，所述第一推荐点通过以下步骤得到：

在电子地图生成步行可达区域，识别电子地图中关联所述连续拥堵路段的所有岔口；

在电子地图中获取每一所述岔口周围50m内的所有POI兴趣点；

将所有POI兴趣点作为第一推荐点返回。

结合第一方面，本发明还提供了第一方面的第6种实施方式，具体的，所述第二推荐点通过以下步骤得到：

在电子地图生成步行可达区域，识别电子地图中所述连续拥堵路段的对向车道，得到对向路段；

在所述对向路段上，按预设间距依次生成第二推荐点，返回第二推荐点。

结合第一方面，本发明还提供了第一方面的第7种实施方式，具体的，在将优化上车点推送至所述出行订单的乘客端之后，所述方法还包括：

接收乘客端发出的确认信息，所述确认信息为乘客端确认将接驾点切换为优化上车点的指令；

根据所述确认信息，将出行订单的接驾点切换为优化上车点；

基于优化上车点生成新的接驾路线和出行路线，分别发送至乘客端和司机端。

第二方面，本发明还提供了一种基于接驾实时路况优化网约车上车点的系统，所述系统包括：

获取模块，其用于获取出行订单的接驾路线和接驾点，监测所述接驾路线是否存在拥堵；

识别模块，其用于识别接驾路线中的连续拥堵路段，所述连续拥堵路段的道路终点为所述接驾点；

计算模块，其用于基于连续拥堵路段计算预估第一通行时间；

优化上车点模块，其用于当连续拥堵路段或第一通行时间满足第一预设规则时，根据接驾点和实时道路状况，获取优化上车点；

推送模块，其用于将优化上车点推送至所述出行订单的乘客端。

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

本发明提供了一种基于接驾实时路况优化网约车上车点的方法，所述方法包括以下步骤：获取出行订单的接驾路线和接驾点，监测所述接驾路线是否存在拥堵；识别接驾路线中的连续拥堵路段，所述连续拥堵路段的道路终点为所述接驾点；基于连续拥堵路段计算预估第一通行时间；当连续拥堵路段或第一通行时间满足第一预设规则时，根据接驾点和实时道路状况，获取优化上车点；将优化上车点推送至所述出行订单的乘客端。

本发明通过在司机开车去乘客上车点进行接驾时，根据实时路况若接驾路线存在拥堵则计算原上车点的周边是否存在更优上车点，通过优化上车点，实现司机过去会更快、司机去到接乘客且到目的地总耗时也会更少、乘客从旧上车点走过去时间也很短的上车点，则弹窗询问乘客是否变更上车点，以此减少乘客等待接驾时间并有效提升司乘双方体验。

本发明主要用于拥塞场景下降低司机抵达用户接驾点、降低用户等待接驾的整体时长。从而更好的满足乘客的乘车需求，提升打车体验，同时也丰富了网约车业务中的接驾导航方式。

附图说明

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

图1是本发明的一种基于接驾实时路况优化网约车上车点的系统的组成示意图；

图2是本发明的一种基于接驾实时路况优化网约车上车点的系统的应用场景图；

图3是本发明的一种基于接驾实时路况优化网约车上车点的方法的流程示意图。

具体实施方式

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

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“网约车出行服务场景”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕“网约车出行服务场景”进行描述，但是应该理解，这仅是一个示例性实施例。本申请可以应用于任何其他交通运输的交通工具，可以包括出租车、私家车、顺风车等，或其任意组合。本申请还可以包括用于网约车用车的任何服务系统。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

为了解决本申请背景技术中所述的至少一种技术问题，本申请实施例提供一种基于接驾实时路况优化网约车上车点的方法，所述方法包括以下步骤：获取出行订单的接驾路线和接驾点，监测所述接驾路线是否存在拥堵；识别接驾路线中的连续拥堵路段，所述连续拥堵路段的道路终点为所述接驾点；基于连续拥堵路段计算预估第一通行时间；当连续拥堵路段或第一通行时间满足第一预设规则时，根据接驾点和实时道路状况，获取优化上车点；将优化上车点推送至所述出行订单的乘客端。

本发明通过在司机开车去乘客上车点进行接驾时，根据实时路况若接驾路线存在拥堵则计算原上车点的周边是否存在更优上车点，通过优化上车点，实现司机过去会更快、司机去到接乘客且到目的地总耗时也会更少、乘客从旧上车点走过去时间也很短的上车点，则弹窗询问乘客是否变更上车点，以此减少乘客等待接驾时间并有效提升司乘双方体验。本发明主要用于拥塞场景下降低司机抵达用户接驾点、降低用户等待接驾的整体时长，同时减少用户乘车费用。从而更好的满足乘客的乘车需求，提升打车体验，同时也丰富了网约车业务中的接驾导航方式。下面通过可能的实现方式对本申请的技术方案进行说明。

基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

实施例1

本实施例1提供了一种基于接驾实时路况优化网约车上车点的系统，可以是用于诸如网约车、出租车、代驾服务、快车服务、拼车服务的在线运输服务平台中。如图1所示，所述系统包括获取模块、识别模块、计算模块、优化上车点模块、推送模块。

在本发明中，基于接驾实时路况优化网约车上车点的系统可以是网约车平台的应用软件系统等，可以是网约车平台的服务器。具体的，基于接驾实时路况优化网约车上车点的系统的应用场景如图2所示，系统、网络、服务请求终端(乘客端)、服务提供终端(司机端)共同构成网约车出行的功能服务架构。

在一种实施方式中，在一种实施方式中，所述服务请求终端(乘客端)用于创建出行订单。服务提供终端(司机端)用于获取出行订单，并提供用车服务。进一步的，服务请求终端(乘客端)用于供乘客手动输入上车点信息、下车点信息、或在地图界面上拖拽生成上/下车点等，以及提供乘客的当前定位。推送系统获取乘客输入的上/下车点信息，以进行更精确的上/下车点的推送，供乘客选择更换。

具体实施中，上述服务请求终端/服务提供终端可以是移动设备、手持设备、车载设备、可穿戴设备、计算设备，以及各种形式的用户设备(User Equipment，UE)，移动台(Mobile Station，MS)及终端(terminal)等。

实施例2

图3示出了本申请的实施例2提供的一种基于接驾实时路况优化网约车上车点的方法的流程示意图，本申请所提供的一种基于接驾实时路况优化网约车上车点的方法可应用于上述实施例1的系统，由基于接驾实时路况优化网约车上车点的系统执行并完成相应的方法步骤。

本发明的研发初衷为，司机与乘客接驾点之间的尚有距离时，由于道路拥堵，导致车辆行驶至接驾点所需的时间很长。如早高峰和晚高峰时，由于道路拥堵导致车辆即使距离目的地较近，但通行时间长，不仅浪费乘客的时间，而且可能出现因为长时间拥堵怠速导致司乘双方的体验感大幅度降低。为此，本发明通过监测接驾线路的的末端行驶路径是否存在拥堵。当检测道路拥堵时，通过优化上车点的方式，选择更优的上车点推送给乘客，告知新的上车点能减少接驾时间，为乘客提供更多的选择，特别是有迫切出行需要的乘客。本发明主要用于拥塞场景下降低司机接到乘客整体时长，且不过多增加出行费用和时长。从而更好的满足乘客的乘车需求，提升打车体验。

如图3所示，所述一种基于接驾实时路况优化网约车上车点的方法包括以下步骤：

S100：获取出行订单的接驾路线和接驾点，监测所述接驾路线是否存在拥堵。

在本发明中，所述系统可以通过网约车平台的业务系统，实时获取当前进行时的出行订单。出行订单一般包括了乘客端信息、司机端信息、接驾路线、出行路线、预估时间信息和预估费用等。

在一种具体实施中，监测所述接驾路线是否存在拥堵。综合系统的性能、快速、节能等多种角度，轮询间隔时间预计设定在5-10秒区间内，即监测间隔为5～10s区间内，按预定间隔时间监测是存在拥堵。

在一种实施中，所述接驾线路实质为出行订单的接驾导航路径，可直接使用该出行订单的导航数据来判断是否存在拥堵。导航数据包括实时路况信息、司机实时位置、乘客实时位置、接驾点、当前行驶路径数据等等。

在一种优选实施中，在监测所述接驾路线是否存在拥堵之前，还包括：

S110：识别当前所述接驾路线的待行驶里程；

S120：当所述待行驶里程满足预设里程区间时，监测所述接驾路线是否存在拥堵；所述预设距离区间为1～3km、1.5～3km或2～3km。

步骤S110和步骤S120的设计作用，是考虑到当司机位置距离乘客接驾点较远时，行驶时间较长，而当前的道路拥堵情况不具有较好的参考价值，为此，当司机距离乘客的一定范围后，才进行监测所述接驾路线是否存在拥堵，以此节约系统资源。

S200：识别接驾路线中的连续拥堵路段，所述连续拥堵路段的道路终点为所述接驾点。

在本发明中，针对网约车的实际业务场景，主要针对的是接驾路线最后的末端部分，即道路终点为接驾点的导航路径部分。司机在前晚，是可以根据实际情况更改行驶路段的，只是最终目的地是需要保持接驾点。

S300：基于连续拥堵路段计算预估第一通行时间。

在具体实施中，可以由导航数据预估得到第一通行时间，是本领域的公知技术，在此不过多说明。

S400：当连续拥堵路段或第一通行时间满足第一预设规则时，根据接驾点和实时道路状况，获取优化上车点。

在本发明的具体实施中，所述第一预设规则包括：所述连续拥堵路段的小于预设长度阈值，第一通行时间大于预设阈值时间。预设长度阈值设置的目的，是避免拥堵长度过长，还进优化上车点的推荐。例如，当拥堵长度超过2km时，司机已经被封堵在路上，切换接驾点的意义不大，而应该转入优化接驾线路的步骤，提醒司机根据电子地图的新的接驾线路进行行驶。通过在电子地图生成由司机当前位置行驶至接驾点的多条导航路径，选择行驶时间最短的导航路径，作为优化接驾路径，推送至司机端和乘客端并在司机端和乘客端进行显示。

在另一种具体实施中，第一通行时间大于预设阈值时间，预设阈值时间可以是5、8、10min不等。当通行时间过长时，则代表接驾时间过长，影响乘客的用车体验。

在本发明中，根据接驾点和实时道路状况，获取优化上车点，具体包括：

S410：根据预设半径，在电子地图上以接驾点为圆心画圆，得到步行可达区域。

在一种优选实施中，所述预设半径为100～300m，该预设半径是考量到乘客步行可达的范围，且步行时间一般小于2min为优。为此，通过步行可达区域进行挖掘优化上车点。当然，为了确保是乘客步行可达的，可以计算每个推荐点与接驾点或乘客实时定位的步行时间，将大于2～3分钟的排除。

S420：从步行可达区域中获取多个第一推荐点和多个第二推荐点；其中，所述第一推荐点为关联该连续拥堵路段的岔口的附近点；所述第二推荐点为所述连续拥堵路段的对向车道的途经点。

在本发明中，通过考量避开拥堵路段，设计了第一推荐点和第二推荐点。具体的，所述第一推荐点通过以下步骤得到：

S421：在电子地图生成步行可达区域，识别电子地图中关联所述连续拥堵路段的所有岔口。

通过电子地图，即可在步行可达区域内识别出所有关联所述连续拥堵路段的所有岔口，岔口是城市道路交叉口，交叉口是两条或两条以上道路的交会处。是车辆、行人交通汇集、转向和疏散的必经之处。按相交道路的条数可分为三岔、四岔和多岔等，因为岔口是车辆更改当前道路的方法。

S422：在电子地图中获取每一所述岔口周围50m内的所有POI兴趣点；

根据岔口获取50m内的POI兴趣点，一方面其在电子地图中已经是现有数据，方便查找筛选，也方便司机停靠接上乘客。一个POI可以是一栋房子、一个商铺、一个邮筒、一个公交站等。

S423：将所有POI兴趣点作为第一推荐点返回。

基于步骤S410的考虑，可以计算每个推荐点与接驾点或乘客实时定位的步行时间，将大于2～3分钟的排除；剩余的POI兴趣点作为第一推荐点返回。

在一种具体实施中，所述第二推荐点通过以下步骤得到：

S424：在电子地图生成步行可达区域，识别电子地图中所述连续拥堵路段的对向车道，得到对向路段。

通过电子地图，即可在步行可达区域内识别出连续拥堵路段的对向车道。对向车道,就是道路上跟自己相反方向,对面行驶过来的车辆所占的车道就是对向车道。对向车道是直接更换了车辆行驶的方向，在普遍的道路状况中，往往拥堵路段的对向车道是畅通的，乘客只需要步行到对面车道，即可快速接驾上车。

S425：在所述对向路段上，按预设间距依次生成第二推荐点，返回第二推荐点。

具体的，预设间距可以是5～10m。基于步骤S410的考虑，可以计算每个第二推荐点与接驾点或乘客实时定位的步行时间，将大于2～3分钟的排除；剩余的第二推荐点返回。

S430：根据所述接驾路线，计算司机抵达接驾点的第一预估接驾时间。

S440：根据所述接驾路线，逐一计算司机分别抵达多个第一推荐点的第二预估接驾时间，逐一计算司机分别抵达多个第二推荐点的第三预估接驾时间。

S450：获取出行订单的第一预估出行时间。

S460：根据所述接驾路线，逐一计算多个第一推荐点分别抵达出行订单终点的第二预估出行时间和第二预估费用，逐一计算多个第二推荐点分别抵达出行订单终点的第三预估出行时间和第三预估费用。

S470：利用第一预估出行时间、多个第二预估出行时间和多个第三预估出行时间，根据第二预设规则算出最优解，得到优化上车点。

在本发明一种具体实施中，第二预设规则可以是推荐点需要同时满足司机接驾节省时间B、接驾+送驾总时间节省时间C。具体的，司机接驾节省时间不小于B，B预计设定在3分钟，接驾+送驾总节省时间不小于C，C预计设定在5分钟

在本发明一种具体实施中，司机抵达一个推荐点的导航路径可能有多条，需要计算每个推荐点的多个导航路径，得到多个预估出行时间。将时间最短的导航路径的预估出行时间作为该推荐点的预估出行时间使用。

S500：将优化上车点推送至所述出行订单的乘客端。

在一种优选实施中，所述优化上车点通过弹窗方式进行推送，并在显示信息中注明拥堵原因、更换原因、更换后的时间优势信息等。

在本发明的优选实施中，所述方法还包括：

S600：接收乘客端发出的确认信息，所述确认信息为乘客端确认将接驾点切换为优化上车点的指令。

S700：根据所述确认信息，将出行订单的接驾点切换为优化上车点；

S800：基于优化上车点生成新的接驾路线和出行路线，分别发送至乘客端和司机端。

在S800中，新的接驾路线，是推荐点的多个导航路径中时间最短的导航路径。

本实施例所述一种基于接驾实时路况优化网约车上车点的方法及系统的其它结构参见现有技术。

以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，故凡是未脱离本发明技术方案内容，依据本发明的技术实质对以上实施例所作的任何修改、等同变化与修饰,均仍属于本发明技术方案的范围内。

Claims (9)

1.一种基于接驾实时路况优化网约车上车点的方法，其特征在于，所述方法包括以下步骤：

获取出行订单的接驾路线和接驾点，监测所述接驾路线是否存在拥堵；

识别接驾路线中的连续拥堵路段，所述连续拥堵路段的道路终点为所述接驾点；

基于连续拥堵路段计算预估第一通行时间；

当连续拥堵路段或第一通行时间满足第一预设规则时，根据接驾点和实时道路状况，获取优化上车点；

将优化上车点推送至所述出行订单的乘客端。

2.根据权利要求1所述的一种基于接驾实时路况优化网约车上车点的方法，其特征在于，在监测所述接驾路线是否存在拥堵之前，还包括：

识别当前所述接驾路线的待行驶里程；

当所述待行驶里程满足预设里程区间时，监测所述接驾路线是否存在拥堵；所述预设距离区间为1～3km、1.5～3km或2～3km。

3.根据权利要求2所述的一种基于接驾实时路况优化网约车上车点的方法，其特征在于，所述第一预设规则包括：

所述连续拥堵路段的小于预设长度阈值，第一通行时间大于预设阈值时间。

4.根据权利要求3所述的一种基于接驾实时路况优化网约车上车点的方法，其特征在于，根据接驾点和实时道路状况，获取优化上车点，具体包括：

根据预设半径，在电子地图上以接驾点为圆心画圆，得到步行可达区域；

从步行可达区域中获取多个第一推荐点和多个第二推荐点；其中，所述第一推荐点为关联该连续拥堵路段的岔口的附近点；所述第二推荐点为所述连续拥堵路段的对向车道的途经点；

根据所述接驾路线，计算司机抵达接驾点的第一预估接驾时间；

根据所述接驾路线，逐一计算司机分别抵达多个第一推荐点的第二预估接驾时间，逐一计算司机分别抵达多个第二推荐点的第三预估接驾时间；

获取出行订单的第一预估出行时间；

根据所述接驾路线，逐一计算多个第一推荐点分别抵达出行订单终点的第二预估出行时间，逐一计算多个第二推荐点分别抵达出行订单终点的第三预估出行时间；

利用第一预估出行时间、多个第二预估出行时间和多个第三预估出行时间，根据第二预设规则算出最优解，得到优化上车点。

5.根据权利要求4所述的一种基于接驾实时路况优化网约车上车点的方法，其特征在于：

所述预设半径为100～300m。

6.根据权利要求4所述的一种基于接驾实时路况优化网约车上车点的方法，其特征在于，所述第一推荐点通过以下步骤得到：

在电子地图生成步行可达区域，识别电子地图中关联所述连续拥堵路段的所有岔口；

在电子地图中获取每一所述岔口周围50m内的所有POI兴趣点；

将所有POI兴趣点作为第一推荐点返回。

7.根据权利要求4所述的一种基于接驾实时路况优化网约车上车点的方法，其特征在于，所述第二推荐点通过以下步骤得到：

在电子地图生成步行可达区域，识别电子地图中所述连续拥堵路段的对向车道，得到对向路段；

在所述对向路段上，按预设间距依次生成第二推荐点，返回第二推荐点。

8.根据权利要求1所述的一种基于接驾实时路况优化网约车上车点的方法，其特征在于，在将优化上车点推送至所述出行订单的乘客端之后，所述方法还包括：

接收乘客端发出的确认信息，所述确认信息为乘客端确认将接驾点切换为优化上车点的指令；

根据所述确认信息，将出行订单的接驾点切换为优化上车点；

基于优化上车点生成新的接驾路线和出行路线，分别发送至乘客端和司机端。

9.一种基于接驾实时路况优化网约车上车点的系统，其特征在于，所述系统包括：

获取模块，其用于获取出行订单的接驾路线和接驾点，监测所述接驾路线是否存在拥堵；

识别模块，其用于识别接驾路线中的连续拥堵路段，所述连续拥堵路段的道路终点为所述接驾点；

计算模块，其用于基于连续拥堵路段计算预估第一通行时间；

优化上车点模块，其用于当连续拥堵路段或第一通行时间满足第一预设规则时，根据接驾点和实时道路状况，获取优化上车点；

推送模块，其用于将优化上车点推送至所述出行订单的乘客端。

Images