一种会合地点的确定方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种会合地点的确定方法及装置。

背景技术：

目前，地理信息系统(Geographic Information System，GIS)的电子地图(以下简称为：GIS地图)得到了广泛的应用。对于用户而言，可通过GIS地图进行导航、定位，从而便于用户的日常出行。

现有技术中，作为使用GIS地图进行导航的一种应用场景，对于处在不同位置的第一用户与第二用户而言，第二用户可根据连接第一用户、第二用户以及目的地这三个地点的导航路径进行导航，行至会合地点与第一用户会合，之后共同前往目的地。

然而，现有的导航路径中，第二用户与第一用户的会合地点就是第一用户所在的位置，实际场景下，可能由于第一用户所在位置对应的道路行驶方向的影响，使得第二用户行驶至第一用户所在的位置时，需要进行绕行以调转行驶方向，显然，这将会导致行驶至目的地的路程较长且增加了耗时，而且较为不便。

技术实现要素：

本申请实施例提供一种会合地点的确定方法，用以解决现有技术中用户之间的会合地点导致行驶过程不便的问题。

本申请实施例提供一种会合地点的确定装置，用以解决现有技术中用户之间的会合地点导致行驶过程不便的问题。

本申请实施例采用下述技术方案：

本申请实施例提供的一种会合地点的确定方法，包括：

根据第一用户和第二用户的位置，以及目标位置，生成第一路径；

确定所述第一用户的位置对应的候选位置；

根据所述候选位置、目标位置以及所述第二用户的位置，生成第二路径；

当确定所述第二路径短于所述第一路径时，将所述候选位置确定为所述第一用户和第二用户前往所述目标位置的会合地点。

本申请实施例另提供的一种会合地点的确定方法，包括：

第一用户向服务器发出用于确定与第二用户之间会合地点的会合请求；其中，所述会合请求中携带有所述第一用户的位置；

接收服务器反馈的会合地点，并展示，其中，所述会和地点，由所述服务器根据第一用户和第二用户的位置，以及目标位置，生成第一路径，确定所述第一用户的位置对应的候选位置，根据所述候选位置、目标位置以及所述第二用户的位置，生成第二路径，当确定所述第二路径短于所述第一路径时，并根据所述候选位置所确定。

本申请实施例还提供的一种会合地点的确定方法，包括：

根据打车用户和驾车用户的位置，以及目的地，生成第一导航路径；

确定所述打车用户的位置对应的候选位置；

根据所述候选位置、目的地以及所述驾车用户的位置，生成第二导航路径；

当确定所述第二导航路径短于所述第一导航路径时，将所述候选位置确定为所述第一用户前往所述目的地的上车点。

本申请实施例提供的一种会合地点的确定装置，包括：

第一路径模块，根据第一用户和第二用户的位置，以及目标位置，生成第一路径；

候选位置模块，确定所述第一用户的位置对应的候选位置；

第二路径模块，根据所述候选位置、目标位置以及所述第二用户的位置，生成第二路径；

确定模块，当确定所述第二路径短于所述第一路径时，将所述候选位置确定为所述第一用户和第二用户前往所述目标位置的会合地点。

本申请实施例另提供的一种会合地点的确定装置，包括：

发送模块，第一用户向服务器发出用于确定与第二用户之间会合地点的会合请求；其中，所述会合请求中携带有所述第一用户的位置；

接收模块，接收服务器反馈的会合地点，并展示，其中，所述会和地点，由所述服务器根据第一用户和第二用户的位置，以及目标位置，生成第一路径，确定所述第一用户的位置对应的候选位置，根据所述候选位置、目标位置以及所述第二用户的位置，生成第二路径，当确定所述第二路径短于所述第一路径时，并根据所述候选位置所确定。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

当位于不同位置的第一用户和第二用户要进行会合，并共同前往相同目的地的场景下，服务器会根据第一用户、第二用户以及目的地的位置，生成第一路径，此时，第一用户与第二用户的会合地点就是第一用户所在的位置，有可能会造成第二用户行驶过程中发生绕行，所以，服务器将进一步确定该第一用户可以移动至的位置，即候选位置，并基于候选位置生成候选路径，即第二路径，再判断第一路径和第二路径的路程长短，在确定第二路径的路程较短后，那么，服务器会进一步将该第二路径中的候选位置确定为会合地点，在后续过程，服务器可将该会合地点发送给第一用户和/或第二用户，使得各用户前往所述会合地点。

相较于现有技术而言，本申请所提供的会合地点的确定方法，可以为双方用户确定合适的会合地点，能够减少路径中第二用户的行驶距离，进而避免第二用户进行绕行、调转方向等操作，并且，服务器还会将合适的会合地点发送给用户，从而可以最大程度减少双方用户为了确定合适的会合地点而进行的多次通话，提升便捷性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1a为本申请实施例提供的会合地点的确定架构示意图；

图1b为本申请实施例提供的会合地点的确定过程示意图；

图1c～1d为本申请实施例提供的会合地点的确定对路径影响的示意图；

图2a～2c为本申请实施例提供的应用实例的示意图；

图3为本申请实施例提供的在第一用户侧的会合地点的确定过程的示意图；

图4为本申请实施例提供的应用于在线打车场景下的会合地点的确定的示意图；

图5为本申请实施例提供的基于服务器侧的会合地点的确定装置结构示意图；

图6为本申请实施例提供的基于第一用户侧的会合地点的确定装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

如前所述，在第一用户与第二用户会合共同前往目的地的场景下，会合地点往往就是第一用户当前所在的位置，那么，第二用户的行驶路径就可能受到第一用户所在位置对应的道路行驶方向的影响，而导致第二用户为了与第一用户会合需要绕行调转行驶方向，这无疑会增加第二用户的行驶距离及行驶时间，并且，在实际场景下，还可能会出现用户双方进行多次通话以调整合适会合地点的现象，较为不便。

基于此，在本申请实施例中，提供一种会合地点的确定方法，以实现优化用户之间的会合地点，从而能够使得第一用户、第二用户以及目的地三者之间路程在一定程度上减少，并且，能够减少用户双方为了确定合适的会合地点而进行的多次通话。

本申请中会合地点的确定方法所基于的架构可如图1a所示。在图1a中，服务器收集第一用户及第二用户的位置信息(其中也包括目的地的位置信息)并根据位置信息生成相应的导航路径和/或会合位置，发送至第一用户和第二用户各自使用的终端上进行展示。换言之，服务器可以作为实施会合地点的确定方法的执行主体。

当然，作为一种可能的方式，还可由用户所使用的终端完成导航路径的计算及生成，在此方式下，终端可以从服务器获得相应的位置信息，计算生成了导航路径后，再通过服务器发送至对方用户的终端。

需要说明的是，图1a中的服务器，可以是具有地图导航功能的服务器。相应地，在用户所使用的终端上，可以由终端自身操作系统中的地图导航功能实现地图、导航路径和/或位置信息的展示，也可以是运行在终端内的应用(Application，APP)实现地图、导航路径和/或位置信息的展示。这里并不构成对本申请的限定。

基于如图1a所示的架构(执行主体为服务器)，本申请实施例中的会合地点的确定方法如图1b所示，具体包括以下步骤：

S101：根据第一用户和第二用户的位置，以及目标位置，生成第一路径。

在本申请实施例中，服务器获取用户位置的过程，可以通过诸如全球卫星定位(GPS)、无线电通讯网络定位等技术实现，这里并不作过多论述。

所述的目标位置，是第一用户或第二用户所要抵达的目的地的位置。在不同的场景下，该目标位置既可以由第一用户设定，也可以由第二用户设定，例如：对于在线打车业务的场景而言，第一用户作为乘客，设置其所要到达的目的地(即，目标位置)。又例如：对于驾车用户(第二用户)主动接送用户(第一用户)至指定位置的场景下，该驾车用户可设置目的地。这里场景性的示例并不构成对本申请的限定。

在本步骤中，服务器根据获取到的位置(包括：用户双方的位置及目标位置)，生成第一导航路径。在实际应用场景下，生成第一导航路径可以使用现有的路径生成算法，这里并不构成对本申请的限定。

例如：如图1c所示，服务器基于获取到的第一用户user1、第二用户user2以及目标地点A的位置，生成第一导航路径L1。

S102：确定所述第一用户的位置对应的候选位置。

需要说明的是，实际场景下，第一用户通常保持自身的位置不变，那么，第二用户与第一用户会合的过程中，就可能由于道路自身行驶方向的影响，使得第二用户需要绕行，从而增加了行驶的路程。而如果第一用户改变自身的位置，就可能使得第二用户无需绕行。

所以，在本申请实施例中，将确定第一用户在一定距离内可变更的位置，也即，候选位置。当然，在实际应用场景下，候选位置可以为多个，这里并不限定候选位置的数量。

这里需要说明的是，本申请实施例中所述的候选位置，应是便于第一用户停留的位置(如：道路两侧)，也就是说，在确定候选位置时，除了基于距离确定候选位置的方式之外，还可结合使用相应的规则(如：交通规则等)，这里并不构成对本申请的限定。

S103：根据所述候选位置、目标位置以及所述第二用户的位置，生成第二路径。

基于确定出的各候选位置，可以生成相应的各条路径(即，第二路径)。当然，如果存在多个候选位置，那么，将生成对应数量的第二路径。

延续上例：假设如图1d所示，根据user1所在的位置以及相应的距离阈值，确定出与该user1相关的候选位置为图中虚线圆点处。那么，基于该候选位置，可生成第二路径L2。

生成的这些第二路径，实质上可看作是各条备选路径，为了确定这些备选的路径是否可以使用，就要与已经生成的第一路径进行比对。

S104：当确定所述第二路径短于所述第一路径时，将所述候选位置确定为所述第一用户和第二用户前往所述目标位置的会合地点。

正是由于第一路径可能受到道路行驶方向的影响，造成第一路径对应的路程较长，故在本申请实施例中将比对第一路径和第二路径各自的路程，并取路程较短的路径。

在实际应用中，经过上述步骤确定了会合地点后，服务器可将所述汇合地点发送给所述第一用户和/或第二用户，以便于所述第一用户和/或第二用户前往所述汇合地点。

需要说明的是，如果第二路径的路程小于第一路径的路程，则可以认为，生成的该第二路径所基于的候选位置，能够起到减少路程的作用，从而，可将该候选位置确定为合适的会合地点，并将该会合地点发送给第一用户和/或第二用户，还可以将该第二路径发送给第二用户，使得第二用户根据该第二路径进行导航。

而如果第二路径的路程并不小于第一路径的路程，那么便可以认为，生成的该第二路径所基于的候选位置，并未能起到减少路程的作用，故在此情况下，仍采用第一路径，也就无需向第一用户和/或第二用户发送候选位置(即，第一用户无需移动)，相应地，将生成的第一路径发送给第二用户，使得该第二用户使用第一路径进行导航。

仍沿用前述示例：从图1c和1d中可见，对于第一路径L1和第二路径L2而言，第一路径L1中明显出现了绕行的路程，所以，第二路径L2的短于第一路径L1。故服务器会将第二路径L2中的候选位置作为会合地点，发送给user1，使得user1移动至该候选位置，并将第二路径L2发送给user2，使得该user2以第二路径L2进行导航，行驶至会合地点与user1会合。

通过上述步骤，当位于不同位置的第一用户和第二用户要进行会合，并共同前往相同目的地的场景下，服务器会根据第一用户、第二用户以及目的地的位置，生成第一路径，此时，第一用户与第二用户的会合地点就是第一用户所在的位置，有可能会造成第二用户行驶过程中发生绕行，所以，服务器将进一步确定该第一用户可以移动至的位置，即候选位置，并基于候选位置生成候选路径，再判断第一路径和候选路径的路程长短，在确定候选路径的路程较短后，那么，服务器会进一步将该候选路径中的候选位置确定为合适的会合地点，在后续过程，服务器可将该会合地点发送给第一用户和/或第二用户，使得各用户前往所述会合地点。

相较于现有技术而言，本申请所提供的会合地点的确定方法，可以为双方用户确定合适的会合地点，能够减少路径中第二用户的行驶距离，并且，服务器还会将合适的会合地点发送给用户，从而可以最大程度减少双方用户为了确定合适的会合地点而进行的多次通话，提升便捷性。

在本申请实施例中，对于第一用户和第二用户而言，确定合适的候选位置作为会合地点，将对路径的长短产生较为明显的影响。第一用户移动至合适的候选位置，能够有效减少进行导航时所使用的路径的长度。通常，在一些场景下，候选位置与第一用户所在的位置之间的距离并不宜过长，例如：在线打车的场景下，第一用户作为乘客，其可移动的距离通常较短，过于长的距离将会对第一用户使用在线打车业务受到影响。所以，在确定所述第一用户的位置对应的候选位置的过程，具体可为：根据所述第一用户的位置以及预设的距离阈值，确定所述第一用户的位置对应的候选位置。

其中，所述候选位置与所述第一用户的位置之间的距离，不超过所述预设的距离阈值。

这里所述的距离阈值，可以认为是使第一用户的位置发生变更的最大距离。当然，不同场景下，距离阈值可能不同，例如：在第一用户为非驾车用户的场景下，距离阈值通常设置较短，可为50～100M等；又如：在第一用户为驾车用户的场景下，距离阈值可以设置较长，如：400M～1KM等；具体可根据实际应用的需要进行设定，这里并不构成对本申请的限定。

同时，考虑到实际应用中，路径中所出现的绕行路程，往往受到第一用户所处的路段的影响，而在第一用户当前位置周围的路段中的某些位置，如：路口，可能能够避免路径中的绕行路程。

因此，在候选位置为路口的情况下，确定所述第一用户的位置对应的候选位置的过程，具体可为：根据所述第一用户的位置以及预设的距离阈值，确定与所述第一用户相关的路段，在确定出的所述路段中，确定与所述第一用户对应的候选位置。

这里需要说明的是，GIS地图中所显示的道路，实质上位于该GIS地图中包含的道路图层上，服务器可基于GIS地图中的道路图层确定相应的路段，这里并不构成对本申请的限定。而所述的路段，可认为是交通网络中相邻两个网络节点之间的交通路线。其中，交通网络包括但不限于：公路网络、铁路网络、河道网络等。

进一步地，确定与所述第一用户相关的路段，具体为：以所述第一用户的位置为起始位置，根据所述预设的距离阈值，统计与所述起始位置之间的距离不超过所述距离阈值的各路段，将统计得到的各路段确定为与所述第一用户相关的路段。

在本申请实施例中，确定与第一用户相关的路段时，可以采用以第一用户的位置作为圆心，并以距离阈值划定范围的方式，落入该范围的路段均可确定为与第一用户相关的路段。

例如：如图2a所示，示出了第一用户user1的位置，该位置所在的路段为路段a，在此假设根据预设的距离阈值，以user1所在位置为起始位置，划定范围(如2a中的圆形区域)，可确定出图2a中的路段b、c、d均为与user1相关的路段。

在确定出与第一用户相关的路段后，便可在这些路段中，进一步确定出候选位置。具体而言，在确定出的所述路段中，确定与所述第一用户相关的候选位置的过程，可以为：在与所述第一用户相关的路段中，确定各路段所对应的路口位置，在确定出的所述路口位置中，选择与所述第一用户所在位置的距离不超过预设的距离阈值的各路口位置，并确定为与第一用户相关的候选位置。

其中，所述的路口位置，可认为是任一路段与其他路段相连接的位置。在实际应用场景下，行驶过程中的转向操作通常发生在路口位置，通过转向操作，可以使得第二用户从某一路段行驶至另一路段，那么，如果选择了合适的路口位置，便可以避免多余的绕行路程。

具体地，现以一应用实例进行说明：

基于图2a所示的道路，user1、user2以及目的地的具体位置如图2b所示，并且，基于图2b中示出的各位置，服务器生成了路径L3，显然，user2为了与user1相遇，需要行驶较多的绕行路程。基于上述内容，作为与user1相关的路段，路段d中的路口位置D点，是其中一个候选位置，若以D点生成的路径L4(如图2c所示)，能够有效减少绕行路程。

从而，在该示例中，服务器将会将D点的位置发送给user1，使得user1移动至D点，后续将使用根据D点生成的路径L4作为实际的路径，并会将该路径发送给user2，使得user2根据该路径进行导航。

当然，作为本申请实施例中的一种可选方式，服务器将候选位置发送第一用户后，需要该第一用户进行确认。具体可以采用提示窗口或通知消息等方式通知第一用户，第一用户通过操作提示窗口中的控件或回复确认消息等方式，进行确认。只有在该第一用户进行确认后，再将基于该候选位置生成的第二路径发送给第二用户。

以上内容是基于候选位置为路口时的情况，在实际应用中，候选位置可根据不同的场景发生相应的变化，如：候选位置还可以是公交车站、餐厅等等，这里并不构成对本申请的限定。

当然，在实际应用中，第一用户接收到了会合地点后，还可以进行确认，若第一用户确认，则表示该第一用户将会移动至该会合地点处，所以，所述方法还包括：第一用户向所述服务器发送对所述会合地点的确认指令。

只有在第一用户进行确认之后，服务器才会将第二路径发送给第二用户，相应地，第二用户才会根据第二路径进行导航，否则，第二用户将根据第一路径进行导航。

所以，在向用户发送第二路径之前，上述方法还包括：接收所述第一用户针对所述会合地点的确认指令。

作为本申请实施例中的一种方式，可以在第一用户终端的地图界面中显示会合地点，并询问第一用户是否愿意前往该会合地点，这里并不构成对本申请的限定。

以上内容是基于服务器侧的方法，对于第一用户而言，本申请实施例中还提供一种会合地点的确定方法，如图3所示。该方法包括以下步骤：

S301：第一用户向服务器发出用于确定会合地点的会合请求。

其中，所述的第一用户，可以理解为包含用户所使用的终端。包括但不限于：智能手机、平板电脑、智能手表、计算机等。

所述的会合请求，可认为是建立第一用户和第二用户之间的导航关联的请求，在不同的场景中，如：在线打车场景，会合请求可以是打车请求；又如：在用户好友之间通过地图导航进行会合以共同前往活动地点的场景下，会合请求可以是用户与好友之间的位置共享请求。

在实际场景中，第一用户所发出的会合请求，通常是发送至服务器，再由服务器基于该会合请求，建立第一用户与第二用户之间的导航关联。

S302：接收服务器反馈的会合地点。

其中，所述会和地点，由所述服务器根据第一用户和第二用户的位置，以及目标位置，生成第一路径，确定所述第一用户的位置对应的候选位置，根据所述候选位置、目标位置以及所述第二用户的位置，生成第二路径，当确定所述第二路径短于所述第一路径时，并根据所述候选位置所确定。

当然，在实际应用中，第一用户接收到了会合地点后，还可以进行确认，若第一用户确认，则表示该第一用户将会移动至该会合地点处，所以，所述方法还包括：第一用户向所述服务器发送对所述会合地点的确认指令。

只有在第一用户进行确认之后，服务器才会将第二路径发送给第二用户，相应地，第二用户才会根据第二路径进行导航，否则，第二用户将根据第一路径进行导航。

考虑到在实际应用中，在线打车业务得到了广泛应用，对于在线打车业务而言，打车用户(可看作是第一用户)可在相应的打车软件中输入目的地信息，并发出打车请求，驾车用户(可看作是第二用户)通过打车软件可接收该第一用户发出的打车请求，实现在线打车业务。显然，在该场景中，确定合适的上车位置，有助于减少驾车用户的行驶路径，并能够减少打车用户与驾车用户之间的沟通次数。

因此，本申请中的上述方法可以适用于实际应用中在线打车的场景。其中，实际应用场景中的架构也如图1a所示，在该实际场景下，包含打车用户、驾车用户以及打车软件后台的服务器，具体而言，打车用户通过打车软件输入目的地位置，发出打车请求。待驾车用户接单后，服务器将建立打车用户与驾车用户之间的导航关联，在该过程中，服务器可获取打车用户、驾车用户的位置，以及目的地的位置。

在这样的场景下，本申请实施例提供一种会合地点的确定方法，如图4所示，具体包括如下步骤：

S401：根据打车用户和驾车用户的位置，以及目的地，生成第一导航路径。

S402：确定所述打车用户的位置对应的候选位置。

S403：根据所述候选位置、目的地以及所述驾车用户的位置，生成第二导航路径。

S404：当确定所述第二导航路径短于所述第一导航路径时，将所述候选位置确定为所述第一用户前往所述目的地的上车点。

针对打车场景，实际的操作过程可以是：打车用户通过打车软件输入目的地和出发点，并发起打车任务，驾车用户成功接单后，此时服务器可以根据距离和拥堵情况，计算出最佳行驶路线，该行驶路线是从用户所在位置前往目的地的路线，为了便于描述，将该路线称为L_a，同时，服务器还将确定出驾车用户前往打车用户所在位置的行驶路线，为了便于描述，将该路线称为L_b，此时服务器将确定路线L_a和路线L_b的交集部分(实质上，这里的路线L_a和路线L_b就构成了前述内容中的第一导航路径)，并确定路线交集部分中是否存在路口，如果存在路口，就选择得到离用户最近的路口为“最佳上车点”，当然，该路口距打车用户的距离不应超过设定距离，进而服务器将该“最佳上车点”的位置发送给打车用户，只有在打车用户同意移动至该“最佳上车点”后，服务器才会将该“最佳上车点”的位置发送给驾车用户。

本方法中的具体内容与前述方法的相类似，具体可以参考前述方法，这里不再过多赘述。

以上为本申请实施例提供的会合地点的确定方法，基于同样的思路，本申请实施例还提供一种会合地点的确定装置。

如图5所示，该装置包括：

第一路径模块501，根据第一用户和第二用户的位置，以及目标位置，生成第一路径；

候选位置模块502，确定所述第一用户的位置对应的候选位置；

第二路径模块503，根据所述候选位置、目标位置以及所述第二用户的位置，生成第二路径；

确定模块504，当确定所述第二路径短于所述第一路径时，将所述候选位置确定为所述第一用户和第二用户前往所述目标位置的会合地点。

所述装置还包括：发送模块505，将所述汇合地点发送给所述第一用户和/或第二用户，以便于所述第一用户和/或第二用户前往所述汇合地点。

所述装置还包括：接收模块506，接收所述第一用户的确认指令。

候选位置模块502，根据所述第一用户的位置以及预设的距离阈值，确定所述第一用户的位置对应的候选位置。其中，所述候选位置与所述第一用户的位置之间的距离，不超过所述预设的距离阈值。

在候选位置为路口的情况下，候选位置模块502，根据所述第一用户的位置以及预设的距离阈值，确定与所述第一用户相关的路段，在确定出的所述路段中，确定所述第一用户的位置对应的候选位置。

进一步地，候选位置模块502，以所述第一用户的位置为起始位置，根据所述预设的距离阈值，统计与所述起始位置之间的距离不超过所述距离阈值的各路段，将统计得到的各路段确定为与所述第一用户相关的路段。

进一步地，候选位置模块502，在与所述第一用户相关的路段中，确定各路段所对应的路口位置，在确定出的所述路口位置中，选择与所述第一用户所在位置的距离不超过预设的距离阈值的各路口位置，并确定为与第一用户相关的候选位置。

需要说明的是，如图5所示的装置，还适用于在线打车的场景，具体而言，

第一路径模块501，根据打车用户和驾车用户的位置，以及目的地，生成第一导航路径；

候选位置模块502，确定所述打车用户的位置对应的候选位置；

第二路径模块503，根据所述候选位置、目的地以及所述驾车用户的位置，生成第二导航路径；

确定模块504，当确定所述第二导航路径短于所述第一导航路径时，将所述候选位置确定为所述第一用户前往所述目的地的上车点。

上述如图5所示的装置，应用于服务器侧，针对第一用户侧，本申请实施例提供一种会合地点的确定装置，如图6所示：

发送模块601，向服务器发出用于确定与第二用户之间会合地点的会合请求；其中，所述会合请求中携带有所述第一用户的位置；

接收模块602，接收服务器反馈的会合地点，其中，所述会和地点，由所述服务器根据第一用户和第二用户的位置，以及目标位置，生成第一路径，确定所述第一用户的位置对应的候选位置，根据所述候选位置、目标位置以及所述第二用户的位置，生成第二路径，当确定所述第二路径短于所述第一路径时，并根据所述候选位置所确定。

所述发送模块601还用于，根据用户的确认操作，向所述服务器发送对所述会合地点的确认指令。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。