CN109614557A - 用于推荐上车点的方法、设备以及计算机可读存储介质 - Google Patents

Abstract

本公开的实施例涉及用于推荐上车点的方法、设备以及计算机可读存储介质。方法包括在用户设备位于预定区域中的情况下显示功能区列表。方法还包括基于接收到的对功能区列表中的某个功能区的选择，推荐与所选功能区相关联的上车点。本公开的实施例针对处于复杂场景中的打车用户，提供一个或多个功能区供用户选择，从而能够向用户推荐合适的且准确的上车点，由此提升用户的打车体验。

Description

用于推荐上车点的方法、设备以及计算机可读存储介质

技术领域

本公开的实施例总体上涉及智能交通领域，并且更具体地涉及用于推荐上车点的方法、设备以及计算机可读存储介质。

背景技术

随着移动互联网的快速发展，在移动终端上涌现了各种各样的智能应用。打车应用或软件是一种常用的智能交通应用，乘客可以通过手机便捷地发布打车信息，并和接单司机直接沟通，这大大提高了打车效率。在乘客打车的过程中，乘客可以通过在地图上指定或者通过搜索来选择上车点和下车点，然后客户端把包括上车点和下车点的打车信息发送到服务器，服务器基于打车信息调度适合的车辆。

一般来说，乘客可能选择任何地点作为上车点，此外，服务器也可以向乘客推荐一些上车点。服务器可以基于乘客和司机的轨迹和订单等历史信息，通过数据挖掘自动获得一些推荐上车点。例如，如果大量乘客选择某个位置作为上车点，则可以说明该位置可能比较适合上车，因此，服务器可以将这个位置存储为推荐上车点，并且在乘客准备打车时向乘客推荐。

发明内容

本公开的实施例提供了用于推荐上车点的方法、设备以及计算机可读存储介质。

在本公开的第一方面，提供了一种用于推荐上车点的方法。该方法包括：获取用户设备的位置；响应于位置被确定为位于预定区域中，在用户设备上呈现功能区列表，其中功能区列表指示一个或多个功能区，并且每个功能区是预定区域中具有相应功能的空间区域；接收对功能区列表中的第一功能区的选择；以及推荐与第一功能区相关联的第一上车点。

在本公开的第二方面，提供了一种用于推荐上车点的方法。该方法包括：响应于接收到用户设备的位置的信息，确定用户设备的位置是否位于预定区域中；响应于确定用户设备的位置位于预定区域中，获取与预定区域相关联的功能区信息，其中功能区信息至少指示一个或多个功能区，并且每个功能区是预定区域中具有相应功能的空间区域；以及向用户设备发送功能区信息。

在本公开的第三方面，提供了一种用户设备。该用户设备包括处理单元以及存储器，其中存储器被耦合至处理单元并且存储有指令。所述指令在由处理单元执行时执行以下动作：获取用户设备的位置；响应于位置被确定为位于预定区域中，在用户设备上呈现功能区列表，其中功能区列表指示一个或多个功能区，并且每个功能区是预定区域中具有相应功能的空间区域；接收对功能区列表中的第一功能区的选择；以及推荐与第一功能区相关联的第一上车点。

在本公开的第四方面，提供了一种服务器。该服务器包括处理单元以及存储器，其中存储器被耦合至处理单元并且存储有指令。所述指令在由处理单元执行时执行以下动作：响应于接收到用户设备的位置的信息，确定用户设备的位置是否位于预定区域中；响应于确定用户设备的位置位于预定区域中，获取与预定区域相关联的功能区信息，其中功能区信息至少指示一个或多个功能区，并且每个功能区是预定区域中具有相应功能的空间区域；以及向用户设备发送功能区信息。

在本公开的第五方面，提供了一种用于推荐上车点的方法。该方法包括：获取用户设备的位置；响应于位置被确定为位于预定区域中，在用户设备上呈现上车点列表，其中上车点列表指示一个或多个上车点；接收对上车点列表中的第一上车点的选择；以及基于所选择的第一上车点生成打车请求。

在本公开的第六方面，提供了一种用户设备。该用户设备包括处理单元以及存储器，其中存储器被耦合至处理单元并且存储有指令。所述指令在由处理单元执行时执行以下动作：获取用户设备的位置；响应于位置被确定为位于预定区域中，在用户设备上呈现上车点列表，上车点列表指示一个或多个上车点；接收对上车点列表中的第一上车点的选择；以及基于所选择的第一上车点生成打车请求。

在本公开的第七方面，提供了一种计算机可读存储介质，计算机可读存储介质在其上存储有计算机程序，计算机程序在被处理器执行时实现根据本公开的实施例的方法或过程。

提供发明内容部分是为了简化的形式来介绍对概念的选择，它们在下文的具体实施方式中将被进一步描述。本发明内容部分无意标识本公开的关键特征或主要特征，也无意限制本公开的各个实施例的范围。

附图说明

通过结合附图对本公开示例性实施例进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中在本公开示例性实施例中，相同的附图标记通常代表相同的元素。

图1示出了根据本公开的实施例的用于推荐上车点的示例环境的示意图；

图2示出了根据本公开的实施例的用于推荐上车点的方法的流程图；

图3示出了根据本公开的实施例的用于推荐上车点的另一方法的流程图；

图4示出了根据本公开的实施例的用于在复杂场景下生成打车请求的过程的示意图；

图5-图6示出了根据本公开的实施例的用于标注复杂场景的示意图；

图7示出了根据本公开的实施例的用于确定推荐上车点的方法的流程图；

图8A-8B示出了根据本公开的实施例的用于推荐上车点的图形用户界面(GUI)的示图；以及

图9示出了可以用来实施本公开的实施例的设备的示意性框图。

具体实施例

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

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

在传统的打车场景中，服务器可以基于对历史信息的大数据挖掘，自动获得一些推荐上车点。在普通场景下，通过这种方式获得上车点对于乘客和司机能够提供一些帮助，因而能够方便乘客上车。然而，在一些复杂场景下，例如火车站、机场、大型商圈等，依靠数据挖掘得到的上车点可能并不适合上车，因为很多位置和区域可能是禁止停车的。因此，传统的上车点推荐方法无法在复杂场景下为乘客推荐合适的且准确的上车点，而用户可能也无法自主地选择合适的上车点，因而需要乘客与司机之间需要大量的电话或消息沟通，造成了较差的打车体验。

为此，本公开的实施例提出了一种用于推荐上车点的新方案。本公开的实施例针对处于复杂场景中的用户(通常为乘客，也可以为替乘客叫车的其他人)，提供一个或多个功能区供用户选择，从而能够向用户推荐更合适且准确的上车点，由此提升用户的打车体验。此外，由于本公开的实施例所推荐的上车点可以是经过人工标注的上车点，因而更方便复杂场景下的打车接乘管理，减少复杂场景下的混乱停车。

以下参考图1至图9来说明本公开的基本原理和若干示例实现方式。应当理解，给出这些示例性实施例仅是为了使本领域技术人员能够更好地理解进而实现本公开的实施例，而并非以任何方式限制本公开的范围。

图1示出了根据本公开的实施例的用于推荐上车点的示例环境100的示意图。如图1所示，环境100包括用户设备110和服务器120，它们之间可以通过网络130互相连接。网络130可以为有线网络、无线网络、或者有线网络和无线网络的组合，例如，网络130可以包括但不限于因特网、广域网、城域网、局域网、虚拟专用网络(VPN)网络、无线通信网络，等等。

在一些实施例中，用户设备110可以是具备联网能力和显示能力的任何移动终端，其中移动终端可以是指搭载各种操作系统并且可根据用户需求定制一些功能的终端设备，包括但不限于智能手机、平板电脑、可穿戴设备、以及便携式计算机，等等。此外，服务器120可以为集中式服务器或者分布式服务器，其可以被部署在云中。

如图1所示，用户设备110包括显示模块113、打车应用115以及定位模块117。显示模块113可以提供显示功能，其可以为用户设备110的显示屏。打车应用115可以为被安装在用户设备110的操作系统中的打车应用程序(诸如“APP”)，也可以是附着在其他应用程序中的打车小程序或者打车页面，用户通过打车应用115能够发布打车需求。

定位模块117是指能够确定用户设备110的位置的模块，其可以为卫星定位系统。卫星定位系统可以包括但不限于美国的全球定位系统(GPS)、欧洲的伽利略卫星定位系统、以及中国的北斗卫星定位系统，等等。备选地，用户设备110也可以不具备卫星定位系统，相反，定位模块117可以通过移动网络来获得用户设备110的大概位置。应当理解，用户设备110还可以包括在图1中未示出的一些其他模块和/或设备，诸如通信模块、输入输出设备，等等。

继续参考图1，服务器120可以包括标注模块123、复杂场景处理模块125以及调度模块127。标注模块123可以是复杂场景的标注平台，其提供一个便捷的人工编辑平台，在该平台上可以实现复杂场景的增加、修改以及删除等操作。复杂场景处理模块125实现对用户是否处于复杂场景的在线判定，其可以通过确定用户的位置(诸如经纬度)是否位于预定区域来判断是否执行复杂场景下的上车点推荐。调度模块127用于在收到用户的打车请求(其包括上车点和下车点)之后，实现对车辆的调度，由此实现用户与司机之间的打车配对。

图2示出了根据本公开的实施例的用于推荐上车点的方法200的流程图。应当理解，方法200中的至少一部分可以由以上参考图1所描述的用户设备110来执行。

在框202，获取用户设备的位置。例如，在用户准备打车的情况下，例如，用户打开打车应用115准备打车或者用户进入到打车应用115的打车页面，可以通过用户设备110的定位模块117来确定用户设备110所处的位置。在一些实施例中，用户设备110的位置可以通过经度和维度来表示。

在框203，判断用户设备的位置是否被确定为位于预定区域中。如果用户设备的位置被服务器或者用户设备确定为位于预定区域中，则在框204，在用户设备上呈现功能区列表，其中功能区列表指示一个或多个功能区，并且每个功能区是预定区域中具有相应功能的空间区域。例如，如果根据位置确定用户设备110位于某个预先定义的区域(例如包括火车站的一个区域)中，则说明其处于某个复杂场景(例如火车站)，因此，可以经由显示模块113向用户呈现一个或多个功能区以供用户选择。在本公开的实施例中，预定区域可以是具有立体的道路结构和有限的可上车位置的区域，其能够覆盖复杂场景所涉及的活动范围。可选地，可以由服务器120来在线确定用户设备位置是否位于预定区域中。备选地，如果用户设备110已经获得预定区域的信息，则也可以由用户设备110自身来确定其是否位于预定区域中。

例如，在复杂场景为上海虹桥火车站的示例中，功能区可以被划分为虹桥火车站北到达口和虹桥火车站南到达口。在本公开的一些实施例中，每个复杂场景可以被划分成一个或多个功能区，每个功能区可以表示该复杂场景在物理世界中具有特定概念的一个空间，其可以根据运营人员的知识而被划分和命名，并且是打车软件的用户可分辨的实体。例如，上海虹桥火车站的功能区也可以被划分为虹桥火车站北1-3号出口和虹桥火车站南1-3号出口、或者被划分为虹桥火车站南广场西侧停车场区和虹桥火车站南广场东侧餐饮区，等等。用户根据其出口位置或出行规划，可以很容易地明确其想要从哪个功能区打车。

在框206，接收对功能区列表中的第一功能区的选择。例如，在向用户呈现功能区列表之后，用户需要选择其中的一个功能区。在一些实施例中，可以将最推荐的功能区作为默认功能区呈现给用户。如果用户接受该推荐功能区，则其点击例如“确定”或“确认”菜单即可。相反，用户还可以不接受该推荐功能区，而是选择其他的功能区。例如，用户可以通过上下滚动的方式或者点击功能区名称的方式来选择某个功能区。

在框208，推荐与第一功能区相关联的第一上车点。例如，在复杂场景为上海虹桥火车站的示例中，如果用户选择的是虹桥火车站北到达口功能区，则可以向用户推荐与虹桥火车站北到达口相对应的上车点。在一些实施例中，可以将推荐上车点直接输入到打车地址窗口的出发地框中，并且可以在用户设备的电子地图上突出显示推荐上车点和预定区域的可视表示。通过这种方式，可以使得用户更直观地看到推荐上车点的位置以及其所处的预定区域的范围，提升用户体验。因此，本公开的实施例的方法200通过使用户选择具有物理含义的某个功能区，能够向用户推荐合适的且准确的上车点，由此提升用户的打车体验，从而提高接乘效率。

在一些实施例中，如果用户接受推荐上车点，则其可以进一步选择下车点，移动设备进而可以基于推荐上车点和下车点来生成打车请求，即打车订单。如果用户不接受推荐上车点，则用户可以修改上车点并选择其所想要的其他上车点。例如，可以在用户设备上重新显示功能区列表，并且用户可以选择功能区列表中的另一功能区。接下来，用户设备可以将向用户推荐与另一功能区相关联的另一上车点。通过这种方式，使得用户能够选择到满意的上车点，从而提升用户的便捷性和用户体验。

图3示出了根据本公开的实施例的用于推荐上车点的另一方法300的流程图。应当理解，方法300可以由以上参考图1所描述的服务器120来执行。

在框301，服务器判断是否接收到用户设备的位置的信息。如果服务器接收到用户设备的位置的信息，则在框302，确定用户设备的位置是否位于预定区域中。例如，在服务器120在接收到来自用户设备110的位置信息的情况下，其复杂场景处理模块125可以判断用户设备110是否位于预定区域，从而确定用户设备是否处于某个复杂场景。在一些实施例中，复杂场景处理模块125可以根据用户设备110的经纬度来确定用户设备110是否处于某个预定区域。

如果在框302确定用户设备的位置位于预定区域中，则在框304，获取与预定区域相关联的功能区信息，其中功能区信息至少指示将要呈现的一个或多个功能区，并且每个功能区是预定区域中具有相应功能的空间区域。例如，如果判断用户设备110处于复杂场景下，则将复杂场景中的功能区提取出来，或者将复杂场景中的功能区和上车点提取出来。在一些实施例中，复杂场景处理模块125可以根据用户设备的位置对功能区和/或上车点进行排序，以便提供推荐的功能区和/或推荐的上车点，从而减少用户的选择时间，提高打车效率。

在框306，向用户设备发送功能区信息。例如，服务器120将所获得的功能区信息发送给用户设备110以用于前端展示给用户。用户可以根据从服务器120接收到的功能区列表选择某个功能区，从而获得推荐的上车点。因此，本公开的实施例的方法300能够在用户处于复杂场景下提供可供用户选择的功能区列表，从而能够向用户推荐合适且准确的上车点，由此提升用户的打车体验。

图4示出了根据本公开的实施例的用于在复杂场景下生成打车请求的过程400的示意图。为了便于更清楚地描述本公开的一些示例实施例，在描述图4的过程400的同时结合了图5-图7以及图8A-8B一起进行描述。应当理解，虽然图4中示出了在复杂场景下生成打车请求的一个示例详细过程，然而，本公开的实施例不是必须包括图4中的所有动作。相反，图4的一个或多个动作是可选的，本公开的一些实施例可以在没有图4中的一个或多个动作的情况下被实现。

如图4所示，过程400涉及到用户105、用户设备110、服务器120以及运营人员135之间的交互。如箭头401所示，运营人员135可以标注和/或配置复杂场景，然后，服务器120存储经标注的复杂场景数据库，如箭头402所示。应当理解，虽然图4中将复杂场景标注平台和复杂场景的标注数据库部署在用于打车的服务器120中，然而，其也可以被部署在与服务器120不同的其他设备中，并且在需要时被服务器120调用。

在一些实施例中，针对每个复杂场景，标注数据库可以存储三层的数据结构：预定区域(其范围通过围栏顶点信息而被确定，也称为围栏区域)、功能区、以及上车点。例如，图5-图6示出了根据本公开的实施例的用于标注复杂场景的示意图。图5示出了一个示例地图500，其包括上海虹桥火车站附近的区域。运营人员135可以通过标注平台来在地图500上标注上海虹桥火车站这一复杂场景。如图6的示意图600所示，运营人员可以首先在地图500上选择一个预定区域510，使得其包含上海虹桥火车站。在一些实施例中，可以通过多边形的多个顶点来限定预定区域，其中每个顶点可以以经纬度来表示。例如，在图6中通过围栏顶点511、512、513以及514限定预定区域510。应当理解，虽然图6中示出了一个矩形的预定区域，然而，预定区域也可以为其他的规则的或不规则的几何形状。

继续参考图6，运营人员135可以针对上海虹桥火车站这一复杂场景配置功能区，例如功能区521，即虹桥火车站北到达口，和功能区522，即虹桥火车站南到达口，功能区通常通过打车用户可分辨的不同功能区名称而被区分。接下来，可以对每个功能区设置一个或多个上车点，以表示在此功能区打车的用户在打车时可以推荐的合适上车点。如图6所示，针对功能区521可以配置两个上车点531和532，针对功能区522可以配置两个上车点533和534。

此外，运营人员135不仅可以增加复杂场景标注数据，还可以修改和/或删除复杂场景标注数据。例如，运营人员135可以修改和/或删除预定区域、功能区以及上车点中的一项或多项。如果运营人员135删除了某个复杂场景，则相应的功能区和上车点都将被删除。类似地，如果运营人员135删除了某个功能区，则相应的上车点也都将被删除。此外，运营人员还可以针对某个预定区域设定默认功能区，和/或针对某个功能区设定默认上车点。通过这种方式，可以直接向用户推荐运营人员所设定的默认功能区和/或默认上车点，以提高用户的打车效率。在一些实施例中，可以对标注平台增加人工审核环节，当运营人员135标注完成之后，需要在其他的人员审核之后才能存储到标注数据库中。另外，除了运营人员之外，打车应用115的开发人员和产品经理也可以对复杂场景进行标注和/或配置。

下表1-3示出了根据本公开的实施例的用于存储复杂场景的标注数据的示例数据表，其中表1示出了复杂场景数据表，表2示出了功能区数据表，表3示出了上车点数据表。应当理解，虽然示出了使用不同的表来存储标注数据，然而，也可以使用一个表来存储这些数据，或者使用不同的数据结构来存储标注数据，本公开的实施例不受标注数据存储形式的限制。

表1：复杂场景数据表

表2：功能区数据表

表3：上车点数据表

如上所示，复杂场景数据表1包括每个复杂场景的标识符(ID)、复杂场景名称、预定区域的围栏顶点信息(诸如地理信息，其通过经纬度来表示)、以及每个复杂场景下的功能区列表。在接收到用户设备110的位置之后，服务器120可以基于复杂场景数据表1中的围栏顶点信息来确定用户设备是否正处于某个复杂场景。

功能区数据表2中包括每个功能区的ID、功能区名称、每个功能区对应的上车点列表、以及功能区所属的复杂场景的场景ID。因此，服务器120通过查询功能区数据表2，可以获得各个复杂场景下的所有功能区的信息。

上车点数据表3包括每个上车点的ID、上车点名称、上车点经度、上车点维度、以及上车点所属的功能区的功能区ID。因此，服务器120通过查询上车点数据表3，可以获得每个功能区对应的所有上车点的信息。由此可见，通过复杂场景数据表1可以确定用户是否处于复杂场景，如果用户处于某个复杂场景，则可以获取该复杂场景的场景ID。接下来，可以基于该场景ID和功能区数据表2获得对应的所有功能区ID，并且可以基于功能区ID和上车点数据表3获得对应的所有上车点的信息。

返回参考图4，如箭头403所示，在某一时刻，用户105可以请求上车点推荐服务。例如，如果用户打开打车应用准备打车或者用户进入到打车应用的打车页面，则可以认为用户正在请求上车点推荐服务。接下来，用户设备110通过其定位模块117确定用户设备110的位置，如箭头404所示，并且将用户设备110的位置发送到服务器120，如箭头405所示。在一些实施例中，也可以由用户设备110自身判断其是否处于复杂场景，在这种情况下，需要用户设备110实时地或者预先地从服务器120获得复杂场景的标注数据。

服务器120在接收到用户设备110的位置信息之后，确定用户设备是否处于复杂场景，如箭头406所示。在确定用户设备处于复杂场景的情况下获得该复杂场景下的功能区信息，如箭头407所示。在一些实施例中，在获得复杂场景下的功能区信息的过程中，可以对功能区和上车点进行排序，以便向用户提供最推荐的功能区和上车点，提高用户的打车效率。

参考图7，其示出了根据本公开的实施例的用于确定推荐上车点的方法700的流程图。应当理解，方法700可以由以上参考图1所描述的服务器120来执行。在框702，基于用户设备的位置，获得所命中的复杂场景下的功能区信息。在框704，判断针对该复杂场景是否已经设定默认功能区。如果已经设定默认功能区，则在框706直接将默认功能区确定为向用户呈现的推荐功能区(其处于向用户呈现的默认选择位置，因而也可称为默认功能区)。如果在704确定针对该复杂场景尚未设定默认功能区，则在框708根据用户设备位置与每个上车点的距离确定推荐功能区。例如，可以选择该复杂场景中的所有上车点中与用户设备距离最小的上车点，并且将距离最小的上车点对应的功能区指定为推荐功能区。

继续参考图7，接下来，在框710，判断是否已经针对推荐功能区设定默认上车点。如果针对推荐功能区已经设定默认上车点，则在框712，将默认上车点确定为推荐上车点(其处于向用户呈现的默认选择位置，因而也可称为默认上车点)。如果针对推荐功能区尚未设定默认上车点，则在框714根据用户设备位置与推荐功能区中的每个上车点的距离，确定推荐上车点。例如，选择推荐功能区所对应的所有上车点中与用户设备位置距离最小的上车点，并且将距离最小的上车点指定为推荐上车点。接下来，还可以针对其他的功能区，分别确定或者指定其默认上车点。通过这种方式，可以向用户提供推荐功能区和推荐上车点，使得用户可以高效获得最推荐的上车点，减少了用户交互，提高了打车效率。此外，虽然图7中示出了通过排序来确定推荐功能区和推荐上车点，然而，服务器也可以不执行排序过程，而是直接将所有的功能区和上车点发给用户设备以便用户自己进行选择。

返回参考图4，如箭头408所示，将所获得经排序的或者未排序的功能区信息发送给用户设备110以用于推荐。在一些实施例中，所发送的功能区信息中可以同时包括一个或多个功能区以及相关联的一个或多个上车点。备选地，所发送的功能区信息可以仅包括功能区本身的信息，而上车点信息可以由用户设备从其本地的数据库来进行获取。接下来，用户设备110向用户105呈现功能区列表，如箭头409所示，用户105从功能区列表中选择某个功能区，如箭头410所示。在接收到用户105选择的功能区之后，用户设备110向用户105推荐与所选功能区对应的上车点，如箭头411所示。接下来，用户可以对推荐上车点进行确认，或者也可以修改以重新选择上车点，如箭头412所示。

图8A-8B示出了根据本公开的实施例的用于推荐上车点的GUI 800和850的示图。例如，在复杂场景为上海虹桥火车站的示例中，在确定用户处于上海虹桥火车站的情况下，如图8A的GUI 800所示，可以在电子设备110上呈现弹出窗口810，窗口810包括一些提示信息和功能区列表815。用户可以滚动功能区列表815来选择某个功能区，在GUI 800的示例中，推荐功能区(即默认功能区)为虹桥火车站北到达口。如果用户不在火车站附近而是发生定位误差，则用户可以点击窗口810中的“起点不在火车站”菜单，从而执行非复杂场景下的打车过程。

如图8B的GUI 850所示，在用户通过点击“确定”菜单而选择功能区列表815中的推荐功能区(即虹桥火车站北到达口)之后，用户设备110基于用户的选择，可以弹出打车地址窗口860。如图8B所示，在窗口860中包括基于用户选择而推荐的上车点865，即虹桥火车站P9停车场。接下来，用户可以确认推荐上车点865，也可以对推荐上车点865进行修改，如上文所描述的。在一些实施例中，可以在电子地图上突出显示推荐上车点865的标记870，以便方便用户前往推荐上车点。在一些实施例中，还可以在电子地图中显示预定区域的可视表示(图8B中未示出)，使得用户知晓其正处于预定区域以及预定区域的范围。

再次返回图4，在用户确定复杂场景下的上车点之后，用户还可以进一步选择下车点。在确定用户的上车点和下车点之后，计算设备110可以生成打车请求(如打车订单)，并且将打车请求发送给服务器120，如箭头413所示。服务器120在收到打车请求之后，其调度模块127可以执行车辆调度，从而实现用户与司机之间的打车配对。

备选地，在一些实施例中，还可以在复杂场景中直接推荐上车点，而不需要用户手动选择某一功能区。例如，获取用户设备的位置，并且在位置被确定为位于预定区域的情况下在用户设备上呈现上车点列表，其中上车点列表显示一个或多个上车点。接下来，从用户接收对上车点列表中的第一上车点的选择，并且基于用户选择的第一上车点来生成打车请求。在一些实施例中，预定区域是指具有立体的道路结构和有限的可上车位置的区域，并且可以在用户设备上通过滚动条的方式来显示上车点列表。

图9示出了可以用来实施本公开的实施例的设备900的示意性框图，设备900可以为以上参考图1所描述的用户设备110或服务器120。如图所示，设备900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的计算机程序指令或者从存储单元908加载到随机访问存储器(RAM)903中的计算机程序指令，来执行各种适当的动作和处理。在RAM 903中，还可存储设备900操作所需的各种程序和数据。CPU 901、ROM 902以及RAM903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

设备900中的多个部件连接至I/O接口905，包括：输入单元906，例如键盘、鼠标等；输出单元907，例如各种类型的显示器、扬声器等；存储单元908，例如磁盘、光盘等；以及通信单元909，例如网卡、调制解调器、无线通信收发机等。通信单元909允许设备900通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

上文所描述的各个方法或过程可由处理单元901执行。例如，在一些实施例中，方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元908。在一些实施例中，计算机程序的部分或者全部可以经由ROM 902和/或通信单元909而被载入和/或安装到设备900上。当计算机程序被加载到RAM 903并由CPU 901执行时，可以执行上文描述的方法或过程中的一个或多个步骤或动作。

在一些实施例中，以上所描述的方法和过程可以被实现为计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本公开的各个方面的计算机可读程序指令。

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

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

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

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

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

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

Claims (29)

1.一种用于推荐上车点的方法，包括：

获取用户设备的位置；

响应于所述位置被确定为位于预定区域中，在所述用户设备上呈现功能区列表，所述功能区列表指示一个或多个功能区，每个功能区是所述预定区域中具有相应功能的空间区域；

接收对所述功能区列表中的第一功能区的选择；以及

推荐与所述第一功能区相关联的第一上车点。

2.根据权利要求1所述的方法，还包括：

向服务器发送所述用户设备的所述位置的信息；以及

从所述服务器接收基于所述位置确定的功能区信息，所述功能区信息至少指示将要在所述用户设备上呈现的所述一个或多个功能区。

3.根据权利要求2所述的方法，其中所述功能区信息还指示与所述一个或多个功能区分别关联的一个或多个上车点。

4.根据权利要求1所述的方法，其中推荐所述第一上车点包括：

在所述用户设备的打车地址窗口中显示所述第一上车点的信息；

在所述用户设备的电子地图上突出显示所述第一上车点的标记；以及

在所述电子地图上显示所述预定区域的可视表示。

5.根据权利要求1所述的方法，还包括：

经由所述用户设备接收对所述第一上车点的确认；以及

基于所述第一上车点，生成打车请求。

6.根据权利要求1所述的方法，还包括：

经由所述用户设备接收对所述第一上车点的修改；

在所述用户设备上重新呈现所述功能区列表；以及

响应于接收到对所述功能区列表中的第二功能区的选择，推荐与所述第二功能区相关联的第二上车点，所述第二功能区不同于所述第一功能区，并且所述第二上车点不同于所述第一上车点。

7.一种用于推荐上车点的方法，包括：

响应于接收到用户设备的位置的信息，确定所述用户设备的所述位置是否位于预定区域中；

响应于确定所述用户设备的所述位置位于预定区域中，获取与所述预定区域相关联的功能区信息，所述功能区信息至少指示一个或多个功能区，每个功能区是所述预定区域中具有相应功能的空间区域；以及

向所述用户设备发送所述功能区信息。

8.根据权利要求7所述的方法，其中所述功能区信息还指示与所述一个或多个功能区分别关联的一个或多个上车点，并且获取所述功能区信息包括：

确定所述一个或多个功能区中的用于推荐的第一功能区；以及

确定所述第一功能区中的用于推荐的第一上车点作为所述功能区信息的一部分。

9.根据权利要求8所述的方法，其中确定所述一个或多个功能区中的用于推荐的第一功能区包括：

确定针对所述预定区域是否已经设定默认功能区；

响应于确定针对所述预定区域已经设定所述默认功能区，将所述默认功能区确定为所述第一功能区；以及

响应于确定针对所述预定区域尚未设定所述默认功能区：

确定所述一个或多个上车点中与所述用户设备的所述位置距离最小的上车点；以及

将与所述距离最小的上车点相对应的功能区确定为所述第一功能区。

10.根据权利要求9所述的方法，其中确定所述第一功能区中的用于推荐的第一上车点包括：

确定针对所述第一功能区是否已经设定默认上车点；

响应于确定针对所述第一功能区已经设定所述默认上车点，将所述默认上车点确定为所述第一上车点；以及

响应于确定针对所述第一功能区尚未设定所述默认上车点，将所述第一功能区中与所述用户设备的所述位置距离最小的上车点确定为所述第一上车点。

11.根据权利要求7所述的方法，其中获取所述预定区域中的功能区信息包括：

基于所述用户设备的所述位置，从数据库获取所述预定区域的标识符，所述数据库中的每个数据项表示一个预定区域，并且包含所述预定区域的场景名称、地理范围以及一个或多个功能区的信息；以及

基于所述预定区域的所述标识符，获取与所述一个或多个功能区相关联的信息。

12.根据权利要求11所述的方法，其中所述数据库通过以下至少一项而被构建：

增加预定区域、功能区以及上车点中的至少一项；

修改预定区域、功能区以及上车点中的至少一项；

删除预定区域、功能区以及上车点中的至少一项；

设定针对某个预定区域的默认功能区；以及

设定针对某个功能区的默认上车点。

13.一种用户设备，包括：

处理单元；以及

存储器，其耦合至所述处理单元并且存储有指令，所述指令在由所述处理单元执行时执行以下动作：

获取所述用户设备的位置；

响应于所述位置被确定为位于预定区域中，在所述用户设备上呈现功能区列表，所述功能区列表指示一个或多个功能区，每个功能区是所述预定区域中具有相应功能的空间区域；

接收对所述功能区列表中的第一功能区的选择；以及

推荐与所述第一功能区相关联的第一上车点。

14.根据权利要求13所述的设备，所述动作还包括：

向服务器发送所述用户设备的所述位置的信息；以及

从所述服务器接收基于所述位置确定的功能区信息，所述功能区信息至少指示将要在所述用户设备上呈现的所述一个或多个功能区。

15.根据权利要求14所述的设备，其中所述功能区信息还指示与所述一个或多个功能区分别关联的一个或多个上车点。

16.根据权利要求13所述的设备，其中推荐所述第一上车点包括：

在所述用户设备的打车地址窗口中显示所述第一上车点的信息；

在所述用户设备的电子地图上突出显示所述第一上车点的标记；以及

在所述电子地图上显示所述预定区域的可视表示。

17.根据权利要求13所述的设备，所述动作还包括：

经由所述用户设备接收对所述第一上车点的确认；以及

基于所述第一上车点，生成打车请求。

18.根据权利要求13所述的设备，所述动作还包括：

经由所述用户设备接收对所述第一上车点的修改；

在所述用户设备上重新呈现所述功能区列表；以及

响应于接收到对所述功能区列表中的第二功能区的选择，推荐与所述第二功能区相关联的第二上车点，所述第二功能区不同于所述第一功能区，并且所述第二上车点不同于所述第一上车点。

19.一种服务器，包括：

处理单元；以及

存储器，其耦合至所述处理单元并且存储有指令，所述指令在由所述处理单元执行时执行以下动作：

响应于接收到用户设备的位置的信息，确定所述用户设备的所述位置是否位于预定区域中；

响应于确定所述用户设备的所述位置位于预定区域中，获取与所述预定区域相关联的功能区信息，所述功能区信息至少指示一个或多个功能区，每个功能区是所述预定区域中具有相应功能的空间区域；以及

向所述用户设备发送所述功能区信息。

20.根据权利要求19所述的服务器，其中所述功能区信息还指示与所述一个或多个功能区分别关联的一个或多个上车点，并且获取所述功能区信息包括：

确定所述一个或多个功能区中的用于推荐的第一功能区；以及

确定所述第一功能区中的用于推荐的第一上车点作为所述功能区信息的一部分。

21.根据权利要求20所述的服务器，其中确定所述一个或多个功能区中的用于推荐的第一功能区包括：

确定针对所述预定区域是否已经设定默认功能区；

响应于确定针对所述预定区域已经设定所述默认功能区，将所述默认功能区确定为所述第一功能区；以及

响应于确定针对所述预定区域尚未设定所述默认功能区：

确定所述一个或多个上车点中与所述用户设备的所述位置距离最小的上车点；以及

将与所述距离最小的上车点相对应的功能区确定为所述第一功能区。

22.根据权利要求21所述的服务器，其中确定所述第一功能区中的用于推荐的第一上车点包括：

确定针对所述第一功能区是否已经设定默认上车点；

响应于确定针对所述第一功能区已经设定所述默认上车点，将所述默认上车点确定为所述第一上车点；以及

响应于确定针对所述第一功能区尚未设定所述默认上车点，将所述第一功能区中与所述用户设备的所述位置距离最小的上车点确定为所述第一上车点。

23.根据权利要求19所述的服务器，其中获取所述预定区域中的功能区信息包括：

基于所述用户设备的所述位置，从数据库获取所述预定区域的标识符，所述数据库中的每个数据项表示一个预定区域，并且包含所述预定区域的场景名称、地理范围以及一个或多个功能区的信息；以及

基于所述预定区域的所述标识符，获取与所述一个或多个功能区相关联的信息。

24.根据权利要求23所述的服务器，其中所述数据库通过以下至少一项而被构建：

增加预定区域、功能区以及上车点中的至少一项；

修改预定区域、功能区以及上车点中的至少一项；

删除预定区域、功能区以及上车点中的至少一项；

设定针对某个预定区域的默认功能区；以及

设定针对某个功能区的默认上车点。

25.一种用于推荐上车点的方法，包括：

获取用户设备的位置；

响应于所述位置被确定为位于预定区域中，在所述用户设备上呈现上车点列表，所述上车点列表指示一个或多个上车点；

接收对所述上车点列表中的第一上车点的选择；以及

基于所选择的所述第一上车点生成打车请求。

26.根据权利要求25所述的方法，其中在所述用户设备上呈现上车点列表包括：

在所述用户设备上使用滚动条显示所述上车点列表。

27.一种用户设备，包括：

处理单元；以及

存储器，其耦合至所述处理单元并且存储有指令，所述指令在由所述处理单元执行时执行以下动作：

获取所述用户设备的位置；

响应于所述位置被确定为位于预定区域中，在所述用户设备上呈现上车点列表，所述上车点列表指示一个或多个上车点；

接收对所述上车点列表中的第一上车点的选择；以及

基于所选择的所述第一上车点生成打车请求。

28.根据权利要求27所述的设备，其中在所述用户设备上呈现上车点列表包括：

在所述用户设备上使用滚动条显示所述上车点列表。

29.一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时执行根据权利要求1-12和25-26中任一项所述的方法。