具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明的说明书和权利要求书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象,而不是用于描述特定顺序。此外,术语“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
在本文中提及“实施例”意味着,结合实施例描述的特定特征、结果或特性可以包含在本发明的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例,也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本文所描述的实施例可以与其它实施例相结合。
参阅图1,图1提供了一种终端,该终端可以为IOS、安卓等系统的终端,当然也可以为其他系统的终端,例如鸿蒙等等,本申请并不限制上述具体的系统,如图1所示,上述终端设备具体可以包括:处理器、存储器、显示屏、通信电路、音频组件(可选的)和摄像头(可选的),上述部件可以通过总线连接,也可以通过其他方式连接,本申请并不限制上述连接的具体方式。
地铁、公交、的士均属于公共交通,随着碳排放的要求越来越高,用户绿色出行越来越成为主流。随着大数据平台对公交数据进行处理,使得智慧城市的公交数据能够被有效数据,但是现有的智慧城市的公交数据量过大,因此导致智慧城市的公交数据的存储量过大,提高了数据处理成本。
参阅图2,图2提供了一种基于大数据平台的智慧城市数据处理方法,该方法如图2所示,该方法可以在如图1所示的终端完成,该终端具体可以为计算机设备、智能手机等等,上述方法包括如下步骤:
步骤S201、终端采集用户A的当前公交出行数据,该当前公交出行数据包括:公交轨迹和轨迹时间段;
示例的,上述公交轨迹具体可以包括:车号、上车站和下车站;上述轨迹时间段包括:上车时间和下车时间。示例的,上述车号可以包括:地面公交的车号,也可以包括轨道交通的线路号,本申请并不限制上述车号的具体表现形式,只需要其属于公共交通即可。
步骤S202、终端将该当前公交出行数据与用户A的历史公交出行数据进行比对确定是否具有相似的公交出行数据;
示例的,上述步骤S202的实现方法具体可以包括:
终端将当前公交出行数据中的第一公交轨迹与历史公交出行数据的公交轨迹进行一致性比对,若历史公交出行数据中具有与第一公交轨迹的车号、上车站和下车站完全一致的第二公交轨迹,获取第二公交轨迹的第二轨迹时间段,若第二轨迹时间段与第一公交轨迹对应的第一轨迹时间段具有重叠时间段且第一公交轨迹与第二公交轨迹完全一致,确定当前公交出行数据与第二公交轨迹对应的第二公交出行数据近似,否则确定不近似。
步骤S203、若具有相似的公交出行数据,终端将相似的两个公交出行数据合并成一个得到合并公交出行数据后存储。
示例的,上述步骤S203的实现方法具体可以包括:
将相似的两个公交出行数据的两个公交轨迹合并成一个得到合并公交轨迹,若两个轨迹时间段完全相同,则将两个完全相同的轨迹时间段合并成一个得到合并轨迹时间段,将该合并公交轨迹和合并轨迹时间段确定为合并公交出行数据,若两个轨迹时间段不完全相同,将该合并公交轨迹和两个轨迹时间段确定为合并公交出行数据。
本申请提供的技术方案终端采集用户A的当前公交出行数据,该当前公交出行数据包括:公交轨迹和轨迹时间段,终端将该当前公交出行数据与用户A的历史公交出行数据进行比对确定是否具有相似的公交出行数据,若具有相似的公交出行数据,终端将相似的两个公交出行数据合并成一个得到合并公交出行数据后存储。本申请的技术方案将公交轨迹的数据进行合并后存储,这样即能够对公交出行数据进行有效的还原,又能够减少数据的存储量,减少数据的存储成本。
对于公交出行数据,尤其是对于用户A来说,其大部分的公交出行数据应该均是相似的,例如用户A从家到公司,由于家地址和公司的地址在很长一个时间段均是固定的,那么用户A从家到公司的公交出行数据应该是相似的,即乘坐同样的车号,并且出行的时间段也是差不多的,即虽然有偏差,但是肯定是具有重叠时间段(即相同的时间段,例如早上8点到9点,下午6点到7点等等),基于这样的数据的采集才能够对公交出行数据进行合并,进而减少数据存储量,减低存储成本。
示例的,上述终端将相似的两个公交出行数据合并成一个得到合并公交出行数据后存储具体可以包括:
将合并公交出行数据中的公交轨迹转换成车号、起始站和终点站,将轨迹时间段、车号、起始站和终点站一起存储。
示例的,上述方法还可以包括:终端接收外部设备发送的合并公交出行数据的提取命令后,提取存储的轨迹时间段、车号、起始站和终点站,提取该车号在该轨迹时间段期间的线路轨迹,从线路轨迹中截取起始点和终端点之间的部分轨迹作为还原的合并公交出行数据中的公交轨迹,将还原的合并公交出行数据中的公交轨迹以及轨迹时间段添加至提取响应中返送至外部设备。
上述外部设备可以为第三方的计算机、手机等等,上述第三方的具体表现形式本申请并不限定。
对于公交系统的运行轨迹来说,其运行轨迹在一定时间段内是固定的,以公交汽车为例,地铁也类似,当起始站、终点站、车号以及时间段确定以后,其运行轨迹实际上确定的,因此不用采用常规的轨迹存储方式,例如通过link(链接)组或坐标组的方式来存储,这样能够减少存储空间,对应的在提取时,可以通过上述起始站、终点站、车号以及时间段对运行轨迹进行完全的还原,这样能够减少存储量的同时,不影响运行轨迹的存储精度,进而进一步降低数据处理的成本。
示例的,上述将轨迹时间段、车号、起始站和终点站一起存储具体可以包括:
将轨迹时间段直接存储,将车号、起始站和终点站按预设的存储规则存储得到第一数据,具体可以包括:配置一个32比特位的数据,将城市、车号、起始站和终点站按预设的存储规则存储在32比特位的数据内,其中,32位比特位的前5位表示城市标识,例如北京00001,上海00010等等,第6到第8位表示公共交通的类别,例如快(M)、慢(K)、区间、高峰、地铁(也可以包括城铁或其他类型的轨道交通)、环线等等类型,第9到18位表示车号,例如999、555、1等等,上述第19到32位表示起始站(占7个比特位)和终点站(占7个比特位)。
对于上述预设的存储规则来说,这里以国内为例,这里主要以统计直辖市以及一些交通繁忙的城市为例,这里以32个城市为最大容量,后续3位表示公共交通的类别,例如001表示非环线地铁,010表示环线地铁,011表示快线,100表示慢线,101表示区间,110表示高峰,111表示环线。第9到18位表示车号,即10个比特位表示车号,0-1024,公交车的车号均为三位数,地铁的车号一般为二位数,因此10个比特位表示车号完全足够,后面每7个比特位表示站点,共计128个站点。通过上述预设的存储规则可以实现对城市、车号、起始站和终点站进行准确的记录,并且节省存储的空间。
依据国内最远线路的公交车具有86个站点,因此通过7个比特位完全足够,对于地铁来说,更加没有128个站点,一般均为20-50个站点之间,因此通过7个比特位之间表示站点。
对于普通的线路,即非环线来说,上述解码之后无需进行特别的处理,但是对于环线来说,在解码的时候需要经过一些处理得知环线的方向,以北京10号线为例,其属于环线,例如用户A从知春路—三元桥,理论上,用户A可以坐外环线路从知春路—三元桥(10个站),也可以坐内环线路从知春路—三元桥(36个站),但是实际上用户A只会选择外环线路,因此需要一种方式来区分环线的方向,对于公交车来说,原理也是一样的,这里不在赘述。
则上述方法还可以包括:解码第一数据得到第一城市、类型、车号、第一起始站和第一终点站,确定该类型为环线时,提取第一城市的环线的所有站点名称,构建圆形图,将所有站点名称均匀的分部在该圆形图的周长线上,在周长线上以第一起始站为起点第一终点站为终端构建方向箭头,若方向箭头为顺时针,确定该环线为内环(也可以为外环,具体为那个环线,以线路实际环线的方向为准),若方向箭头为逆时针,确定该环线为外环。
为了方便说明,这里以8个站点为例说明(在实际中可能会远远大于8个站点,例如50或40个站点),参阅图3所示,假设从站点A到站点C(如图3的实线箭头所示),则确定方向箭头为顺时针,确定环线为内环,反之,若从站点A到站点G(如图3的虚线所示),则确定方向箭头为逆时针,确定环线为外环。需要说明的是,图3仅仅是为了方便选择方向,这里每个站点在圆周长线一样是为了方便确定方向,并不表示每个站点之间的距离值。
对于用户A的身份识别来说,分为两大类,第一大类为接触式识别,例如指纹识别,需要用户按压(即接触)来实现识别,第二大类为非接触式识别,例如人脸识别,需要用户进行拍照来实现识别。但是对于用户A的识别,通过人脸识别具有如下的缺点,第一,人脸识别需要用户将人脸执行拍照,对于公共交通来说,其人员身高比较复杂,例如小学生,其身高在1.3米左右,对于成年人,身高可能在1.8米左右,这么大的身高的差距,而采集设备高度相对固定,使得人脸识别在公交系统上使用并不方便,第二,人脸可以直接显示用户的个人信息,即信息若泄露,人脸图片可以直接导致个人信息的泄露。基于此缺点,本申请的身份识别采用手掌静脉识别,即通过手掌的静脉图片来进行识别,对于用户来说,无论其是小孩(1.3米身高)还是成人(1.8米身高),手部的活动空间都很大,并且手部活动非常方便,不想头部的高度调整非常麻烦,因此解决了采集不方便的问题;另外,对于手掌静脉图片来说,其他人(包括自己)是无法通过肉眼识别出其对应的身份的,因此其不会导致个人信息的泄露,增加了安全性。
对于公交系统的静脉图片识别,需要快速的识别,并且需要对采集角度完全不敏感,因此需要一种新型的静脉图片识别方法。具体的,上述方法在步骤S201之前还可以包括:
终端采集目标对象的手掌静脉图片,对该手掌静脉图片执行初步处理得到第一图片(如图5A所示),对第一图片中静脉像素点进行提取得到第二图片,该第二图片包括多个特征点(即静脉像素点),将第二图片中连续的特征点连接起来得到n个线段,计算n个线段中相交线段之间的角度值得到m个角度值,将m个角度值投射到该第二图片中角度值对应的交点(两个线段之间的交点)得到第三图片(如图5B所示);从多个预设图片中提取具有m个角度值的x个预设图片,提取x个预设图片中的第一预设图片,从第三图片的中间区域(即第三图片中点的预设范围,例如中点周围1千或1万像素点的圆形范围)中任意选择m个角度值中的第一值和第二值,以第一值为圆心构建时钟图(第一值向第二值的方向确定为时钟图的12点方向),确定m-1个值在时钟图中的位置值得到m-1个位置值,将m-1个位置值与对应的m-1个角度值组成m-1个值组(每个值组包括1个位置值和与位置值对应的1个角度值),将m-1个值组按顺时针或逆时针排列得到第一向量,同理对第一预设图片处理得到第二向量,计算第一向量与第二向量的差值,若差值小于阈值,确定目标对象的身份为第一预设图片对应的用户A,若差值大于阈值,对x个预设图片中的剩余图片进行处理直至第一向量与第i向量(第i预设图片对应的向量)的差值i小于阈值后,确定该目标对象的身份为第i预设图片对应的用户。
上述识别的原理具体可以包括:这里的静脉识别通过快速识别的方式,原理即通过角度值以及角度值分布图构成向量来进行识别区分,上述初步处理可以采用通用的处理方式,例如二值化、滤波处理、等等,这里不再赘述,上述特征提取的方式也可以采用现有的处理方式,本申请并不限定,上述m与n大小并不限定,m,n也可以相同,因为n个线段对应n个静脉,其有可能不相交,也可能1个静脉相交多个静脉构成多个交点,上述m个角度值可以采用现有的方式,例如反三角函数或图像测量方式来计算角度值;为了避免采集角度对识别的影响,因此这里的构建向量需要去除掉角度的影响,对于相同的一个人的采集的两个图片,由于采集的条件不同(例如角度、范围有所影响),其采集的静脉图片也可能不同,但是两个图片中静脉是不变的,静脉的角度也是不变的,另外,各个角度之间的方位也是不变的,因此通过时钟图来确定方位,即将360°设置成12个方位,其中位置值可以为时间区间的最大值或最小值(这里的预设图片的位置值获取方式要不目标对象的第三图片方式一样),如角度值30°,其位于1点与2点之间的时间区间,该30°的位置值可以为1,也可以为2,对应的值组可以为30、1;这里假设m=3(实际要大于3),则2个角度值分别为30°、155°,30°对应的位置值为1,155°对应的位置为6,则按顺时针顺序构建第一向量可以为,30,1,155,6;若按逆时针构建第一向量可以为55,6,30,1,这样就可以与模板图片(即预设图片)进行比对即能够对用户身份进行快速的识别。上述第一值为预设范围的唯一值,即在第三图片的中间区域中没有与第一值相同的值,上述角度值的精度可以为小数点后1位,也可以精确到1°即可。
参阅图4,图4提供了一种基于大数据平台的智慧城市数据处理系统,
采集单元401,用于采集用户A的当前公交出行数据,该当前公交出行数据包括:公交轨迹和轨迹时间段;
所述公交轨迹具体包括:车号、上车站和下车站;上述轨迹时间段包括:上车时间和下车时间;
处理单元402,用于将该当前公交出行数据与用户A的历史公交出行数据进行比对确定是否具有相似的公交出行数据;若具有相似的公交出行数据,将相似的两个公交出行数据合并成一个得到合并公交出行数据后存储。
示例的,
处理单元402,具体用于将当前公交出行数据中的第一公交轨迹与历史公交出行数据的公交轨迹进行一致性比对,若历史公交出行数据中具有与第一公交轨迹的车号、上车站和下车站完全一致的第二公交轨迹,获取第二公交轨迹的第二轨迹时间段,若第二轨迹时间段与第一公交轨迹对应的第一轨迹时间段具有重叠时间段且第一公交轨迹与第二公交轨迹完全一致,确定当前公交出行数据与第二公交轨迹对应的第二公交出行数据近似,否则确定不近似。
示例的,
处理单元402,具体用于将相似的两个公交出行数据的两个公交轨迹合并成一个得到合并公交轨迹,若两个轨迹时间段完全相同,则将两个完全相同的轨迹时间段合并成一个得到合并轨迹时间段,将该合并公交轨迹和合并轨迹时间段确定为合并公交出行数据,若两个轨迹时间段不完全相同,将该合并公交轨迹和两个轨迹时间段确定为合并公交出行数据;
将相似的两个公交出行数据合并成一个得到合并公交出行数据后存储具体包括:
将合并公交出行数据中的公交轨迹转换成车号、起始站和终点站,将轨迹时间段、车号、起始站和终点站一起存储。
示例的,
处理单元402,具体用于接收外部设备发送的合并公交出行数据的提取命令后,提取存储的轨迹时间段、车号、起始站和终点站,提取该车号在该轨迹时间段期间的线路轨迹,从线路轨迹中截取起始点和终端点之间的部分轨迹作为还原的合并公交出行数据中的公交轨迹,将还原的合并公交出行数据中的公交轨迹以及轨迹时间段添加至提取响应中返送至外部设备。
本发明实施例还提供一种计算机存储介质,其中,该计算机存储介质存储用于电子数据交换的计算机程序,该计算机程序使得计算机执行如上述方法实施例中记载的任何一种基于大数据平台的智慧城市数据处理方法的部分或全部步骤。
本发明实施例还提供一种计算机程序产品,所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质,所述计算机程序可操作来使计算机执行如上述方法实施例中记载的任何一种基于大数据平台的智慧城市数据处理方法的部分或全部步骤。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以接收其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于可选实施例,所涉及的动作和模块并不一定是本发明所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置,可通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性或其它的形式。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储器中,存储器可以包括:闪存盘、只读存储器(英文:Read-Only Memory,简称:ROM)、随机存取器(英文:Random Access Memory,简称:RAM)、磁盘或光盘等。
以上对本发明实施例进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。