上车位置推荐方法、装置、设备及其存储介质与流程

本申请一般数据处理技术领域，尤其涉及上车位置推荐方法、装置、设备及其存储介质。

背景技术：

网约车是网络预约出租汽车的简称。用户使用网约车，即打车。当用户使用应用程序打车时，可以在打车应用程序的交互界面上，输入上车地址和下车地址后发起打车请求，直到网约车司机应答后。网约车司机通常按照订单中的上车地址去接应用户。此时，打车应用程序向网约车司机呈现的导航界面，显示的是网约车所在位置到用户的上车位置之间的导航数据。

现有的打车应用程序没有很好地处理用户的所在地的详细情况以及用户的时间需求，例如，用户在发起打车请求后，若估算等待时间过长，用户主动取消订单，或者被网约车司机被动取消订单等，导致用户对现有打车应用程序的体验非常不好。

技术实现要素：

鉴于现有技术中的上述缺陷或不足，期望提供一种上车位置推荐方法、装置、设备及存储介质，来自动为用户推荐最佳上车位置，以缩短用户的等待时间，从而提高用户的体验度。

第一方面，本申请实施例提供了一种上车位置推荐方法，该方法包括：

在生成订单后，生成用于重新规划乘车路线的触发事件；

响应于触发事件，推送新的上车位置。

第二方面，本申请实施例提供了一种上车位置推荐方法，该方法包括：

在生成订单后，响应于用于重新规划乘车路线的触发事件，控制在显示屏幕上呈现第一提示界面，第一提示界面用于提示第一用户和/或第二用户是否重新规划乘车路线，触发事件是基于第一用户或第二用户输入的触发指令或用户等待时间和/或交通实况信息生成的；

获取第一用户或第二用户在第一提示界面输入的确认指令；

响应于确认指令，接收新的上车位置。

第三方面，本申请实施例提供了一种上车位置推荐装置，该装置包括：

事件生成单元，用于在生成订单后，生成用于重新规划乘车路线的触发事件；

位置推送单元，用于响应于触发事件，推送新的上车位置。

第四方面，本申请实施例提供了一种上车位置推荐装置，该装置包括：

界面控制单元，用于在生成订单后，响应于用于重新规划乘车路线的触发事件，控制在显示屏幕上呈现第一提示界面，第一提示界面用于提示第一用户和/或第二用户是否重新规划乘车路线，触发事件是基于第一用户或第二用户输入的触发指令或用户等待时间和/或交通实况信息生成的；

第一指令获取单元，用于获取第一用户或第二用户在第一提示界面输入的确认指令；

位置接收单元，用于响应于确认指令，接收新的上车地位置。

第五方面，本申请实施例还提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，该处理器执行该程序时实现如本申请实施例描述的方法。

第六方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序用于：

该计算机程序被处理器执行时实现如本申请实施例描述的方法。

本申请实施例提供的推荐上车位置方法、装置、设备及其存储介质，可以通过在生成订单后，获取用于重新规划乘车路线的触发事件，响应于触发事件，推送新的乘车地址，其中触发事件可以是基于第一用户或第二用户主动触发的修改，或者基于用户等待时间和/或交通实况信息等。即在打车应用程序中考虑乘车用户或司机基于下单的信息发起的修改上车位置，或者基于用户时间需求、交通实况信息等，综合为乘车用户推荐最优的上车位置，以有效地节省乘车用户等待司机的所耗费的时间，并避开拥堵路段，提高了用户乘车体验。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出了现有技术中某打车场景的示意图；

图2示出了本申请实施例提供的上车位置推荐方法的流程示意图；

图3示出了本申请实施例提供的步骤110的流程示意图；

图4示出了本申请又一实施例提供的步骤110的流程示意图；

图5示出了本申请又一实施例提供的步骤110的流程示意图；

图6示出了本申请实施例提供的上车位置推荐方法的流程示意图；

图7示出了本申请又一实施例提供的上车位置推荐方法的流程示意图；

图8示出了本申请又一实施例提供的上车位置推荐方法的流程示意图；

图9示出了第一导航数据示意图；

图10示出了第二导航数据示意图

图11示出了根据本申请实施例提供的上车位置推荐装置900的示例性结构框图；

图12示出了根据本申请实施例提供的上车位置推荐装置1000的示例性结构框图。

图13示出了适于用来实现本申请实施例的终端设备或服务器的计算机系统1100的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关公开，而非对该公开的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与公开相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

现有技术中，用户(或称为乘客)通过终端设备中预先安装的打车应用程序，通过订单方式发起用车需求(即下单)后，网约车司机在接到订单后，按照网约车所在地址与订单中指定的起始地址获取导航数据。

如图1所示，图1示出了现有技术中某打车场景的示意图。其中，标识“起”为发起打车请求的第一用户，标识“终”为响应打车请求的网约车的第二用户。图1中描述了第一用户下单后，在打车应用程序中呈现的用车场景。第一用户与第二用户在图中匹配距离很近，但是，第二用户驾驶网约车必须按照车辆行驶交通规则，以致抵达第一用户所在位置需要耗费大量的时间，才能接应到第一用户。然后，再以第一用户所在的上车位置为起始点，开始新的导航规划。

显然，这种打车方式给用户带来很多不便，例如用户需要等待的时间过长，即使交规熟识的用户企图通过手动方式修改打车位置，但是，目前gps定位技术的不准确，导致修改后的上车位置不能被第二用户准确获知，需要第一用户与第二用户经过长时间的沟通，从而克服修改上车位置导致的问题。这些问题的存在，致使用户使用打车应用程序的体验不好。

因此，本申请实施例提出一种智能的推荐上车位置的方法来解决上述问题。

请参考图2，图2示出了本申请实施例提供的上车位置推荐方法的流程示意图。该方法可以在服务器侧实现。

如图2所示，该方法包括：

步骤110，在生成订单后，生成用于重新规划乘车路线的触发事件。其中，触发事件可以基于第一用户或第二用户输入的触发指令，或者用户等待时间，或者交通实况信息，或者用户等待时间和交通实况信息来生成。

本申请实施例中，在生成订单后，可以获取用于重新规划乘车路线的触发事件。例如，在生成订单后，根据用户的起始地址和网约车司机的距离，按照实际路况综合计算出用户等待时间，当用户等待时间大于等于某个阈值时，触发重新规划乘车路线。或者，在生成订单后，系统根据用户的起始地址和网约车司机之间的实际路况的交通实况信息，触发重新规划乘车线路。或者，根据乘车用户或者司机根据路况判断作出触发指令，该触发指令用于主动请求修改新的上车位置。

步骤120，响应于触发事件，推送新的上车位置。

本申请实施例中，响应于触发事件向用户自动地推荐新的上车位置，即上车地址。例如，当用户等待时间大于等于某个阈值时，触发重新规划乘车路线；或者，根据用户的起点位置和网约车司机的起点位置之间拥堵信息和/或交通规则信息，触发重新规划乘车路线。或者，根据用户的起点位置和网约车司机的起点位置估计用户等待时间之后，再根据用户的起点位置和网约车司机的起点位置之间拥堵信息和/或交通规则信息，综合考虑后触发重新规划乘车路线。重新规划乘车路线是指通过自动修改用户的上车地址来变更用户的行程路线。

触发重新规划乘车路线，可以通过向用户和/或网约车司机提供友好的交互界面来实现。

其中，步骤120可以包括：响应于第一用户和/或第二用户在第一提示界面输入的确认指令，推送新的上车地位置。

其中，第一提示界面用于提示第一用户和/或第二用户是否重新规划乘车路线。例如，响应于触发事件，在打车应用程序中呈现第一提示界面。该界面可以包括，同意变更上车位置的选项和不同意变更上车位置的选项。第一提示界面可以同时通过第一用户和第二用户的终端显示装置来呈现。当第一用户或第二用户通过人机交互装置，例如触摸屏、键盘等输入工具，输入确认指令(即同意变更的选项)后，系统将按照某个规则搜索确定的新的上车位置，推送至第一用户和第二用户的终端，并在打车应用程序的地图功能中呈现。

步骤120，还可以包括响应于第一用户在第二提示界面输入的确认指令，分别推送第一导航数据和第二导航数据，其中，第一导航数据包含用于指导第一用户按照推荐方式运动至新的上车位置的提示信息，第二导航数据包含用于指导第二用户从第二起始位置行驶至新的上车位置的提示信息。

其中，第二提示界面用于提示第一用户是否接受推荐方式运动至新的上车位置。其中，推荐方式，例如步行方式，或者自行车、电动车等方式，以便于第一用户抵达新的上车位置

第二提示界面可以包括，接受推荐方式运动至新的上车位置的选项和不接受推荐方式运动至新的上车位置的选项。第二提示界面可以仅在第一用户的终端侧显示，也可以同时在第一用户和第二用户的终端侧显示。当第一用户通过人机交互装置，例如触摸屏、键盘等输入工具，输入确认指令(即接受推荐方式的选项)后，系统将按照某个规则搜索确定的新的上车位置以不同的导航数据，分别推送至第一用户的终端设备和第二用户的终端设备，并各自的在打车应用程序的地图功能中呈现。例如，向第一用户推送的导航数据是按照推荐方式运动至新的上车位置的提示信息。向第二用户推送的导航数据则是从第二用户的网约车所在位置行驶至新的上车位置的提示信息。

优选地，步骤120还包括，在第一用户和/或第二用户在第一提示界面输入的确认指令之后，还要获取第一用户在第二提示界面输入的确认指令，响应于第一用户在第二提示界面输入的确认指令，分别推送第一导航数据和第二导航数据，来获取新的上车位置。

步骤120可以包括：响应于第一用户和/或第二用户输入的触发指令，接收第一用户或第二用户输入的新的上车地位置。

本申请实施例，通过响应于触发事件自动地为用户推荐新的上车位置，有效地节省了用户在下单后，等待网约车所需耗费的时间，提升了用户的乘车体验度。

请参考图3，图3示出了本申请实施例提供的步骤110的流程示意图。如图3所示，该方法包括：

步骤210，在生成订单后，根据第一用户的第一起点位置和第二用户的第二起点位置估算用户等待时间；

步骤220，确定用户等待时间是否大于等于时间阈值；

步骤230，若大于等于时间阈值，则生成触发事件。

步骤240，若小于时间阈值，则不生成触发事件。

本申请实施例中，用户等待时间可以根据第一用户的上车位置和第二用户的车辆所在位置、路况信息等按照导航信息估算得到。

例如，第一用户在下单后且有应答的第二用户接单，则系统主动提取订单中的上车位置(即第一起点位置)，和网约车所在的位置(即第二起点位置)。利用现有估算方法，考虑车辆行驶速度和两个起点位置的实际距离，估算出用户需要等待的时间。

其中，阈值条件可以预先设置为用户等待时间大于等于时间阈值，时间阈值例如可以是5分钟，或者2分钟，对于时间阈值的选择可以根据地域灵活设置。时间阈值不局限于上述内容。

当用户等待时间满足阈值条件时，生成触发事件。处理器响应于触发事件，根据用户所在的起始位置，发起重新搜索，以确定新的上车位置，例如可以通过打车应用程序中自带的地图功能，按照闭拥堵规则，或者时间最优规则，或者交通实况分析规则，为第一用户确定新的上车位置。第二用户从其所在位置驾车前往该新的上车位置的所需时间为新的用户等待时间，相比变更前的用户等待时间，用户等待时间明显缩短或者路径有明显优化。

请参考图4，图4示出了本申请又一实施例提供的步骤110的流程示意图。

步骤310，在生成订单后，获取第一用户的第一起点位置和第二用户的第二起点位置之间交通实况信息，该交通实况信息包括道路拥堵信息和/或交通规则信息。

步骤320，基于道路拥堵信息和/或交通规则信息生成触发事件。

本申请实施例中触发事件可以是基于交通实况信息生成的，交通实况信息例如道路拥堵信息、交通规则信息等。

例如，第一用户下单后且有应答的第二用户接单，则系统主动获取用户的上车位置(即第一起点位置)和网约车所在的位置(即第二起点位置)之间的交通实况信息。例如，是否存在表征道路拥堵的信息标识，或者拥堵级别标识，或者拥堵耗时估算等参数。还可以通过实际路形分析，确定第一用户的上车位置与网约车所在的位置之间存在按照交通规则行驶绕行路线等。

若存在上述情况，则生成触发事件。在生成触发事件之后，以第一用户的上车位置为中心，在地图功能中发起重新搜索，以确定新的上车位置，新的上车位置可以明显缩短第一用户的等待时间或者明显优化第一用户的乘车路线。例如，可以在打车应用程序自带的地图中，按照闭拥堵规则，或者时间最优规则，或者交通实况分析规则，为第一用户确定新的上车位置。

若不存在上述情况，则不生成触发事件，仍按订单规划的乘车路线等待。

请参考图5，图5示出了本申请又一实施例提供的步骤110的流程示意图。

步骤410，在生成订单后，根据第一用户的第一起点位置和第二用户的第二起点位置估算用户等待时间。

步骤420，确定用户等待时间是否大于等于时间阈值。

步骤430，若大于等于时间阈值，则获取第一起点位置和第二起点位置之间拥堵信息和/或交通规则信息。

步骤440，若小于时间阈值，则不生成触发事件。

步骤450，基于道路拥堵信息和/或交通规则信息生成触发事件。

本申请实施例，通过综合用户等待时间和交通实况信息来生成触发事件，可以权衡分析导致用户等待时间过长的客观因素的影响因子。还可以通过设置权重信息，在分析策略中，以用户等待时间和交通实况信息的权重系数均衡考量。

本申请实施例还考虑基于第一用户(乘车用户)或第二用户(司机)在下单完成后，基于订单显示的路况信息判断，发出触发指令，以请求修改订单中的上车位置为新的上车位置。新的上车位置可能是基于用户凭经验选择的位置。该位置可以有效地优化乘车路线。

请参考图6，图6示出了本申请又一实施例提供的上车位置推荐方法的流程示意图。该方法可以在终端侧实现。

该方法包括：

步骤510，在生成订单后，响应于用于重新规划乘车路线的触发事件，控制在显示屏幕上呈现第一提示界面。其中，第一提示界面用于提示第一用户和/或第二用户是否重新规划乘车路线。

步骤520，获取第一用户或第二用户在第一提示界面输入的确认指令；

步骤530，响应于确认指令，接收新的上车地位置。

步骤540，获取第一用户或第二用户在第一提示界面输入的否认指令(即拒绝变更上车位置的选项)；

步骤550，响应于否认指令，则拒绝变更上车位置。

请参考图7，图7示出了本申请又一实施例提供的上车位置推荐方法的流程示意图。该方法在终端侧实现。

步骤610，在生成订单后，响应于用于重新规划乘车路线的触发事件，控制在显示屏幕上呈现第二提示界面。

其中，第二提示界面用于提示第一用户是否接受推荐方式运动至新的上车位置。

步骤620，获取第一用户在第二提示界面输入的确认指令；

步骤630，响应于确认指令，接收第一导航数据或第二导航数据。

步骤640，获取第一用户在第二提示界面输入的否认指令(即拒绝按推荐方式运动至新的上车位置)。

步骤650，响应于否认指令，控制呈现重新派单提示界面。

其中，第一导航数据包含用于指导第一用户按照推荐方式运动至新的上车位置的提示信息。如图9所示，图9示出了第一导航数据示意图。第二导航数据包含用于指导第二用户从第二起始位置行驶至新的上车位置的提示信息。如图10所示，图10示出了第二导航数据示意图。

请参考图8，图8示出了本申请又一实施例提供的上车位置推荐方法的流程示意图。该方法在终端侧实现。

步骤710，在生成订单后，响应于用于重新规划乘车路线的触发事件，控制在显示屏幕上呈现第一提示界面。其中，第一提示界面用于提示第一用户和/或第二用户是否重新规划乘车路线。

步骤720，获取第一用户和/或第二用户在第一提示界面输入的确认指令；

步骤730，响应于确认指令，控制在显示屏幕上呈现第二提示界面。

步骤740，获取第一用户在第二提示界面输入的确认指令。

步骤750，响应于在第二提示界面输入的确认指令，接收第一导航数据或第二导航数据。

步骤760，获取第一用户和/或第二用户在第一提示界面输入的否认指令(即拒绝变更上车位置的选项)。

步骤770，响应于否认指令，则拒绝变更上车位置。

步骤780，获取第一用户在第二提示界面输入的否认指令(即拒绝按推荐方式运动至新的上车位置的选项)。

步骤790，响应于在第二提示界面输入的否认指令，控制在显示屏幕上呈现重新派单提示界面。

本申请实施例，通过向用户提供友好的交互界面，提升用户使用打车应用程度的交互满意度。

为了进一步说明本申请的实施例，以用户a为打车用户，用户b为网约车司机，构建上车位置推荐的场景。在用户a下单后，用户b响应接单，则系统获取用户a的订单中的上车位置(即第一起点位置)和用户b接单时所处的起点位置(即第二起点位置)。用户a的上车位置为订单中指示用户b承接用户a的上车的地点。

服务器端的处理器获取到两个起点位置之间的路况，按照用户等待时间和交通实况信息，生成触发事件。用于触发系统启动搜索程序，以用户a的起点位置为搜索条件，以路径优化为目的，筛选用户a的第一起点位置附近的可以规避拥堵、缩短用户a等待时间的新的上车位置，然后向用户a推荐新的上车位置。

用户a通过终端上预先安装的打车应用程序，其控制功能响应于触发事件，控制呈现第一提示界面，询问用户a和b是否愿意变更上车位置，如果用户a或b通过人机交互装置表示愿意变更，则服务器响应于愿意的指令，启动搜索程序。或者，在服务器在生成触发事件时，启动搜索程序，获取到新的上车位置，得到终端的指令信息。

进一步地，如果用户a或用户b选择愿意变更，则用户a终端安装的打车应用程序被控制显示第二提示界面，向用户a询问是否愿意按照推荐方式运动至新的上车位置。推荐方式，例如是步行至新的上车位置。选择的新的上车位置，通常是与用户a较近，且能够很好地节省用户a的用车时间的地理位置。因此，考虑步行范围即可。

如果用户a选择同意按照推荐方式运动至新的上车位置，则推送第一导航数据至用户a的终端，提示用户a如何步行至新的上车位置，同时推送第二导航数据用户b的终端，提示用户b行驶至新的上车位置承接用户a。

本申请实施例，通过系统自动为用户筛选符合条件的新的上车位置，来节省用户等待网约车的时间，从而提升了用户的体验度，也有效地提高了用车效率。

应当注意，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

进一步参考图11，图11示出了根据本申请实施例提供的上车位置推荐装置900的示例性结构框图。

该装置900包括：

事件生成单元910，用于在生成订单后，生成用于重新规划乘车路线的触发事件。其中，触发事件可以基于第一用户或第二用户输入的触发指令，或者用户等待时间，或者交通实况信息，或者用户等待时间和交通实况信息来生成。

位置推送单元920，用于响应于触发事件，推送新的上车位置。

其中，事件生成单元910还用于根据第一用户的第一起点位置和第二用户的第二起点位置估算用户等待时间；并确定用户等待时间是否大于等于时间阈值；若大于等于时间阈值，则生成触发事件。

或者，事件生成单元910还用于获取第一用户的第一起点位置和第二用户的第二起点位置之间的交通实况信息，该交通实况信息包括道路拥堵信息和/或交通规则信息；基于道路拥堵信息和/或交通规则信息生成触发事件。

或者，事件生成单元910还用于根据第一用户的第一起点位置和第二用户的第二起点位置估算用户等待时间；确定用户等待时间是否大于等于时间阈值；若大于等于，则获取第一起点位置和第二起点位置之间交通实况信息，该交通实况信息包括道路拥堵信息和/或交通规则信息；基于道路拥堵信息和/或交通规则信息生成触发事件。

或者，事件生成单元910还用于响应于第一用户或第二用户输入的触发指令，生成触发事件。触发指令用于主动请求修改新的上车位置。

其中，位置推送单元920还用于响应于第一用户或第二用户在第一提示界面输入的确认指令，推送新的上车地位置。

第一提示界面用于提示第一用户和/或第二用户是否重新规划乘车路线。

进一步地，位置推送单元920还用于响应于第一用户在第二提示界面输入的确认指令，分别推送第一导航数据和第二导航数据。其中，第一导航数据包含用于指导第一用户按照推荐方式运动至新的上车位置的提示信息。第二导航数据包含用于指导第二用户从第二起始位置行驶至新的上车位置的提示信息。其中，第二提示界面用于提示第一用户是否接受推荐方式运动至新的上车位置。

本申请实施例中，响应于触发事件自动地为用户推荐新的上车位置，有效地节省了用户在完成下单后，等待网约车所需耗费的时间，提升了用户对打车应用程序的体验度。

进一步参考图12，图12示出了根据本申请实施例提供的上车位置推荐装置1000的示例性结构框图。如图12所示，该装置包括：

界面控制单元1010，用于在生成订单后，响应于用于重新规划乘车路线的触发事件，控制在显示屏幕上呈现第一提示界面。其中，第一提示界面用于提示第一用户和/或第二用户是否重新规划乘车路线。

第一指令获取单元1020，用于获取第一用户或第二用户在第一提示界面输入的确认指令。

位置接收单元1030，用于响应于确认指令，接收新的上车地位置。

界面控制单元1010，还用于响应于触发事件或者确认指令，控制在显示屏幕上呈现第二提示界面。其中，第二提示界面用于提示第一用户是否接受以推荐方式运动至新的上车位置。

第二指令获取单元1040，用于获取第一用户在第二提示界面输入的确认指令，

数据接收单元1050，用于响应于在第二提示界面输入的确认指令，接收第一导航数据或第二导航数据。其中，第一导航数据包含用于指导第一用户按照推荐方式运动至新的上车位置的提示信息。第二导航数据包含用于指导第二用户从第二起始位置行驶至新的上车位置的提示信息。

应当理解，装置900-1000中记载的诸单元或模块与参考图2-8描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于装置900-1000及其中包含的单元，在此不再赘述。装置900-1000可以预先实现在电子设备的浏览器或其他安全应用中，也可以通过下载等方式而加载到电子设备的浏览器或其安全应用中。装置900-1000中的相应单元可以与电子设备中的单元相互配合以实现本申请实施例的方案。

在上文详细描述中提及的若干模块或者单元，这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

下面参考图13，图13示出了适于用来实现本申请实施例的终端设备或服务器的计算机系统1100的结构示意图。

如图13所示，计算机系统1100包括中央处理单元(cpu)701，其可以根据存储在只读存储器(rom)702中的程序或者从存储部分708加载到随机访问存储器(ram)703中的程序而执行各种适当的动作和处理。在ram703中，还存储有系统1100操作所需的各种程序和数据。cpu701、rom702以及ram703通过总线704彼此相连。输入/输出(i/o)接口705也连接至总线704。

以下部件连接至i/o接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至i/o接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本公开的实施例，上文参考流程图图2-8描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在机器可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(cpu)1101执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，例如，可以描述为：一种处理器包括获取单元和推送单元。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定，例如，获取单元还可以被描述为“用于在生成订单后，获取用于重新规划乘车路线的触发事件的单元”。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中的。上述计算机可读存储介质存储有一个或者多个程序，当上述前述程序被一个或者一个以上的处理器用来执行描述于本申请的推荐上车位置方法。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。