[0001] 本发明涉及智慧出行领域，具体而言，涉及一种改善乘客等待体验的优化方法、装置、计算机设备及可读存储介质。

[0002] 在现代交通出行领域，尤其是网约车服务中，乘客等待司机接驾的体验至关重要。传统的仅展示真实车辆坐标的方式在一些情况下可能无法很好地满足乘客的心理预期。例如在较长的预估接驾距离或者交通拥堵场景下，乘客看到车辆缓慢靠近可能会产生焦虑情绪。并且不同的打车渠道和城市交通状况差异较大，单一的位置显示方式缺乏针对性优化。

[0045] 为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

[0046] 下面结合附图，对本发明的具体实施方式进行详细说明。

[0047] 为了解决前述背景技术中的技术问题，图1为本公开实施例提供的改善乘客等待体验的优化方法的流程示意图，下面对该改善乘客等待体验的优化方法进行详细介绍。

[0048] 步骤S201，获取司机端的当前接驾状态和乘客端的当前等待状态，所述当前接驾状态包括司机当前位置信息，所述当前等待状态包括乘客当前位置信息；

[0049] 步骤S202，根据所述当前位置信息和所述乘客当前位置信息，构建导航路线；

[0050] 步骤S203，判断所述乘客端是否满足预设优化条件；

[0051] 步骤S204，若满足，则生成幻影车辆坐标，并将配置了所述幻影车辆坐标的导航路线推送至所述乘客端，所述幻影车辆坐标为基于真实车辆坐标优化后得到的持续反馈的模拟车辆坐标；

[0052] 步骤S205，若不满足，则生成真实车辆坐标，并将配置了所述真实车辆坐标的导航路线推送至所述乘客端。

[0053] 在本发明实施例中，示例性的：

[0054] 一、获取司机端的当前接驾状态和乘客端的当前等待状态。

[0055] 场景一：正常接单情况

[0056] 1.司机端状态获取

[0057] 当司机在打车平台上接受一个订单时，服务器开始对司机端的状态进行获取。服务器与司机端设备保持通信连接，司机端设备(如安装在司机手机上的打车应用)通过GPS等定位技术获取自己的当前位置信息，例如司机位于经度为116.4074°，纬度为39.9042°的地点。同时，司机端还会将自身的一些其他接驾状态信息发送给服务器，如车辆的行驶方向(假设为向北行驶)、车辆的速度(假设为30千米/小时)等。这些信息构成了司机当前接驾状态的一部分。

[0058] 司机端还会将自身的接单时间(假设为2023年10月1日10:00)、司机预计到达乘客位置的预估接驾时间(假设根据当前交通状况和距离预估为10分钟)等信息发送给服务器。

[0059] 2.乘客端状态获取

[0060] 乘客在自己的手机上使用打车应用下单后，服务器会获取乘客端的当前等待状态。乘客端的应用通过手机的定位功能获取乘客的当前位置信息，例如乘客位于经度为116.3975°，纬度为39.9100°的商场门口。

[0061] 服务器还会获取乘客端的一些其他相关信息，如乘客的订单类型(假设为普通快车订单)、乘客的特殊需求(例如携带宠物，需要宽敞的车内空间)等。这些信息虽然与位置无关，但也是乘客当前等待状态的一部分，对于后续的服务优化可能会有影响。

[0062] 场景二：网络波动情况

[0063] 1.司机端

[0064] 假设司机在行驶过程中，经过一个网络信号不好的区域，比如进入了一个地下停车场。司机端的设备可能会暂时失去与服务器的稳定连接。但是，司机端的应用会在本地缓存一部分接驾状态信息，如最近一次获取的位置信息、行驶方向等。当司机驶离地下停车场，网络恢复时，司机端会立即将缓存的信息以及新的状态信息(如在停车场内行驶后的新位置等)发送给服务器。

[0065] 2.乘客端

[0066] 如果乘客所在的区域网络也不稳定，例如在高楼大厦之间信号被遮挡。乘客端的应用可能会出现刷新缓慢的情况。但乘客端会在本地记录下单信息和初步获取的位置信息。一旦网络恢复，服务器会重新获取乘客端完整的当前等待状态，包括可能更新后的位置信息(如果乘客在网络不稳定期间移动了一小段距离)。

[0067] 二、根据当前位置信息和乘客当前位置信息，构建导航路线。

[0068] 场景一：常规导航构建

[0069] 1.计算最短路径

[0070] 服务器在获取到司机的当前位置(经度为116.4074°，纬度为39.9042°)和乘客的当前位置(经度为116.3975°，纬度为39.9100°)后，会调用地图导航算法来构建从司机位置到乘客位置的导航路线。假设服务器使用的是Dijkstra算法，它会考虑道路的类型(如主干道、次干道)、交通状况(通过与交通管理部门的数据交互或者基于平台上其他司机的行驶速度数据进行估算)等因素。

[0071] 服务器计算出一条最短路径，例如先沿着当前道路行驶1千米到达一个十字路口，然后左转进入另一条主干道，再行驶2千米后到达乘客所在的商场门口。这条路径上的各个坐标点(如每个路口的坐标、关键路段的起点和终点坐标等)都会被记录下来，同时计算出每个路段的距离，形成完整的导航路线信息。

[0072] 2.考虑交通限制

[0073] 如果在构建导航路线时，发现某些路段存在交通限制，例如某条道路在特定时间段内是单行道，或者正在进行道路施工。服务器会重新规划路线，避开这些限制路段。比如，原本的最短路径中有一段道路正在施工无法通行，服务器会重新计算出一条替代路线，可能会多绕行500米，但能够确保司机顺利到达乘客位置。

[0074] 场景二：多目的地情况(如果平台支持)

[0075] 1.特殊订单需求

[0076] 假设这是一个拼车订单，除了当前的乘客外，还有另一名乘客在附近的另一个地点等待。服务器在构建导航路线时，就需要综合考虑两个乘客的位置。例如，第一个乘客在商场门口(经度为116.3975°，纬度为39.9100°)，第二个乘客在距离商场500米的写字楼前(经度为116.3990°，纬度为39.9090°)。

[0077] 服务器会先规划出一条从司机当前位置(经度为116.4074°，纬度为39.9042°)到写字楼前接第二名乘客的路线，然后再从写字楼前往商场门口接第一名乘客的最优路线。这个过程中，需要权衡先接哪个乘客能够使总的行驶距离最短、花费的时间最少，同时还要考虑交通状况和道路的限制情况。

[0078] 三、判断乘客端是否满足预设优化条件。

[0079] 场景一：渠道和城市维度的判断

[0080] 1.渠道判断

[0081] 假设打车平台有多个打车渠道，如普通打车渠道、企业合作渠道、高端专车渠道等。服务器在判断时，首先查看乘客下单使用的是哪个渠道。如果乘客使用的是普通打车渠道，而预设的可使用幻影坐标功能的渠道是高端专车渠道，那么在渠道这一维度上，乘客端就不满足预设优化条件。

[0082] 相反，如果乘客使用的是高端专车渠道，这是预设的可使用幻影坐标功能的渠道之一，那么服务器会继续进行城市定位的判断。

[0083] 2.城市定位判断

[0084] 假设预设的可使用幻影坐标功能的城市有北京、上海、广州等大城市。如果乘客所在的城市是北京，那么在城市定位这一维度上满足条件。此时，结合之前渠道判断的结果(如果渠道也满足)，可以判定乘客端满足预设优化条件。

[0085] 但如果乘客所在的城市是一个三线小城市，不在预设的可使用幻影坐标功能的城市列表中，那么即使渠道满足条件，整体上乘客端也不满足预设优化条件。

[0086] 场景二：预估接驾里程的判断

[0087] 1.计算预估接驾里程

[0088] 服务器根据之前构建的导航路线，计算司机当前位置(经度为116.4074°，纬度为39.9042°)到乘客位置(经度为116.3975°，纬度为39.9100°)的距离。假设通过坐标计算得出的距离是1千米。

[0089] 由于预设的启用幻影坐标功能的预估接驾里程是1.5千米，在这种情况下，1千米小于1.5千米，所以乘客端不满足预设优化条件。

[0090] 2.动态距离变化

[0091] 假设在司机行驶过程中，由于交通拥堵或者道路临时管制，导航路线发生了变化。原本计算的1千米预估接驾里程可能变为1.8千米。此时，服务器会重新进行判断，因为1.8千米大于1.5千米，所以在这种情况下，乘客端满足预设优化条件。

[0092] 四、若满足，则生成幻影车辆坐标，并将配置了幻影车辆坐标的导航路线推送至乘客端。

[0093] 场景一：幻影坐标生成‑基于距离阈值

[0094] 1.获取真实车辆坐标与距离

[0095] 服务器从司机端获取到真实车辆坐标，例如司机当前的真实位置是经度为116.4074°，纬度为39.9042°。然后计算这个真实车辆坐标与乘客当前位置(经度为
116.3975°，纬度为39.9100°)的当前距离。假设计算得出的距离是2千米。

[0096] 预设的距离阈值是1.5千米，因为2千米大于1.5千米，所以满足生成幻影车辆坐标的条件。

[0097] 2.生成幻影坐标

[0098] 服务器根据司机的真实行驶方向(向北行驶)、当前速度(30千米/小时)以及导航路线等信息，按照预设的幻影坐标生成规则开始生成幻影坐标。例如，按照规则，幻影坐标会在真实坐标的基础上，以稍快一点的速度(假设为35千米/小时)沿着导航路线向北移动，生成一个新的幻影坐标，如经度为116.4080°，纬度为39.9045°。这个幻影坐标会随着时间按照一定的规则持续更新，以模拟车辆的行驶。

[0099] 场景二：幻影坐标生成‑基于预估接驾时间

[0100] 1.获取预估接驾时间

[0101] 服务器获取到当前订单的预估接驾时间为10分钟。根据规则，幻影车辆坐标最大移动时间＝预估接驾时间的1/3，最大2分钟。所以在这个订单中，幻影车辆坐标最大移动时间为10/3≈3.33分钟，但由于最大限制为2分钟，所以最大移动时间为2分钟。

[0102] 2.在时间范围内生成幻影坐标

[0103] 服务器在这2分钟的时间范围内，根据司机的真实行驶情况(如真实坐标的变化趋势、行驶方向等)和导航路线，生成幻影坐标。例如，在开始的30秒内，根据真实车辆的速度和方向，生成了一系列幻影坐标，使幻影车辆看起来在稳定地朝着乘客方向行驶。

[0104] 场景三：幻影坐标调整‑基于与真实坐标的距离

[0105] 1.计算位置距离

[0106] 服务器在生成幻影坐标的过程中，不断计算真实车辆坐标与当前幻影车辆坐标的位置距离。假设真实车辆坐标为经度为116.4074°，纬度为39.9042°，当前幻影车辆坐标为经度为116.4085°，纬度为39.9048°。通过坐标计算得出两者的距离为100米。

[0107] 2.调整幻影坐标显示

[0108] 预设的位置距离阈值为200米，因为100米小于200米，所以将当前幻影车辆坐标作为有效的幻影车辆坐标继续使用。如果在某个时刻，计算得出的距离超过了200米，那么服务器会停止当前幻影车辆坐标的显示，并切换至真实车辆坐标进行显示。

[0109] 场景四：幻影坐标调整‑基于与乘客上车点的距离

[0110] 1.确定真实和幻影坐标与上车点距离

[0111] 服务器根据乘客的位置(经度为116.3975°，纬度为39.9100°)确定真实的乘客上车点。假设当前幻影车辆坐标为经度为116.4000°，纬度为39.9090°，计算得出幻影车辆距离真实乘客上车点的距离为300米；真实车辆坐标为经度为116.4020°，纬度为39.9085°，计算得出真实车辆距离真实乘客上车点的距离为250米。

[0112] 2.切换坐标显示

[0113] 因为当前幻影车辆距离真实乘客上车点的距离(300米)大于真实车辆坐标离真实乘客上车点的距离(250米)，所以服务器会停止当前幻影车辆坐标的显示并切换至真实车辆坐标进行显示。

[0114] 五、若不满足，则生成真实车辆坐标，并将配置了真实车辆坐标的导航路线推送至乘客端。

[0115] 场景一：简单推送真实坐标

[0116] 1.获取真实坐标

[0117] 服务器直接从司机端获取真实车辆坐标，例如司机的位置是经度为116.4074°，纬度为39.9042°。

[0118] 2.推送导航路线

[0119] 服务器将包含这个真实车辆坐标的导航路线直接推送给乘客端。乘客端的应用会在地图上显示司机的真实位置，乘客可以看到司机沿着导航路线朝着自己的方向行驶。

[0120] 场景二：真实坐标更新推送

[0121] 1.坐标更新情况

[0122] 在司机行驶过程中，司机的位置会不断变化。例如，司机行驶了一段距离后，新的位置变为经度为116.4080°，纬度为39.9045°。

[0123] 2.持续推送更新

[0124] 服务器会持续获取司机的真实坐标更新，并将配置了新的真实车辆坐标的导航路线及时推送给乘客端。这样乘客就可以在自己的手机上看到司机实时的准确位置和行驶轨迹。

[0125] 在本发明实施例中，所述判断所述乘客端是否满足预设优化条件，可以通过以下示例执行实施。

[0126] 判断所述乘客端配置的打车渠道是否为预设渠道；

[0127] 若是，则判断所述乘客端所在的城市定位是否为预设城市定位，若是，则判定所述乘客端满足预设优化条件；

[0128] 若否，则判定所述乘客端不满足预设优化条件。

[0129] 在本发明实施例中，示例性的：

[0130] 一、判断所述乘客端配置的打车渠道是否为预设渠道。

[0131] 1.渠道信息的获取与比对

[0132] 当乘客在打车应用上下单后，服务器首先接收到来自乘客端的订单请求信息。这个请求信息中包含了乘客端配置的打车渠道相关信息。例如，乘客端可能通过应用界面选择了“普通快车”渠道进行打车。

[0133] 服务器中预先设定了可以使用幻影坐标功能的打车渠道列表，比如“高端专车”渠道和“商务出行”渠道等。服务器将乘客端的“普通快车”渠道与预设的渠道列表进行比对。由于“普通快车”不在预设渠道列表中，所以在这一步判定乘客端不满足预设优化条件。

[0134] 在另一种情况下，如果乘客选择的是“高端专车”渠道，这个渠道在服务器预设的可使用幻影坐标功能的渠道列表中，那么服务器就会进入下一步，即判断乘客端所在的城市定位是否为预设城市定位。

[0135] 2.渠道功能关联与判断依据

[0136] 不同的打车渠道在服务特性上有所差异。预设的可使用幻影坐标功能的渠道往往是那些对服务体验优化有更高要求或者有特殊服务定位的渠道。例如，“高端专车”渠道可能更注重为乘客提供优质、高效且心理体验较好的服务，幻影坐标功能可以在一定程度上提升乘客等待时的感受。而“普通快车”渠道可能更侧重于提供基本的、性价比高的出行服务，所以没有被纳入可使用幻影坐标功能的渠道范畴。

[0137] 服务器在进行渠道判断时，依据的是平台运营方预先设定的业务规则。这些规则是综合考虑了不同渠道的用户群体、服务定位、市场竞争等多方面因素后确定的。

[0138] 二、若是(乘客端配置的打车渠道为预设渠道)，则判断所述乘客端所在的城市定位是否为预设城市定位。

[0139] 1.城市定位信息的获取与确认

[0140] 假设乘客端配置的打车渠道是“高端专车”渠道(满足第一步的预设渠道条件)，服务器接下来获取乘客端的城市定位信息。这个信息是通过乘客端设备的定位功能获取并发送给服务器的。例如，乘客所在的城市定位为北京。

[0141] 服务器中有一个预设的可使用幻影坐标功能的城市定位列表，其中包括北京、上海、广州等大城市。服务器将乘客所在的北京与这个预设城市定位列表进行比对。因为北京在预设城市定位列表中，所以判定乘客端满足预设优化条件。

[0142] 然而，如果乘客的城市定位是一个较小的城市，比如某三线城市A。这个城市不在服务器预设的可使用幻影坐标功能的城市定位列表中。即使乘客选择的是“高端专车”渠道，由于城市定位不满足要求，服务器判定乘客端不满足预设优化条件。

[0143] 2.城市定位背后的考量因素

[0144] 预设的可使用幻影坐标功能的城市定位通常是那些交通流量大、出行需求复杂的大城市。在这些城市中，由于交通拥堵、道路复杂等情况较为常见，幻影坐标功能可以更好地优化乘客等待体验。例如，在北京这样的大城市，高峰时段交通拥堵严重，司机可能行驶缓慢。幻影坐标功能可以让乘客在等待过程中感受到司机在更快速地接近，减少等待的焦虑感。

[0145] 而对于一些三线城市或者交通相对简单的城市，交通状况相对稳定，车辆行驶速度相对较快且可预测性强，所以没有被纳入可使用幻影坐标功能的城市定位范畴。服务器根据这些不同城市的交通特性和业务需求来进行城市定位的判断，以确定是否对乘客端应用幻影坐标优化功能。

[0146] 在本发明实施例中，所述判断所述乘客端是否满足预设优化条件，可以通过以下示例执行实施。

[0147] 判断当前订单的预估接驾里程是否达到预设里程距离；

[0148] 若是，则判定所述乘客端满足预设优化条件；

[0149] 若否，则判定所述乘客端不满足预设优化条件。

[0150] 在本发明实施例中，示例性的：

[0151] 一、获取订单信息及计算预估接驾里程。

[0152] 1.订单信息的接收与解析

[0153] 当乘客在打车应用上成功下单后，服务器会接收到包含订单相关信息的数据包。这个数据包包含了乘客的起始位置(通过乘客端设备的定位功能获取)和目的地信息(由乘客在应用中输入)等。例如，乘客的起始位置为某商场的具体坐标(经度为116.3975°，纬度为39.9100°)，目的地是某写字楼的坐标(经度为116.4150°，纬度为39.9000°)。

[0154] 服务器会根据存储的地图数据以及实时的交通信息(可以从与交通部门的接口获取或者基于平台其他司机的行驶数据进行估算)来计算从起始位置到目的地的预估接驾里程。服务器使用专门的路径规划算法，例如A算法，来确定最佳的行驶路线。这个算法会考虑道路的类型(如主干道、次干道、小路)、交通限制(如单行道、禁止左转等)以及当前的交通流量情况。

[0155] 在计算过程中，服务器会沿着规划的路线累加各个路段的长度。假设从商场到写字楼之间，首先要经过一条1千米长的主干道，然后转弯进入一条500米的次干道，再行驶800米到达写字楼。通过这样的计算，得出预估接驾里程为1+0.5+0.8＝2.3千米。

[0156] 二、与预设里程距离进行比较。

[0157] 1.预设里程距离的设定依据

[0158] 服务器中预先设定了一个里程距离值，用于判断是否启用幻影坐标功能。这个预设里程距离是基于平台的运营经验和用户体验研究确定的。例如，设定为1.5千米。这个数值的确定考虑到在较短距离的接驾情况下，司机到达乘客位置的时间相对较短，使用幻影坐标可能不会给乘客体验带来显著的提升，甚至可能因为坐标的虚拟性造成不必要的混淆。而对于较长距离的接驾，幻影坐标可以在一定程度上改善乘客等待时的心理感受。

[0159] 2.比较结果与判定

[0160] 由于计算得出的预估接驾里程为2.3千米，而预设里程距离为1.5千米，2.3千米大于1.5千米。所以，服务器判定乘客端满足预设优化条件。

[0161] 反之，如果计算得出的预估接驾里程为1千米，1千米小于1.5千米。那么服务器判定乘客端不满足预设优化条件。

[0162] 三、特殊情况处理。

[0163] 1.交通状况变化导致的里程变化

[0164] 在司机前往接驾的过程中，可能会遇到交通状况的变化。例如，原本规划的路线上发生了交通事故，导致部分路段堵塞。服务器会根据实时交通信息重新规划路线。假设原来预估接驾里程为2.3千米的路线，由于需要绕行，新的路线里程变为3千米。

[0165] 服务器会在重新规划路线后重新进行与预设里程距离的比较。因为3千米仍然大于1.5千米，所以如果之前判定满足条件，现在依然满足；如果之前不满足条件，现在则可能满足了，服务器会根据新的比较结果调整对乘客端是否满足预设优化条件的判定。

[0166] 2.乘客位置变动导致的里程变化

[0167] 有时候，乘客在等待司机接驾的过程中可能会移动自己的位置。例如，乘客原本在商场门口等待，然后走到了商场附近的公交站。乘客端设备会将新的位置信息发送给服务器。

[0168] 服务器会根据新的乘客位置重新计算预估接驾里程。假设原来的预估接驾里程为2.3千米，由于乘客位置的移动，新的预估接驾里程变为2千米。然后服务器再次与预设里程距离(1.5千米)进行比较，因为2千米大于1.5千米，所以在这种情况下，依然判定乘客端满足预设优化条件。如果新的里程小于1.5千米，则判定为不满足条件。

[0169] 在本发明实施例中，所述生成幻影车辆坐标，可以通过以下示例执行实施。

[0170] 从所述当前接驾状态中实时获取所述真实车辆坐标；

[0171] 获取所述真实车辆坐标与所述乘客当前位置信息的当前距离；

[0172] 在所述当前距离超过预设距离阈值的情况下，则生成所述幻影车辆坐标。

[0173] 在本发明实施例中，示例性的：

[0174] 一、从当前接驾状态中实时获取真实车辆坐标。

[0175] 1.建立通信与数据获取

[0176] 服务器与司机端设备保持持续的通信连接。这种连接可以基于多种网络协议，如TCP/IP协议。司机端设备(例如安装了打车应用的智能手机)通过自身的定位系统(如GPS、北斗等)实时获取车辆的位置信息。

[0177] 当司机接受订单并开始接驾流程后，司机端设备会按照一定的频率(例如每5秒一次)将车辆的位置信息发送给服务器。这些位置信息包含了车辆的经度、纬度等坐标数据。例如，司机端发送的真实车辆坐标为经度116.4074°，纬度39.9042°。

[0178] 服务器接收到这些数据后，会对其进行解析和验证。验证过程包括检查数据的完整性和准确性，例如检查坐标数据是否在合理的地理范围内，是否符合数据格式要求等。

[0179] 2.数据存储与更新

[0180] 服务器会将接收到的真实车辆坐标存储在专门的数据结构中，例如在一个数据库表中，以订单ID为索引，关联司机的真实车辆坐标以及其他相关接驾状态信息。

[0181] 随着司机的行驶，服务器会不断接收新的真实车辆坐标并更新存储的数据。这样，服务器始终保持着司机最新的真实位置信息，为后续的操作提供准确的数据基础。

[0182] 二、获取真实车辆坐标与乘客当前位置信息的当前距离。

[0183] 1.坐标转换与距离计算原理

[0184] 服务器从存储中获取到真实车辆坐标(经度116.4074°，纬度39.9042°)和之前获取的乘客当前位置信息(假设为经度116.3975°，纬度39.9100°)。为了计算两者之间的距离，服务器需要将经纬度坐标转换为适合距离计算的空间坐标系统。

[0185] 通常会使用大地测量学中的距离计算公式，如哈弗辛公式(Haversine formula)。这个公式考虑了地球的曲率，能够较为准确地计算出两点(真实车辆坐标点和乘客位置坐标点)之间的球面距离。

[0186] 2.距离计算过程

[0187] 根据哈弗辛公式，服务器将真实车辆坐标和乘客当前位置坐标代入计算。首先计算两点之间的经度差和纬度差，然后进行一系列的三角函数运算。经过计算，得出真实车辆坐标与乘客当前位置信息的当前距离为1.5千米。

[0188] 三、在当前距离超过预设距离阈值的情况下，则生成幻影车辆坐标。

[0189] 1.预设距离阈值的确定依据

[0190] 服务器中预先设定了一个距离阈值，这个阈值是基于平台的运营策略和用户体验研究确定的。例如，预设距离阈值设定为1千米。这个数值的确定考虑到在较短距离内，司机能够较快地到达乘客位置，使用幻影车辆坐标可能不会带来明显的体验提升，反而可能增加系统的复杂性和数据处理量。而在较长距离时，幻影车辆坐标可以更好地改善乘客等待的心理感受。

[0191] 2.幻影车辆坐标生成的触发

[0192] 由于计算得出的当前距离为1.5千米，而预设距离阈值为1千米，1.5千米大于1千米。所以满足生成幻影车辆坐标的条件。

[0193] 服务器在确定满足条件后，开始生成幻影车辆坐标。生成幻影车辆坐标需要考虑多个因素，如司机的行驶方向、速度以及导航路线等。假设司机的行驶方向为向北，速度为30千米/小时，服务器根据这些信息以及导航路线，按照一定的算法生成幻影车辆坐标。

[0194] 例如，服务器会在真实车辆坐标的基础上，根据司机的行驶方向和速度，按照一个略高于实际速度(如35千米/小时)的虚拟速度，沿着导航路线向前推算一个新的坐标位置。假设经过计算，生成的幻影车辆坐标为经度116.4080°，纬度39.9045°。这个幻影车辆坐标会随着时间根据设定的规则不断更新，以模拟车辆朝着乘客方向行驶的过程。

[0195] 3.特殊情况与调整

[0196] 如果在生成幻影车辆坐标后，由于交通状况的变化(如道路临时管制)或者司机自身的操作(如临时停车)，导致真实车辆坐标与乘客位置的距离发生变化。例如，真实车辆距离乘客的距离由于道路管制而变为0.8千米，小于预设距离阈值1千米。

[0197] 服务器会根据新的距离情况进行调整。在这种情况下，服务器可能会停止幻影车辆坐标的更新，并切换回使用真实车辆坐标，以确保乘客端显示的位置信息的准确性和合理性。

[0198] 在本发明实施例中，所述生成幻影车辆坐标，可以通过以下示例执行实施。

[0199] 获取当前订单的预估接驾时间；

[0200] 根据所述当前订单的预估接驾计算得到幻影车辆坐标最大移动时间；

[0201] 在所述幻影车辆坐标最大移动时间确定的时间范围内，生成所述幻影车辆坐标。

[0202] 在本发明实施例中，示例性的：

[0203] 一、获取当前订单的预估接驾时间。

[0204] 1.基于多种因素的预估

[0205] 当乘客下单后，服务器开始对当前订单的预估接驾时间进行计算。服务器首先获取司机当前位置和乘客当前位置信息。例如，司机位于城市的A区，坐标为经度116.4074°，纬度39.9042°，乘客位于B区，坐标为经度116.3975°，纬度39.9100°。

[0206] 服务器会分析从司机位置到乘客位置的导航路线。这个分析过程涉及到考虑道路类型，如主干道的限速通常较高(假设为60千米/小时)，次干道限速可能为40千米/小时；还要考虑交通流量情况，服务器通过与交通部门的数据接口获取实时交通信息，或者基于平台上其他司机在相同或类似路段的行驶速度数据来判断。如果当前时段是交通高峰期，道路拥堵，平均车速可能会降低到20‑30千米/小时。

[0207] 除了道路和交通因素，服务器还会考虑可能存在的特殊情况，如道路施工、临时管制等。假设在导航路线中有一段道路正在进行小规模施工，这会导致车速降低。综合这些因素，服务器计算出从司机到乘客的预估接驾时间为15分钟。

[0208] 二、根据当前订单的预估接驾计算得到幻影车辆坐标最大移动时间。

[0209] 1.计算规则的应用

[0210] 服务器按照既定的规则来计算幻影车辆坐标最大移动时间。规则规定幻影车辆坐标最大移动时间＝预估接驾时间的1/3，最大2分钟。

[0211] 对于当前订单，预估接驾时间为15分钟，那么按照规则计算得到的幻影车辆坐标最大移动时间为15/3＝5分钟。但由于存在最大2分钟的限制，所以最终确定的幻影车辆坐标最大移动时间为2分钟。

[0212] 三、在幻影车辆坐标最大移动时间确定的时间范围内，生成幻影车辆坐标。

[0213] 1.初始状态下的幻影坐标生成

[0214] 在确定了幻影车辆坐标最大移动时间为2分钟后，服务器开始在这个时间范围内生成幻影车辆坐标。首先，服务器获取司机的真实车辆坐标(经度116.4074°，纬度39.9042°)以及司机的行驶方向(假设为向北)和速度(假设为30千米/小时)。

[0215] 服务器根据导航路线，以略高于司机实际速度(例如35千米/小时)的速度开始生成幻影车辆坐标。按照这个速度和行驶方向，在时间起点(即开始生成幻影坐标的时刻)，计算出一个初始的幻影车辆坐标。假设在导航路线上，经过计算得到的初始幻影车辆坐标为经度116.4078°，纬度39.9043°。

[0216] 2.幻影坐标的动态更新

[0217] 随着时间的推移，服务器在这2分钟的最大移动时间范围内持续更新幻影车辆坐标。例如，在经过30秒后，根据幻影车辆的虚拟速度和行驶方向，重新计算幻影车辆的新坐标。由于虚拟速度为35千米/小时，换算为每秒约9.72米(35000/3600)，在30秒内，车辆理论上移动了约291.6米(9.72×30)。按照导航路线和行驶方向，计算出30秒后的幻影车辆坐标，如经度116.4082°，纬度39.9044°。

[0218] 服务器会按照一定的时间间隔(例如每10秒)不断重复这个计算和更新过程，直到达到幻影车辆坐标最大移动时间2分钟。在这个过程中，幻影车辆坐标始终在导航路线上按照设定的速度和方向移动，模拟车辆朝着乘客方向行驶的状态，从而改善乘客等待时看到车辆位置的体验。

[0219] 3.特殊情况处理

[0220] 如果在幻影车辆坐标最大移动时间内，出现了交通状况的突然变化，例如原本畅通的道路突然发生交通事故导致拥堵。服务器会根据新的交通信息调整幻影车辆坐标的生成。假设事故导致车速大幅下降，服务器可能会相应地降低幻影车辆的虚拟速度，以保证幻影坐标的移动仍然符合实际可能的交通情况。

[0221] 另外，如果司机端的状态发生变化，如司机临时停车或者改变行驶方向，服务器也会对幻影车辆坐标进行调整。例如，司机因为避让行人而短暂停车，服务器会暂停幻影车辆坐标的移动，直到司机重新启动并继续行驶，然后再根据新的行驶状态重新计算和更新幻影车辆坐标。

[0222] 在本发明实施例中，所述生成幻影车辆坐标，可以通过以下示例执行实施。

[0223] 从所述当前接驾状态中实时获取所述真实车辆坐标；

[0224] 计算所述真实车辆坐标与当前幻影车辆坐标的位置距离；

[0225] 在所述位置距离低于预设位置距离阈值的情况下，将所述当前幻影车辆作为所述幻影车辆坐标；

[0226] 在所述位置距离高于预设位置距离阈值的情况下，停止所述当前幻影车辆坐标的显示并切换至所述真实车辆坐标进行显示。

[0227] 在本发明实施例中，示例性的：

[0228] 一、从当前接驾状态中实时获取真实车辆坐标。

[0229] 1.数据获取的持续进行

[0230] 服务器与司机端始终保持稳定的通信连接，这一连接基于可靠的网络技术，如4G/5G移动网络或者Wi‑Fi网络(如果车辆处于Wi‑Fi覆盖区域且司机端设备连接了Wi‑Fi)。司机端设备(例如司机的智能手机，其上运行着打车应用)通过内置的高精度定位系统(如GPS结合基站辅助定位等)持续获取车辆的真实位置信息。

[0231] 这个真实位置信息以一定的频率(例如每3‑5秒一次)发送给服务器。假设司机正在城市道路上行驶，司机端发送的真实车辆坐标信息为经度116.4074°，纬度39.9042°，同时还可能包含车辆的行驶状态信息，如速度(假设为30千米/小时)、行驶方向(假设为向北)等。服务器接收到这些信息后，会对其进行分类和存储，以便后续操作使用。

[0232] 二、计算真实车辆坐标与当前幻影车辆坐标的位置距离。

[0233] 1.坐标系统与距离计算

[0234] 服务器在获取到真实车辆坐标后，需要计算它与当前幻影车辆坐标的位置距离。服务器采用合适的坐标系统来表示地理位置，通常是基于地球经纬度的地理坐标系。为了准确计算两者之间的距离，会使用专门的地理距离计算算法，如哈弗辛公式(Haversine formula)。

[0235] 假设当前幻影车辆坐标为经度116.4076°，纬度39.9043°。服务器根据哈弗辛公式，首先计算两个坐标点之间的经度差(116.4076°‑116.4074°＝0.0002°)和纬度差(39.9043°‑39.9042°＝0.0001°)，然后代入公式进行一系列的三角函数运算，最终得出真实车辆坐标与当前幻影车辆坐标的位置距离为10米(这里仅为示例数值，实际计算结果根据精确的公式计算得出)。

[0236] 三、在位置距离低于预设位置距离阈值的情况下，将当前幻影车辆作为幻影车辆坐标。

[0237] 1.预设位置距离阈值的确定

[0238] 服务器中预先设定了一个位置距离阈值，这个阈值是基于多方面因素确定的。从用户体验角度考虑，设置一个合适的距离阈值可以保证幻影车辆坐标在合理范围内与真实车辆坐标波动，避免给乘客造成过大的视觉或心理差异。从系统稳定性和准确性角度看，这个阈值有助于平衡幻影坐标模拟和真实坐标反映的关系。假设这个预设位置距离阈值为50米。

[0239] 2.根据比较结果的操作

[0240] 由于计算得出的真实车辆坐标与当前幻影车辆坐标的位置距离为10米，10米低于预设位置距离阈值50米。所以，服务器判定当前幻影车辆坐标在合理范围内，可以将其作为幻影车辆坐标继续使用。这意味着在向乘客端推送车辆位置信息时，仍然使用这个幻影车辆坐标，让乘客看到幻影车辆按照预期的轨迹(基于幻影坐标)移动，给乘客一种车辆正在稳定地朝着自己行驶过来的感觉。

[0241] 四、在位置距离高于预设位置距离阈值的情况下，停止当前幻影车辆坐标的显示并切换至真实车辆坐标进行显示。

[0242] 1.超过阈值的情况处理

[0243] 假设在某些情况下，由于网络延迟或者幻影坐标生成算法的一些临时波动等原因，导致计算得出的真实车辆坐标与当前幻影车辆坐标的位置距离变为80米，而预设位置距离阈值为50米，80米高于50米。

[0244] 2.坐标切换操作及影响

[0245] 当出现这种情况时，服务器会停止当前幻影车辆坐标的显示。这是为了避免给乘客显示一个与真实车辆位置偏差过大的位置信息，防止造成乘客的误解。然后，服务器会切换至真实车辆坐标进行显示。这样，乘客端将看到司机车辆的真实位置，虽然可能与之前看到的幻影车辆坐标的移动轨迹有一定的跳跃感，但这种切换确保了位置信息的准确性，让乘客能够基于真实情况来判断司机的接驾进度。同时，服务器可能会记录下这次坐标切换的相关信息，如切换的时间、当时的真实车辆坐标和幻影车辆坐标等，以便后续进行数据分析和系统优化。

[0246] 在本发明实施例中，所述生成幻影车辆坐标，可以通过以下示例执行实施。

[0247] 根据所述乘客当前位置信息在所述导航路线生成真实乘客上车点；

[0248] 在当前幻影车辆距离所述真实乘客上车点的距离小于所述真实车辆坐标离所述真实乘客上车点的距离的情况下，将所述当前幻影车辆作为所述幻影车辆坐标；

[0249] 在当前幻影车辆距离所述真实乘客上车点的距离大于所述真实车辆坐标离所述真实乘客上车点的距离的情况下，停止所述当前幻影车辆坐标的显示并切换至所述真实车辆坐标进行显示。

[0250] 在本发明实施例中，示例性的：

[0251] 一、根据乘客当前位置信息在导航路线生成真实乘客上车点。

[0252] 1.确定上车点的依据

[0253] 当乘客在打车应用上下单时，服务器获取到乘客的当前位置信息。这个位置信息是通过乘客端设备(如手机)的定位功能获取的精确坐标。例如，乘客的当前位置坐标为经度116.3975°，纬度39.9100°。

[0254] 同时，服务器已经根据司机和乘客的位置构建了导航路线。这个导航路线包含了一系列的坐标点，表示从司机位置到乘客位置的最佳行驶路径。服务器会根据乘客的当前位置在这个导航路线上确定真实乘客上车点。通常，上车点会选择在靠近乘客位置且方便车辆停靠的地方，比如在道路的一侧且没有交通限制(如非禁停区域)的位置。

[0255] 假设在导航路线中，距离乘客当前位置坐标最近且符合停车条件的点就是真实乘客上车点，其坐标为经度116.3978°，纬度39.9102°。这个上车点可能是在商场门口附近的路边，有足够的空间供车辆停靠。

[0256] 二、在当前幻影车辆距离真实乘客上车点的距离小于真实车辆坐标离真实乘客上车点的距离的情况下，将当前幻影车辆作为幻影车辆坐标。

[0257] 1.计算距离并比较

[0258] 服务器在运行过程中，会同时跟踪真实车辆坐标和幻影车辆坐标。假设真实车辆坐标为经度116.4074°，纬度39.9042°，幻影车辆坐标为经度116.4060°，纬度39.9050°。

[0259] 服务器首先计算真实车辆坐标到真实乘客上车点(经度116.3978°，纬度39.9102°)的距离。使用专门的地理距离计算算法(如哈弗辛公式)，计算出真实车辆到上车点的距离为1.5千米。

[0260] 接着，计算幻影车辆坐标到真实乘客上车点的距离。同样使用该算法，得出幻影车辆到上车点的距离为1.2千米。

[0261] 由于1.2千米(幻影车辆到上车点的距离)小于1.5千米(真实车辆到上车点的距离)，所以服务器判定将当前幻影车辆坐标作为幻影车辆坐标。

[0262] 2.对乘客体验的影响

[0263] 在这种情况下，向乘客端推送幻影车辆坐标是更有利的。因为从乘客的角度来看，幻影车辆似乎更接近上车点，这会给乘客一种车辆更快到达的心理暗示，从而改善乘客等待的体验。例如，乘客在等待过程中看到车辆(幻影车辆坐标)在导航地图上更靠近自己的上车点，会减少等待的焦虑感，觉得司机能够更快地接到自己。

[0264] 三、在当前幻影车辆距离真实乘客上车点的距离大于真实车辆坐标离真实乘客上车点的距离的情况下，停止当前幻影车辆坐标的显示并切换至真实车辆坐标进行显示。

[0265] 1.距离比较与触发切换

[0266] 假设在另一种情况下，真实车辆坐标为经度116.4050°，纬度39.9045°，幻影车辆坐标为经度116.4030°，纬度39.9030°。

[0267] 服务器计算真实车辆坐标到真实乘客上车点(经度116.3978°，纬度39.9102°)的距离，得出为1.3千米。

[0268] 再计算幻影车辆坐标到真实乘客上车点的距离，结果为1.4千米。

[0269] 因为1.4千米(幻影车辆到上车点的距离)大于1.3千米(真实车辆到上车点的距离)，此时服务器会停止当前幻影车辆坐标的显示。

[0270] 2.切换坐标的必要性和意义

[0271] 停止幻影车辆坐标显示并切换至真实车辆坐标是为了确保乘客端显示的位置信息的准确性。如果继续使用幻影车辆坐标，会给乘客造成误导，让乘客以为车辆离自己更远或者行驶方向出现异常。而切换到真实车辆坐标后，乘客能够看到车辆的真实位置和接近自己的实际情况，这有助于乘客准确地判断司机的接驾进度，避免因为不准确的位置信息导致的不必要的等待或者误解。例如，乘客可能会根据真实车辆坐标调整自己的准备上车的时间或者在正确的位置等待司机到来。

[0272] 为了能够更加清楚的描述本发明实施例提供的方案，下面提供一种更加详细的实施方式。

[0273] 1、精准追踪司机接驾状态：系统首要任务是实时捕获并更新司机的接驾状态，确保信息的即时性与准确性。

[0274] 2、实时位置的同步：在接驾流程中，设计了灵活的位置同步机制。既可由渠道主动请求司机的最新位置信息，也可由系统主动推送，同时，通过精细化的坐标新鲜度管理，让渠道接收到的每一个坐标都是即时捕捉的。

[0275] 3、导航路线缓存：一旦司机接单，司机端规划的接驾导航路线及其坐标点与距离将被写入缓存系统。提升数据处理效率。

[0276] 4、智能启用幻影坐标策略：自司机上传首个坐标点起，系统会优先判断渠道&城市维度开关，以及订单条件，判断是否启用幻影坐标功能。若未启用，则直接采用真实坐标同步司机位置；若启用，则运用幻影坐标技术。

[0277] 渠道&城市维度：只有特定的渠道和城市才会启用幻影坐标功能。

[0278] 订单条件：只有订单的预估接驾里程大于1.5km才会启用幻影坐标。

[0279] 5、幻影坐标的精细调控：

[0280] 距离与速度考量：幻影坐标的生成严格遵循系统预设的速度与规则，且仅当接驾距离达到一定阈值时启用，短距离接驾则直接采用真实坐标。

[0281] 动态调整避免误解：幻影坐标的移动并非持续不变，系统会持续与预估的接驾时间进行比对，确保在乘客即将可见司机的关键时刻，幻影坐标能够适时停止移动，避免造成不必要的误解。

[0282] 其中幻影坐标的最大移动时间＝预估接驾时间的1/3，最大2min

[0283] 安全距离限制：当幻影坐标与真实坐标之间的距离超出安全范围时，系统将自动停止其移动，确保位置信息的合理性与安全性。

[0284] 安全范围：(预估接驾里程‑司机可就位距离)/10。

[0285] 路线精准度：生成的幻影坐标需严格遵循既定的导航路线，确保其移动的轨迹与司机实际应走的路径相吻合。

[0286] 6、幻影坐标与真实坐标：当幻影坐标距离乘客上车点远于真实坐标距离乘客上车点时，此时应切回使用真实坐标。

[0287] 请结合参阅图2，图2为本发明实施例提供的一种改善乘客等待体验的优化装置110，包括：

[0288] 获取模块1101，用于获取司机端的当前接驾状态和乘客端的当前等待状态，所述当前接驾状态包括司机当前位置信息，所述当前等待状态包括乘客当前位置信息；根据所述当前位置信息和所述乘客当前位置信息，构建导航路线；

[0289] 优化模块1102，用于判断所述乘客端是否满足预设优化条件；若满足，则生成幻影车辆坐标，并将配置了所述幻影车辆坐标的导航路线推送至所述乘客端，所述幻影车辆坐标为基于真实车辆坐标优化后得到的持续反馈的模拟车辆坐标；若不满足，则生成真实车辆坐标，并将配置了所述真实车辆坐标的导航路线推送至所述乘客端。

[0290] 需要说明的是，前述改善乘客等待体验的优化装置110的实现原理可以参考前述改善乘客等待体验的优化方法的实现原理，在此不再赘述。应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，改善乘客等待体验的优化装置110可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上改善乘客等待体验的优化装置110的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所描述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

[0291] 例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(application specific integrated circuit，ASIC)，或，一个或多个微处理器(digital signal processor，DSP)，或，一个或者多个现场可编程门阵列(fieldprogrammable gate array，FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(centralprocessing unit，CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system‑on‑a‑chip，SOC)的形式实现。

[0292] 本发明实施例提供一种计算机设备100，计算机设备100包括处理器及存储有计算机指令的非易失性存储器，计算机指令被处理器执行时，计算机设备100执行前述的改善乘客等待体验的优化装置110。如图3所示，图3为本发明实施例提供的计算机设备100的结构框图。计算机设备100包括改善乘客等待体验的优化装置110、存储器111、处理器112及通信单元113。

[0293] 为实现数据的传输或交互，存储器111、处理器112以及通信单元113各元件相互之间直接或间接地电性连接。例如，可通过一条或多条通讯总线或信号线实现这些元件相互之间电性连接。改善乘客等待体验的优化装置110包括至少一个可以软件或固件(firmware)的形式存储于存储器111中或固化在计算机设备100的操作系统(operating system，OS)中的软件功能模块。处理器112用于执行存储器111中存储的改善乘客等待体验的优化装置110，例如改善乘客等待体验的优化装置110所包括的软件功能模块及计算机程序等。

[0294] 本发明实施例提供一种可读存储介质，可读存储介质包括计算机程序，计算机程序运行时控制可读存储介质所在计算机设备执行前述的改善乘客等待体验的优化装置110。

[0295] 出于说明目的，前面的描述是参考具体实施例而进行的。但是，上述说明性论述并不打算穷举或将本公开局限于所公开的精确形式。根据上述教导，众多修改和变化都是可行的。选择并描述这些实施例是为了最佳地说明本公开的原理及其实际应用，从而使本领域技术人员最佳地利用本公开，并利用具有不同修改的各种实施例以适于预期的特定应用。