CN111104990A - 一种确定交通行程的方法、装置、服务器及存储介质 - Google Patents

Abstract

本发明实施例公开了一种确定交通行程的方法、装置、服务器及存储介质，属于信息处理技术领域，用于对乘车码的交通场景下的用户的上下车站点进行检测。该方法中，通过扫码乘车码得到的扫码数据和扫码时间来确定目标用户的刷乘车码的刷码位置和/或下车位置，进而再将这两个位置与扫码机具所在的交通工具(例如公交车)所属的交通线路包括的多个站点位置进行匹配，以最终确定出用户的上下车站点，也就是说，提供了一种在乘车码的交通场景下的配套检测用户上下车站点的检测方案，从而增强了乘车码的交通场景的适用性。

Description

一种确定交通行程的方法、装置、服务器及存储介质

技术领域

本发明涉及信息处理技术领域，尤其涉及一种确定交通行程的方法、装置、服务器及存储介质。

背景技术

为了减少携带实体交通卡(例如公交卡)的不便，目前推出了使用乘车码搭乘公共交通的智慧交通出行方式，例如在乘坐公交车时，用户可以向公交车中设置的扫码枪展示手机中的乘车码，扫码枪在扫描用户展示的乘车码之后可以将扫码得到的数据上传给公交后台，然后再进行扣费。通过乘车码这种新兴的互联网交通产品，可以实现“先乘车、后付费”、快速、便捷的交通体验。

随着乘车码越来越广泛的使用，在乘车码的交通场景下如何确定用户的上下车站点是一个值得关注的问题。

发明内容

本发明实施例提供一种确定交通行程的方法、装置、服务器及存储介质，以提供一种在乘车码的交通场景下确定用户的上下车站点的方式，实现对用户的上下车站点的准确检测。

一方面，提供一种确定交通行程的方法，所述方法包括：

获得扫码机具扫描终端设备中的乘车码而得到的扫码数据、扫描所述乘车码的扫码时间和所述扫码机具所在的交通工具所属的交通线路，其中，所述乘车码和所述扫码数据中均携带有用户标识；

根据所述扫码时间，确定与所述用户标识对应的目标用户的刷码位置和/或交通行程结束位置；

将所述刷码位置与所述交通线路包括的多个站点进行位置匹配以确定所述目标用户的出发站点，和/或，将所述交通行程结束位置与所述交通线路包括的多个站点进行位置匹配以确定所述目标用户的下车站点。

一方面，提供一种确定交通行程的装置，所述装置包括：

获得模块，用于获得扫码机具扫描终端设备中的乘车码而得到的扫码数据、扫描所述乘车码的扫码时间和所述扫码机具所在的交通工具所属的交通线路，其中，所述乘车码和所述扫码数据中均携带有用户标识；

第一确定模块，用于根据所述扫码时间，确定与所述用户标识对应的目标用户的刷码位置和/或交通行程结束位置；

第二确定模块，用于将所述刷码位置与所述交通线路包括的多个站点进行位置匹配以确定所述目标用户的出发站点，和/或，将所述交通行程结束位置与所述交通线路包括的多个站点进行位置匹配以确定所述目标用户的下车站点。

一方面，提供一种服务器，所述服务器包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序指令执行上述各个方面所述的方法包括的步骤。

一方面，提供一种存储介质，该存储介质存储有计算机可执行指令，该计算机可执行指令用于使计算机执行上述各个方面所述的方法包括的步骤。

本发明实施例中，通过扫码乘车码得到的扫码数据和扫码时间来对确定目标用户的刷乘车码的刷码位置和/或下车位置，进而再将这两个位置与扫码机具所在的交通工具(例如公交车)所属的交通线路包括的多个站点位置进行匹配以最终确定出用户的上下车站点，也就是说，本发明实施例提供了一种在乘车码的交通场景下的配套检测用户上下车站点的检测方案，使得乘车码的交通场景进一步地广泛应用，增强了乘车码的适用性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为乘车码的展示界面示意图；

图2A为能够扫描乘车码的地铁闸机的示意图；

图2B为使用地铁闸机扫描手机中的乘车码的示意图；

图3为使用公交扫码枪扫描手机中的乘车码的示意图；

图4A为本发明实施例中的一种应用场景的示意图；

图4B为本发明实施例中的一种应用场景的示意图；

图5为本发明实施例中乘车码体系中各方数据的交互示意图；

图6为本发明实施例中的确定交通行程的方法的流程图；

图7为本发明实施例中的乘车码验证装置的结构框图；

图8为本发明实施例中的服务器的一种结构示意图；

图9为本发明实施例中的服务器的一种结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本发明的说明书和权利要求书及上述附图中的术语“第一”和“第二”是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的保护。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明实施例中，“多个”可以表示至少两个，例如可以是两个、三个或者更多个，本发明实施例不做限制。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，在不做特别说明的情况下，一般表示前后关联对象是一种“或”的关系。

以下对本文中涉及的部分用语进行说明，以便于本领域技术人员理解。

1、乘车码，用户用来乘坐公交或地铁等交通工具的二维码，在乘车码中可包含用户的身份标识(又称作用户标识)、时间戳(乘车码的生成时间)、安全证书、扣费账户等信息中的一种或多种信息。另外，乘车码中可以包括一个可扩展数据区，在该可扩展数据区中可以写入数据，进而实现乘车码的扩展应用。乘车码可以定时刷新，例如每间隔10秒刷新一次，通过不同的乘车码客户端生成的乘车码可以具有不同的刷新周期。

2、乘车码客户端，乘车码一般是依托于终端设备使用的，比如通过运行在终端设备中的乘车码客户端生成并展示乘车码，而乘车码客户端可以理解为是一个应用客户端，由于每个应用客户端可以对应一个应用服务器，所以不同的乘车码客户端可以分别对应不同的应用服务器。在实际中，乘车码客户端可以是一个独立的应用程序(Application，APP)，例如某地铁公司或某公交公司发布的专用于乘坐该地铁公司或该公交公司下辖的交通工具而使用的乘车码客户端，例如天府通、羊城通，等等，或者，乘车码客户端也可以是一个嵌入在现有的APP中的功能模块，例如目前的支付宝和微信均支持乘车码的使用，那么支付宝客户端和微信客户端也可以理解为是乘车码客户端，由于支付宝和微信的使用范围较广且用户群较大，所以通过这种方式来承载乘车码可以增加乘车码的普及率。

以微信客户端为例，其中的乘车码功能可以以小程序的方式嵌入在微信客户端中，通过内嵌小程序的方式可以节约流量，并且可以快速运行，当用户需要使用乘车码时，可以通过下拉微信主界面或者通过查找的方式找到乘车码小程序，进而进入到乘车码小程序的运行界面，然后调出乘车码的展示界面。以终端设备是手机为例，该手机中安装有乘车码客户端，当运行该乘车码客户端之后，此时乘车码的展示界面例如图1所示。

3、扫码机具，是指可以扫描乘车码以获得乘车码图像的设备，在某些情形下例如也可以称作扫码设备、扫码枪、验票机具、交通扫码设备，等等。扫码机具可以通过摄像头以扫码的方式得到乘车码的二维码图像。由于乘车码是以二维码图像的方式展示在终端设备(例如手机)中，当用户需要通过乘车码乘坐某种交通工具时，可以在手机中先调出乘车码，然后再将手机显示的乘车码对准扫码机具的摄像头，以使得扫码机具扫描得到乘车码的二维码图像。

在不同的交通场景下，扫码机具的设置方式可能不一样，为了便于理解，以目前使用较为广泛的公交交通场景和地铁交通场景举例说明。

在地铁交通场景下，扫码机具可以理解为地铁站中设置的地铁闸机，在进站口和出站口均设置有多个地铁闸机，此时的闸机不仅具备扫码的功能，同时还具备允许乘客是否能够通行的作用，为了支持多种支付方式，在地铁闸机中还可以集成有近场通信(NearField Communication，NFC)功能，通过NFC功能来感应识别常规的实体公交卡或者临时车票，同时还可以设置有车票投递口以便于回收临时车票，一种可能的地铁闸机例如图2A所示，以及用户使用地铁闸机的摄像头扫描手机中的乘车码的场景如图2B所示。

在公交交通场景下，扫码设备可以理解为公交车中设置的公交扫码枪，一般来说，公交扫码枪固定设置在公交车的前门处，以便乘客在上车后能够及时地刷码乘车，与地铁闸机类似的，公交扫码枪也可以支持实体公交车的刷卡方式，例如参见图3所示的用户使用手机向公交扫码枪刷乘车码的场景。在实际中，公交扫码枪和公交车可以具有一一对应的绑定关系，该绑定关系可以存储在公交后台服务器中，通过该绑定关系，只要知晓了公交扫码枪和公交车中的任意一方，就可以知晓另一方，例如公交扫码枪111是固定设置在川A88888这辆公交车中的，那么通过前述的绑定关系，就可以知晓川A88888这辆公交车中设置的公交扫码枪的编号是111，以及，也可以知晓公交扫码枪111是设置在川A88888这辆公交车中的，也就是说，所有的公交车中分别设置的公交扫码枪的对应关系可以预先存储在公交后台服务器中。另外，在目前的公交系统中，每辆公交车属于哪条公交线路也是可以公交后台调度配置，比如川A88888这辆公交车属于318路，川A77777这辆公交车属于122路，以及川A55555这辆公交车属于504路，等等，换言之，公交车和其所属的公交线路也具有对应关系，扫码机具、车辆标识(例如车牌号或者车辆编号)和公交线路这三者是相互关联的，只要知晓其中一个，就可以基于该关联关系知晓另外两者。另外，一般来说，一条公交线路会配置多辆公交车，该公交线路中的每辆公交车可以在所属的公交线路上进行上行或下行行驶。

4、乘车码图像，即乘车码的二维码图像，例如手机中生成并显示的乘车码的二维码图像，以及交通扫码设备通过摄像头扫描手机中展示的乘车码而获得的二维码图像。

5、交通量调查，又称OD调查，即交通起止点调查，又称OD交通量调查，OD交通量就是指起终点间的交通出行量。“O”来源于英文ORIGIN，指出行的出发地点，“D”来源于英文DESTINATION，指出行的目的地。

如前所述，随着乘车码越来越广泛的使用，针对乘车码这种新兴的智慧交通场景，需要提供一些配套的检测方案，例如前述提到的，在乘车码的交通场景下如何检测各个用户的上下车站点就是需要提供的一种配套检测方案，通过检测用户的上下车站点，可以对各个站点的交通流量进行统计等扩展应用，然而，目前对于乘车码的交通场景下如何确定用户的上下车站点还缺乏相应的检测方案。

鉴于此，本发明实施例提供一种确定交通行程的方法，用于对乘车码的交通场景下的用户的上下车站点进行检测，通过扫描乘车码得到的扫码数据和扫码时间来确定用户的刷乘车码的刷码位置和/或下车位置，进而再将这两个位置与扫码机具所在的交通工具(例如公交车)所属的交通线路包括的多个站点位置进行匹配以最终确定出用户的上下车站点，也就是说，本发明实施例提供了一种在乘车码的交通场景下的配套检测用户上下车站点的检测方案，增强了乘车码的交通场景进一步地广泛应用。

以下对本发明实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本发明实施例而非限定。在具体实施时，可以根据实际需要灵活地应用本发明实施例提供的技术方案。

请参见图4A所示的一种应用场景示意图，图4A所示的应用场景为通过乘车码乘坐公交车的场景为例进行说明，在该应用场景中包括公交车400、终端设备401、扫码机具402、乘车码服务器403和公交后台服务器404。其中，终端设备401是能够运行乘车码客户端的设备，如前面介绍的，例如可以运行支付宝客户端或者微信客户端，在支付宝客户端或微信客户端中可以直接使用乘车码，由于终端设备401中运行有乘车码客户端，所以与该乘车码客户端对应设置有一个乘车码服务器403，该乘车码服务器403可以是一个应用服务器，用于为运行在终端设备401中的乘车码客户端提供应用服务。扫码机具402安装在公交车400中，当用户携带终端设备401上车之后，可向扫码机具402展示终端设备401中的乘车码进行乘车。扫码机具402可通过网络向公交后台服务器404上传扫码数据和公交车400的车辆动态数据(例如公交车400的实时位置)，终端设备401可以通过网络向乘车码服务器403请求乘车码的相关服务请求，同时也可以向乘车码服务器403实时上报用户的位置数据，另外，乘车码服务器403和公交后台服务器404之间也可以进行后台通信，公交后台服务器404可以将公交车400和扫码机具402上报的数据推送给乘车码服务器403。

再参见图4B所示的另一应用场景示意图，相对于图4A来说，图4B中增加了公交管理平台405，乘车码服务器403在采用本发明实施例介绍的交通行程确定方法确定了用户的上下车站点之后，可以基于每个用户的上下车站点数据对多个站点的交通量进行交通流量统计，再将获得的交通流量统计结果推送给公交管理平台405，以使得公交管理平台405可以基于乘车码服务器403推送的统计数据对各条交通线路进行优化调整，等等。

再在另外一种应用场景中，公交后台服务器404还可以与支付平台保持通信连接，公交后台服务器404可以生成交通账单，再将生成的交通账单发送给支付平台以请求该支付平台对交通账单付费，也就是说，公交后台服务器404可以根据生成的交通账单向支付平台请款，以实现交通运营方和支付方的请款支付。在具体实施过程中，支付平台可以是与交通运营方(例如公交公司)合作的支付机构，支付平台例如是乘车码服务方自身开设的支付机构，以乘车码服务方是微信为例，那么支付平台可以是微信钱包，或者，支付平台也可以是与交通运营方具有合作关系的支付机构，例如可以是支付宝支付平台，或者可以是银联支付平台，或者还可以是其它的第三方支付平台，等等。

前述的终端设备401可以是手机、平板电脑、掌上电脑(Personal DigitalAssistant，PDA)，笔记本电脑、智能穿戴式设备(例如智能手表和智能头盔)、个人计算机等能够运行乘车码客户端的设备。以及，前述的乘车码服务器403、公交后台服务器404、公交管理平台405、支付平台均可以是个人计算机、大中型计算机、计算机集群，等等。

为进一步说明本发明实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本发明实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本发明实施例提供的执行顺序。所述方法在实际的处理过程中或者装置执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的应用环境)。

在介绍本发明实施例的方法流程之前，先结合图5把乘车码体系中各方数据的交互进行说明。

乘车码体系包括的角色有：交通运营方、乘车码服务方和用户方，也就是说，在整个乘车码体系中，涉及到交通运营方、乘车码服务方和用户这三个参与方。其中的交通运营方例如是地铁运营公司或公交运营公司，即能够提供交通服务的运营方；乘车码服务方是指能够提供乘车码服务的主体，例如在微信中使用乘车码，那么乘车码服务方即可理解为是微信的主体厂商，又例如在支付宝中使用乘车码，那么乘车码服务方即可理解为是支付宝的主体厂商，等等；而用户就是指利用终端设备使用乘车码的个体。终端设备中运行有乘车码客户端，乘车码客户端提供的所有乘车码相关的功能是由乘车码服务方提供的，所以，可以将乘车码服务方理解为是乘车码客户端的服务后台，在实际中，例如可以将乘车码服务方理解为是一个后台服务器，与此类似的，可以将交通运营方也理解为一个后台服务器，扫码机具是交通运营方提供的用于与用户之间进行交互的交互终端。请参见图5，图5中包括用户、乘车码客户端(例如是小程序方式运行)、乘车码后台、公交车、设置于公交车内的扫码机具以及公交后台。其中的用户即可代表前述的用户方，乘车码客户端和乘车码后台可代表前述的乘车码服务方，公交车、扫码机具和公交后台可代表前述的交通运营方。

用户可使用终端设备中的乘车码客户端展示乘车码，以将乘车码图像提供给公交车中的扫码机具，扫码机具在扫码得到乘车码图像之后可以对乘车码图像进行解析，进而得到扫码数据，在本发明实施例中，乘车码中携带有用户标识，用户标识又称作用户ID，用户标识具有唯一性，即一个用户标识唯一表示一个用户，在实际中，乘车码中还可以携带乘车码的生成时间、安全证书、支付账户等信息。扫码机具在扫描得到乘车码图像之后，可以记录扫描该乘车码图像的扫码时间，然后将扫码时间、扫码数据和扫码机具的机具标识(例如扫码机具的编号)一起上报给公交后台。

公交后台中存储有公交绑定关系和线路站点数据，该公交绑定关系和线路站点数据可以是预先存储在公交后台中的，通过这些预存的数据，公交后台可以对各辆公交车进行线路调度和调整。

其中，公交绑定关系是指扫码机具、交通工具(例如公交车)和交通线路(例如公交线路)之间的关联关系，例如表1所示的公交绑定关系示例，表1示出了公交线路318与三辆车和三个扫码机具之间的绑定关系，所以，通过图1所示，可知车辆编号为川A88888的公交车所属的交通线路是318，以及绑定设置在该公交车中的扫码机具的编号Aaa1。当然，本发明实施例中的公交绑定关系可以更改，具体来说，可以由公交调度机构进行更改，例如在线路318所配置的公交车辆过多的情形下，可以将川A 67895这辆公交车再重新配置为其它公交线路(例如703路)使用。

表1.

线路编号	车辆编号	扫码机具编号
			318	川A 88888	Aaa1
318	川A 67895	Aaa2
			318	川A 34567	Aaa3

线路站点数据，可以包括每条交通线路所包括的站点，包括各个站点的名称和地理位置，其中的地理位置具体可以由经度和纬度表示。并且，通过线路站点数据，还可以获知每条交通线路的上行线路和下行线路，例如对于702这条公交线路来说，假设其两个终点站是A站和F站，可以将由A站开往F站的线路称作上行线路，以及可以将由F站开往A站的线路称作下行线路，上行线路和下行线路分别所包括的站点名称可能相同，但是对应的站点的地理位置一般是存在较大差别的，比如，在公交线路702中的上行线路中，A站位于某道路的右侧的某个位置，而在公交线路702中的下行线路中，A站则可能位于该道路的左侧的某个位置。请参见表2所示的公交线路318的一部分线路站点数据。

表2.

线路编号	方向	序号	站点名称	经度	纬度
						318	上行	1	文化宫	120.3333	29.9999
318	上行	2	会展中心	124.2222	30.5555
						318	上行	3	希望路口	129.6666	32.1111

公交后台在获得扫码机具上传的扫码数据、扫码时间和扫码机具的编号之后，可以通过扫码机具的编号从预存的公交绑定关系中查找到对应的车辆编号和线路编号。例如表3所示的，公交后台存储的用户123456和用户123457这两个用户的扫码时间和对应的车辆编号和线路编号。

表3.

用户ID	扫码时间	车辆编号	线路编号
				123456	09:02:34	川A 88888	318
123457	09:02:45	川A 88888	318

进一步地，在获得用户的扫码数据之后，公交后台可以根据得到的扫码数据生成用户的消费数据，进而可以基于该消费数据生成交通账单，然后可以通过该交通账单向支付平台请款，一种可能的实施方式是，公交后台将交通账单直接发送给乘车码后台进行请款付费。

在本发明实施例中，公交车可以将自身的位置(例如在行驶过程中的多个行驶位置)实时动态地上报给公交后台，那么，首先，公交车需要先获取自身的车辆位置数据，例如可以通过GPS模块来采集获得车辆位置数据，然后再将采集到的车辆位置数据动态地上报给公交后台，公交后台可以根据公交车上报的车辆位置数据对应得到该公交车的车辆动态数据，例如车辆动态数据就为车辆位置数据，或者，车辆动态数据除了包括车辆位置数据之外，还可以包括车辆的其它动态信息。在具体实施过程中，前述的GPS模块可以集成在扫码机具中，或者也可以独立于扫码机具设置于公交车的其它位置。请参见表4所示的，川A88888这辆公交车向公交后台上报的部分车辆位置数据。

表4.

车辆编号	上报时间	经度	纬度
				川A 88888	09:10:55	120.3456	29.4566
川A 88888	09:11:55	121.2345	28.9879
				川A 88888	09:12:55	121.8986	28.2354

在本发明实施例中，终端设备也可以将用户的位置实时上报给乘车码后台，具体来说可以通过终端设备中集成的全球定位系统(Global Positioning System，GPS)模块先获得用户位置数据，然后再将获得的用户位置数据进行上报。请参见表5所示的，终端设备向公交设备上报的用户123456的部分用户位置数据。

表5.

用户ID	上报时间	经度	纬度
				123456	09:10:55	120.3458	29.4568
123456	09:11:55	121.2349	28.9888
				123456	09:12:55	121.8996	28.2359

在具体实施过程中，扫码机具可以在公交车的工作时间段内均向公交后台上报车辆位置数据，以便于公交后台对各个车辆进行实时的监控和调度。而对于用户来说，因为使用乘车码搭乘公交车一般是在上车时候刷一次乘车码即可，终端设备可以在上次刷码之后即可向乘车码后台上报用户位置数据，以便于后续能够根据该用户位置数据来计算用户的下车站点。在具体实施过程中，在乘车码后台获得用户的扫码数据之后，为了后续根据用户位置数据进行下车站点的计算，所以乘车码后台可以向终端设备发送位置上报指示，以通过该位置上报指示来指示终端设备上报用户位置数据，本发明实施例中所说的用户位置数据包括位置(例如经度和纬度)以及上报每个用户位置的上报之间，上报每个用户位置的上报时间也即是获取所述用户位置的时间，类似的，车辆位置数据亦是如此，位置与上报时间是对应的。进一步地，当乘车码后台计算出用户的下车站点之后，即可以确定用户已经下车，此时为了节约终端设备的功耗，乘车码后台还可以向终端设备再发送停止上报指示，以指示终端设备停止继续上报用户位置，或者在另一种实施方式中，终端设备在接收到乘车码后台发送的位置上报指示后的预定时长内即可自动停止上报，该预定时长例如是一般的公交车一个上行线路或下行线路的总时长，例如是2小时，因为在2小时候，用户很大可能已经下车，所以也可估计后自动停止上报。

另外，需要说明的是，无论是终端设备上报的用户位置数据，还是公交车上报的车辆位置数据，均可以按照一定的上报周期进行上报，例如每间隔20秒上报一次，或者每间隔30秒上报一次，本发明实施例对于上报的周期不做限制。例外，终端设备和公交车上报的周期可以相同或者也可以不同，并且，这两者分别上报的起始点可以相同或者也可以不同，在上报周期不是很大(即上报间隔比较频繁)的情形下，可以近似认为两者的上报时间大约相等，即终端设备上报一次用户位置的上报时间和公交车上报一次车辆位置的上报时间可以认为近似相同。

另外，由于公交后台和乘车码后台可以进行后台交互，所以公交后台获得的车辆位置数据可以推送给乘车码后台，或者乘车码后台可以定时从公交后台拉取需要的数据。

以上结合图5介绍了乘车码体系中的各方的交互情况之后，以下再结合图6对本发明实施例中的确定交通行程的方法进行说明，图6所示的方法流程可以由前述的乘车码后台(乘车码服务器)执行。可以理解的是，图6所示的方法流程也可以由前述的公交后台(即公交后台服务器)执行，或者由乘车码后台与公交后台共同执行。

步骤601、获得扫码数据、扫码时间和交通线路。

也就是说，乘车码后台可以获得扫码机具扫描终端设备中的乘车码而得到的扫码数据、扫码机具扫描乘车码的扫码时间和扫码机具所在的交通工具所属的交通线路，并且，乘车码和扫码数据中均携带有用户标识，该用户标识对应某个特定的用户，为了便于描述，本发明实施例中将该特定的用户称作目标用户。

在获得了这些数据之后，乘车码后台可以根据扫码时间确定目标用户的刷码位置，同时也可以确定交通行程结束位置。其中，刷码位置，即是用户向扫码机具刷乘车码时用户所处的位置，由于用户是处于公交车内的，所以此时用户的刷码位置也可以认为是公交车所在的位置，而交通行程结束位置是指用户本次交通行程结束的位置，对于搭乘公交车来说，那么即是完成本次乘坐公交车时的位置，即可以认为是用户的下车位置。

进一步地，在获得了刷码位置之后，可以将刷码位置与确定的交通线路包括的多个站点进行位置匹配以确定目标用户的出发站点，同理，也可将交通行程结束位置与交通线路包括的多个站点进行位置匹配以确定目标用户的下车站点，从而完成用户的上下车站点的检测。

为了便于理解，以下分别从上车站点匹配和下车站点匹配两方面来说明上车站点(出发站点)和下车站点的确定过程。继续结合图6来说，步骤602-步骤606为上车站点匹配的过程，步骤607-步骤615为下车站点匹配的过程。

一、上车站点匹配。

步骤602：根据扫码时间，匹配出用户在扫码时间对应的刷码位置。

一种可能的实施方式中，扫码机具在上报扫码数据和扫码时间的时候，就同步上报了扫码机具在扫码时公交车的行驶位置，因为用户是在公交车内的扫码机具前进行扫码的，所以在扫码时间时，公交车的位置和用户的位置可以认为是近似一样的，在该种情况下，则可以直接将上报的在扫码时间时公交车的行驶位置直接确定为用户的刷码位置。

在另一种可能的实施方式中，可以从第一时间组或第二时间组中确定与扫码时间最接近的目标时间，并将与该目标时间对应的目标用户位置或目标行驶位置确定为用户的刷码位置，其中，第一时间组包括终端设备上报若干个用户位置对应的若干个上报时间，第二时间组包括上报交通工具的若干个行驶位置对应的若干个上报时间。

也就是说，公交车可以上报车辆位置数据，由于车辆位置数据包括多个位置及上报每个位置的上报时间，上报每个位置的上报时间也即是获取所述位置的时间，所以可以先从多个上报时间中找到与扫码时间最接近的上报时间，然后再把该最接近的上报时间对应的车辆位置作为用户的刷码位置。类似的，终端设备也可以上报用户位置数据，进而可以先从上报用户位置的多个上报时间中找到与扫码时间最接近的上报时间，然后再把该最接近的上报时间对应的用户位置作为用户的刷码位置。

步骤603：在获得了用户的刷码位置之后，可以再判断刷码位置的数据是否有效。

在具体实施中，刷码位置可以以经度和纬度表示，一种判断方式是，可以判断得到的经度和纬度是否明显是不属于经纬度的数据，若不属于的话则可以认为是无效的数据，另一种判断方式是，可以判断得到的经度和纬度的精度是否明显偏差过大，若偏差明显过大的话，则也可以认为是无效数据。

步骤604：在确定刷码位置的数据有效之后，则可以从步骤601中获得的交通线路包括的多个站点对应的多个站点位置中进行位置的距离匹配，以从多个站点位置中查找出与用户的刷码位置距离最近的第一目标站点位置。

步骤605：再将确定出的第一目标站点位置对应的站点确定为用户的上车站点。

步骤606：进一步地，乘车码后台可以存储用户的上车站点。

对于上述上车站点的匹配过程，还可以按照以下流程理解：

首先，乘车码后台获得用户的扫码数据，具体来说是获得扫码数据中的用户标识，进而可以根据该用户标识确定出当前是对哪一个用户(即目标用户)的行程进行检测，并且同时可以获得扫码机具扫描目标用户展示的乘车码的扫码时间，以及该扫码机具所在的车辆的车辆编号和对应线路编号。

然后，再根据扫码时间来确定目标用户扫码时的位置，即刷码位置，例如确定出的刷码位置是位置A(am，an)，其中的am表示位置A处对应的经度值，以及an表示位置A处对应的纬度值，后面类似的表述亦如此理解。

最后，根据线路站点近似匹配的方式来计算上车站点。例如，前面确定出的线路中的多个站点位置中的位置B(bm，bn)是最接近位置A(am，an)，那么则可以将位置B对应的站点确定为是目标用户的上车站点。

上述介绍了上车站点的匹配过程，上车站点是OD调查的先决条件，换言之，只有准确的计算出用户的上车站点，才能准确的检测出用户的实际交通行程，提高交通行程检测的完整性和准确性。本发明实施例中，通过乘车码的扫码时间即可准确的确定出用户的刷码位置，进而匹配出用户的上车站点，在充分考虑乘车码的交通场景下的，实现了上车站点的准确匹配。

二、下车站点匹配。

在现有的公交体系中，大多数情况下是全程单一计费，所以乘客只需要在上车的时候刷一次乘车码即可，在需要下车时直接下车，而无需再刷一次乘车码，由于在下车时不再刷乘车码，所以自然也就无法将扫码时间对应的车辆位置或用户位置作为用户的下车位置了。鉴于此，本发明实施例提供另外一种匹配方式来计算用户的下车位置(即交通行程结束位置)，具体来说，即是根据在用户刷码之后的车辆位置数据和用户位置数据来地对车辆和用户的相对位置动态地进行计算，若人车之间的距离达到一定值(例如100米或500米)之后即说明人车已经分离，那么此时则可以认为用户已经下车，进而再根据用户的下车位置通过线路近似匹配的方式来匹配出用户的下车站点。为了便于理解，以下结合步骤607-步骤615进行说明。

步骤607：获得在扫码时间之后的用户位置数据和车辆位置数据。

参照图5对应实施例的介绍，用户位置数据可以是由终端设备直接上报给乘车码后台的，而车辆位置数据可以是由车辆上报给公交后台后再由公交后台推送或者由乘车码后台从公交后台处请求拉取获得的。其中的用户位置数据包括多个用户位置以及每个用户位置的上报时间，车辆位置数据也包括多个车辆位置以及每个车辆位置的上报时间，上报每个位置的上报时间也即是获取所述位置的时间，例如将用户位置的多个上报时间以第一时间组表示，以及将车辆位置的多个上报时间以第二时间组表示。例如请参见表4所示的车辆川A 88888的部分车辆位置数据，以及表5所示的用户123456的部分用户位置数据，可见车辆川A 88888和用户123456上报自身位置的上报周期相同，均是1分钟，并且这两者上报各自位置的上报时间(可以认为是上报开始时刻)也相同，这样的话，通过相同的上报时刻可以更为准确的判定在某个时刻用户和车的相对位置关系。

步骤608：判断用户位置数据是否有效。

步骤609：判断车辆位置数据是否有效。

也就是说，针对获得用户位置数据和车辆位置数据还需要进行有效性的检查，只有有效的数据才能进入后续的计算流程，确保位置计算的有效性，具体的检查方式前述已有说明，此处就不再重复介绍了。

步骤610：根据用户位置数据和车辆位置数据，进行人车距离计算。

步骤611：例如，可以判断人车距离是否连续3次大于200米。

步骤612：若人车距离已经连续3次大于200米，即可确定用户已下车。

也就是说，在扫码时间之后，乘车码后台可以确定第一时间组中连续的M个第一时间对应的M个用户位置与第二时间组中连续的M个第二时间对应的M个行驶位置之间对应的位置偏差是否均大于等于预定距离，结合到图6中的例子，此时的M为3，而预定距离为200米，当然，这里的连续次数设置为3和预定距离为200米都仅是举例的参考值，在具体实施过程中，可以根据实际的应用场景对这些参考值进行调整，例如可以将M设置为2，以及可以将预定距离设置为300米，等等。

继续以表4和表5进行举例说明，表5中的三个用户位置的上报时间可以理解为是第一时间组，表4中的三个车辆位置的上报时间可以理解为是第二时间组，表4中连续的三个上报时间与表5中连续的三个上报时间相同，那么则可以分别将相同上报时间对应的用户位置和车辆位置进行差值计算，并根据差值与预定距离之间的大小来确定人车是否已经分离，若差值大于预定距离，则认为人车已经分离，若差值不大于预定距离，则可认为人车还未分离。其中，以连续多次的方式来进行判定，是为了避免一次判定可能造成的判定失误，所以通过连续多次的方式可以提高判断的准确性。

例如，用户位置以A(am，an)表示，车辆位置以C(cm，cn)表示，那么表4中任一组经纬度即可以C(cmi，cni)，其中的i表示位置的数量，按照该表示方式，例如表4中车辆连续的三个经纬度可以C(cm1，cn1)、C(cm2，cn2)、C(cm3，cn3)表示，类似地，表5中用户连续的三个经纬度可以A(am1，an1)、A(am2，an2)、A(am3，an3)表示。

分别计算A(am1，an1)与C(cm1，cn1)、A(am2，an2)与C(cm2，cn2)、A(am3，an3)与C(cm3，cn3)之间的差值的绝对值，例如这三个绝对值以Δ1、Δ2和Δ3表示，若Δ1、Δ2和Δ3均大于200米，则可以认为人车已经分离，具体到表4和表5来说，对应的三组位置均相差甚小，可以认为用户和车辆的位置是近似相同的，所以通过计算，Δ1、Δ2和Δ3均小于200米，所以此时可以认为人车并未分离。若在其它的实施例中，Δ1、Δ2和Δ3均大于200米，那么此时可以认为人车已经分离，即表明用户已经下车。

步骤613：在确定用户已经下车之后，可确定用户的交通行程结束位置，即确定用户的下车位置。

继续前述例子，若Δ1、Δ2和Δ3均大于200，那么可以根据对应计算Δ1、Δ2和Δ3的三个用户位置或者三个车辆位置来确定用户的下车位置。以三个用户位置为例，可以取其中最后一次的用户位置作为用户的下车位置，或者可以取三个用户位置的平均位置作为用户的下车位置。由于在刚下车时车辆可能由于停靠会有一定时间的停留，或者车辆在用户刚下车后的行驶速度一般较小，所以也可以通过车辆位置来近似表示用户的下车位置，例如也可以将最后一次的车辆位置或者平均车辆位置作为用户的下车位置。

步骤614：从交通线路包括的多个站点对应的多个站点位置中，查找与交通行程结束位置距离最近的第二目标站点位置，并将该第二目标站点位置对应的站点确定为用户的下车站点。

该步骤与前述介绍的上车站点中确定第一目标站点位置的过程是类似的，该步骤的具体实施可以参见前述的介绍，此处就不再重复说明了。

步骤615：存储用户下车站点。

进一步地，在确定了用户的下车站点之后，也可以将用户的下车站点进行存储。

上述介绍了下车站点的匹配方式，提供了一种在用户下车时未刷码的情形下的确定用户的下车站点的方式，完善了乘车码应用过程中的上下车站点的匹配检测方案，进而可以增强乘车码的适用性，也便于乘车码推广。

在本发明实施例中，无论是上车站点匹配还是下车站点匹配，均需要利用到车辆所属的交通线路，如前所述的，在实际中，一条交通线路包括上行线路和下行线路，而一般来说，上行线路和下行线路分别包括的多个站点对应的站点位置是不同的，所以为了提高对用户的刷码位置和下车位置匹配的准确性，在确定交通线路的时候，需要准确的知晓当前的运行线路到底是上行线路还是下行线路。在一种可能的实施方式中，可以先获得车辆在本次交通行程中已经行驶过的站点，并且可以根据已经行驶过的站点的顺序来判定到底是上行线路还是下行线路，进而提高最终的站点匹配的准确性。

前面介绍的是对一个用户的一次交通行程的上下车站点进行匹配的方式，对于该用户的其它交通行程的匹配也可以再采用相同的方式，以及，对于其他用户的交通行程的匹配也可以采用相同的方式。对于乘车码后台来说，通过前述介绍的方式可以获得多个用户的多次交通行程的上下车站点的匹配，那么针对某个站点(可以是上车站点也可以是下车站点)来说，乘车码后台就可以对该站点的交通量进行统计，进而获得各个站点的交通量统计数据，进一步地，乘车码后台可以将统计的这些数据发送给交通管理平台，以使得交通管理根据这些统计数据对交通线路进行优化调整，比如，对于某些设置的比较密集的站点，但是交通量如果较小的话则可以适度的减少站点的数量以节约资源，等等。另外，交通管理平台还可以根据获得的交通量统计数据进行预警提示，例如，若确定某个站点的交通量特别大，那么则可以在该站点进行人群引导、疏散等安全措施，还可以对用户进行相应的安全预警提示，以尽量确保人员安全。

在另外一些可能的应用中，在确定了用户的下车站点之后，乘车码后台还可以将匹配的站点数据推送给其它的应用服务器，以使的其它的应用服务器能够及时地对处于某个下车站点的用户进行应用推广，例如推送一些打折促销广告、餐饮酒店广告、景点介绍等相关信息，以实现精准营销。

基于同一发明构思，本发明实施例提供的一种确定交通行程的装置，该确定交通行程的装置例如可以是前述的乘车码服务器，也可以是前述的公交后台服务器，该确定交通行程的装置能够实现前述的确定交通行程的方法中乘车码服务器或公交后台服务器的功能；或者，该乘车码服务器也可以是能够支持乘车码服务器实现前述的确定交通行程的方法中乘车码服务器或乘车码后台的功能的装置。该确定交通行程的装置可以是硬件结构、软件模块、或硬件结构加软件模块。该确定交通行程的装置可以由芯片系统实现，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。请参见图7所示，本发明实施例提供的确定交通行程的装置包括获得模块701、第一确定模块702和第二确定模块703，其中：

获得模块701，用于获得扫码机具扫描终端设备中的乘车码而得到的扫码数据、扫描乘车码的扫码时间和扫码机具所在的交通工具所属的交通线路，其中，乘车码和扫码数据中均携带有用户标识；

第一确定模块702，用于根据扫码时间，确定与用户标识对应的目标用户的刷码位置和/或交通行程结束位置；

第二确定模块703，用于将刷码位置与交通线路包括的多个站点进行位置匹配以确定目标用户的出发站点，和/或，将交通行程结束位置与交通线路包括的多个站点进行位置匹配以确定目标用户的下车站点。

可选的，第一确定模块702，用于将扫码机具上报的在扫码时间时交通工具的行驶位置确定为刷码位置；或者，从第一时间组或第二时间组中确定与扫码时间最接近的目标时间，并将与目标时间对应的目标用户位置或目标行驶位置确定为刷码位置，其中，第一时间组包括终端设备上报的若干个用户位置对应的若干个上报时间，第二时间组包括上报的交通工具的若干个行驶位置对应的若干个上报时间。

可选的，第一确定模块702，用于从交通线路包括的多个站点分别对应的站点位置中，确定与刷码位置距离最近的第一目标站点位置；并将第一目标站点位置对应的站点确定为出发站点。

可选的，第一确定模块702，用于在扫码时间之后，确定第一时间组中连续的M个第一时间对应的M个用户位置与第二时间组中连续的M个第二时间对应的M个行驶位置之间对应的位置偏差均大于等于预定距离，其中，第一时间组包括终端设备上报的若干个用户位置对应的若干个上报时间，第二时间组包括上报的交通工具的若干个行驶位置对应的若干个上报时间，M为正整数；并根据M个用户位置或M个行驶位置确定交通行程结束位置。

可选的，第一确定模块702，用于从交通线路包括的多个站点分别对应的站点位置中，确定与交通行程结束位置距离最近的第二目标站点位置；再将第二目标站点位置对应的站点确定为下车站点。

可选的，本发明实施例中的确定交通行程的装置还包括发送模块，用于在获得扫码数据、扫码时间和交通线路之后，基于用户标识向终端设备发送位置上报指示，以指示终端设备上报多个用户位置与每个用户位置对应的上报时间；和/或，在确定下车站点之后，基于用户标识向终端设备发送停止上报指示，以指示终端设备停止继续上报用户位置。

可选的，本发明实施例中的确定交通行程的装置还包括第三确定模块，用获得交通工具在本次交通行程中已经行驶过的站点；并根据已经行驶过的站点的顺序，确定交通线路是上行线路或者是下行线路，其中，上行线路与下行线路分别包括的多个站点对应的站点位置不同。

可选的，本发明实施例中的确定交通行程的装置还包括统计模块，用于统计在出发站点和/或下车站点的交通量，获得交通量统计数据；并将交通量统计数据发送给交通管理平台，以使交通管理平台根据交通量统计数据对交通线路进行优化调整。

前述的确定交通行程的方法的实施例涉及的各步骤的所有相关内容均可以援引到本申请实施例中的确定交通行程的装置所对应的功能模块的功能描述，在此不再赘述。

本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本发明各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

基于同一发明构思，本发明实施例还提供一种服务器，该服务器可以是计算设备，该服务器例如是图4A-图4B中的乘车码服务器403或者公交后台服务器404，或者可以是图5中的乘车码后台或公交后台，如图8所示，本发明实施例中的服务器包括至少一个处理器801，以及与至少一个处理器连接的存储器802，本发明实施例中不限定处理器801与存储器802之间的具体连接介质，图8中是以处理器801和存储器802之间通过总线800连接为例，总线800在图8中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线800可以分为地址总线、数据总线、控制总线等，为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

在本发明实施例中，存储器802存储有可被至少一个处理器801执行的指令，至少一个处理器801通过执行存储器802存储的指令，可以执行前述的确定交通行程的方法中所包括的步骤。

其中，处理器801是服务器的控制中心，可以利用各种接口和线路连接整个终端设备的各个部分，通过运行或执行存储在存储器802内的指令以及调用存储在存储器802内的数据，服务器的各种功能和处理数据，从而对该服务器进行整体监控。可选的，处理器801可包括一个或多个处理单元，处理器801可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器801中。在一些实施例中，处理器801和存储器802可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器801可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本发明实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器802作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器802可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、RAM、SRAM、PROM、ROM、EEPROM、磁性存储器、磁盘、光盘等等。存储器802是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本发明实施例中的存储器802还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

通信接口803是能够用于进行通信的传输接口，例如可以通过通信接口803接收数据或者发送数据。

参见图9所示的服务器的进一步地的结构示意图，该服务器还包括帮助服务器内的各个器件之间传输信息的基本输入/输出系统(I/O系统)901、用于存储操作系统902、应用程序903和其他程序模块904的大容量存储设备905。

基本输入/输出系统901包括有用于显示信息的显示器906和用于用户输入信息的诸如鼠标、键盘之类的输入设备907。其中显示器906和输入设备907都通过连接到系统总线800的基本输入/输出系统901连接到处理器801。所述基本输入/输出系统901还可以包括输入输出控制器以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备905通过连接到系统总线800的大容量存储控制器(未示出)连接到处理器801。所述大容量存储设备905及其相关联的计算机可读介质为该服务器包提供非易失性存储。也就是说，大容量存储设备905可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。

根据本申请的各种实施例，该服务器包还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即该服务器可以通过连接在所述系统总线800上的通信接口803连接到网络908，或者说，也可以使用通信接口803来连接到其他类型的网络或远程计算机系统(未示出)。

基于同一发明构思，本发明实施例还提供一种确定交通行程的装置，该确定交通行程的装置包括至少一个处理器及可读存储介质，当该可读存储介质中包括的指令被该至少一个处理器执行时，可以执行如前述的确定交通行程的方法的步骤。

基于同一发明构思，本发明实施例还提供一种芯片系统，该芯片系统包括处理器，还可以包括存储器，用于实现如前述的确定交通行程的方法的步骤。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

在一些可能的实施方式中，本发明提供的确定交通行程的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机上运行时，该程序代码可以用于使计算机执行前文述描述的根据本发明各种示例性实施方式的确定交通行程的方法中的步骤。

基于同一发明构思，本发明实施例还提供一种确定交通行程的装置，该确定交通行程的装置包括：存储器，用于存储程序指令；处理器，用于调用该存储器中存储的程序指令，按照获得的程序指令执行前文述描述的根据本发明各种示例性实施方式的确定交通行程的方法中的步骤。

基于同一发明构思，本发明实施例还提供一种存储介质，该存储介质存储有计算机可执行指令，该计算机可执行指令用于使计算机执行前文述描述的根据本发明各种示例性实施方式的确定交通行程的方法中的步骤。

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

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

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

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

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (11)

1.一种确定交通行程的方法，其特征在于，所述方法包括：

获得扫码机具扫描终端设备中的乘车码而得到的扫码数据、扫描所述乘车码的扫码时间和所述扫码机具所在的交通工具所属的交通线路，其中，所述乘车码和所述扫码数据中均携带有用户标识；

根据所述扫码时间，确定与所述用户标识对应的目标用户的刷码位置和/或交通行程结束位置；

将所述刷码位置与所述交通线路包括的多个站点进行位置匹配以确定所述目标用户的出发站点，和/或，将所述交通行程结束位置与所述交通线路包括的多个站点进行位置匹配以确定所述目标用户的下车站点。

2.如权利要求1所述的方法，其特征在于，根据所述扫码时间，确定与所述用户标识对应的目标用户的刷码位置，包括：

将所述扫码机具上报的在所述扫码时间时所述交通工具的行驶位置确定为所述刷码位置；或者，

从第一时间组或第二时间组中确定与所述扫码时间最接近的目标时间，并将与所述目标时间对应的目标用户位置或目标行驶位置确定为所述刷码位置，其中，所述第一时间组包括所述终端设备上报的若干个用户位置对应的若干个上报时间，所述第二时间组包括上报的所述交通工具的若干个行驶位置对应的若干个上报时间。

3.如权利要求2所述的方法，其特征在于，将所述刷码位置与所述交通线路包括的多个站点进行位置匹配以确定所述目标用户的出发站点，包括：

从所述交通线路包括的多个站点分别对应的站点位置中，确定与所述刷码位置距离最近的第一目标站点位置；

将所述第一目标站点位置对应的站点确定为所述出发站点。

4.如权利要求1所述的方法，其特征在于，根据所述扫码时间，确定与所述用户标识对应的目标用户的交通行程结束位置，包括：

在所述扫码时间之后，确定第一时间组中连续的M个第一时间对应的M个用户位置与第二时间组中连续的M个第二时间对应的M个行驶位置之间的位置偏差均大于等于预定距离，其中，所述第一时间组包括所述终端设备上报若干个用户位置对应的若干个上报时间，所述第二时间组包括上报所述交通工具的若干个行驶位置对应的若干个上报时间，M为正整数；

根据所述M个用户位置或所述M个行驶位置确定所述交通行程结束位置。

5.如权利要求4所述的方法，其特征在于，将所述交通行程结束位置与所述交通线路包括的多个站点进行位置匹配以确定所述目标用户的下车站点，包括：

从所述交通线路包括的多个站点分别对应的站点位置中，确定与所述交通行程结束位置距离最近的第二目标站点位置；

将所述第二目标站点位置对应的站点确定为所述下车站点。

6.如权利要求4所述的方法，其特征在于，所述方法还包括：

在获得所述扫码数据、所述扫码时间和所述交通线路之后，基于所述用户标识向所述终端设备发送位置上报指示，以指示所述终端设备上报所述多个用户位置与每个用户位置对应的上报时间；和/或，

在确定所述下车站点之后，基于所述用户标识向所述终端设备发送停止上报指示，以指示所述终端设备停止继续上报用户位置。

7.如权利要求1-6任一所述的方法，其特征在于，所述方法还包括：

获得所述交通工具在本次交通行程中已经行驶过的站点；

根据已经行驶过的站点的顺序，确定所述交通线路是上行线路或者是下行线路，其中，上行线路与下行线路分别包括的多个站点对应的站点位置不同。

8.如权利要求1-6任一所述的方法，其特征在于，所述方法还包括：

统计在所述出发站点和/或所述下车站点的交通量，获得交通量统计数据；

将所述交通量统计数据发送给交通管理平台，以使所述交通管理平台根据所述交通量统计数据对所述交通线路进行优化调整。

9.一种确定交通行程的装置，其特征在于，所述装置包括：

获得模块，用于获得扫码机具扫描终端设备中的乘车码而得到的扫码数据、扫描所述乘车码的扫码时间和所述扫码机具所在的交通工具所属的交通线路，其中，所述乘车码和所述扫码数据中均携带有用户标识；

第一确定模块，用于根据所述扫码时间，确定与所述用户标识对应的目标用户的刷码位置和/或交通行程结束位置；

第二确定模块，用于将所述刷码位置与所述交通线路包括的多个站点进行位置匹配以确定所述目标用户的出发站点，和/或，将所述交通行程结束位置与所述交通线路包括的多个站点进行位置匹配以确定所述目标用户的下车站点。

10.一种服务器，其特征在于，所述服务器包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序指令执行权利要求1-8任一所述的方法包括的步骤。

11.一种存储介质，其特征在于，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行权利要求1-8任一所述的方法包括的步骤。

Images