本发明涉及互联网技术领域,尤其涉及一种用于识别用户出行场景的方法、装置及计算机设备。
背景技术
随着网络的不断发展,用户的出行越来越方便,但随之而来的安全问题。当用户遇到危险时,现有技术中用户只能偷偷地手动向好友、家人或者报警平台传递信息,但是遇到更为危险的情况时,用户一般是传递不出任何信息的,导致用户的出行安全得不到保障。
技术实现要素:
鉴于上述问题,提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的用于识别用户出行场景的方法、装置及计算机设备。
本发明的一个方面,提供了一种用于识别用户出行场景的方法,所述方法包括:
获取用户在预设周期内的出行数据;
根据所述出行数据生成所述用户的出行线路轨迹;
根据所述出行线路轨迹预先确定所述用户在各目标时间点对应的出行场景;
检测所述用户在出行过程中,是否在任一当前所处的目标时间点到达对应的出行场景;若不是,则推送所述用户出行危险的报警信息。
可选地,所述获取用户在预设周期内的出行数据,包括:
在所述预设周期内,按照预设的出行距离间隔获取对应的时间点及各所述时间点对应的经纬度信息。
可选地,所述获取用户在预设周期内的出行数据,包括:
在所述预设周期内,按照预设的时间间隔获取对应的时间点及各所述时间点对应的经纬度信息。
可选地,所述根据所述出行数据生成所述用户的出行线路轨迹,包括:
从所述出行数据中提取出训练出行数据;
对所述出行训练数据进行合并,形成训练数据集;
利用所述训练数据集进行出行线路轨迹模型训练,以生成所述出行线路轨迹模型;
利用所述出行线路轨迹模型预测出所述出行线路轨迹。
可选地,所述根据所述出行线路轨迹确定所述用户在各目标时间点对应的出行场景,包括:
获取所述出行线路轨迹中所述目标时间点对应的经纬度信息;
利用地图数据库对所述目标时间点对应的经纬度信息进行匹配,确定所述经纬度信息对应的地标信息;
根据所述地标信息确定出对应的出行场景。
可选地,所述方法还包括:
检测所述用户在出行过程中的交通状态,若所述交通状态为畅行状态,执行检测所述用户是否在任一当前所处的目标时间点到达对应的出行场景的步骤;
若所述交通状态为非畅行状态,根据所述交通状态预估所述用户的延迟时间;
根据所述延迟时间及所述目标时间点确定应到达时间点;
检测所述用户是否在所述应到达时间点到达对应的出行场景,若不是,则推送所述用户出行危险的报警信息。
可选地,所述推送用户出行危险的报警信息,包括:
向好友推送所述用户出行危险的报警信息。
可选地,所述向好友推送用户出行危险的报警信息后,包括:
检测所述报警信息是否推送成功,若没有推送成功,则继续检测是否存在紧急联系人,若存在所述紧急联系人,则向所述紧急联系人发送短信报警信息。
可选地,若检测到不存在所述紧急联系人,包括:向报警平台拨打报警电话。
可选地,所述推送用户出行危险的报警信息后,包括:向所述好友分享所述用户的实时位置信息。
本申请实施例还提供一种用于识别用户出行场景的装置,所述装置包括:
获取单元,用于获取用户在预设周期内的出行数据;
生成单元,用于根据所述出行数据生成所述用户的出行线路轨迹;
确定单元,用于根据所述出行线路轨迹预先确定所述用户在各目标时间点对应的出行场景;
检测单元,用于检测所述用户在出行过程中,是否在任一当前所处的目标时间点到达对应的出行场景,若不是,则向好友推送所述用户出行危险的报警信息。
可选地,所述获取单元具体用于:
在所述预设周期内,按照预设的出行距离间隔获取对应的时间点及各所述时间点对应的经纬度信息。
可选地,所述获取单元具体用于:
在所述预设周期内,按照预设的时间间隔获取对应的时间点及各所述时间点对应的经纬度信息。
可选地,所述生成单元包括:
提取子单元,用于从所述出行数据中提取出训练出行数据;
合并子单元,用于对所述出行训练数据进行合并,形成训练数据集;
训练子单元,用于利用所述训练数据集进行出行线路轨迹模型训练,以生成所述出行线路轨迹模型;
预测子单元,用于利用所述出行线路轨迹模型预测出所述出行线路轨迹。
可选地,所述确定单元具体用于:
获取所述出行线路轨迹中所述目标时间点对应的经纬度信息;
利用地图数据库对所述目标时间点对应的经纬度信息进行匹配,确定所述经纬度信息对应的地标信息;
根据所述地标信息确定出对应的出行场景。
可选地,所述检测单元用于:
检测所述用户在出行过程中的交通状态,若所述交通状态为畅行状态,执行检测所述用户是否在任一当前所处的目标时间点到达对应的出行场景的步骤;
若所述交通状态为非畅行状态,根据所述交通状态预估所述用户的延迟时间;
根据所述延迟时间及所述目标时间点确定应到达时间点;
检测所述用户是否在所述应到达时间点到达对应的出行场景,若不是,则推送所述用户出行危险的报警信息。
可选地,所述检测单元用于:
向好友推送所述用户出行危险的报警信息。
可选地,所述检测单元用于:
向好友推送用户出行危险的报警信息后,检测所述报警信息是否推送成功,若没有推送成功,则继续检测是否存在紧急联系人,若存在所述紧急联系人,则向所述紧急联系人发送短信报警信息。
可选地,所述检测单元用于:若检测到不存在所述紧急联系人,向报警平台拨打报警电话。
可选地,所述装置还包括:分享单元,用于向好友推送用户出行危险的报警信息后,向所述好友分享所述用户的实时位置信息。
本申请实施例还提供一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现上述任一项所述方法的步骤。
本申请实施例还提供一种用于识别用户出行场景的计算机设备,包括:
至少一个处理器;以及
与所述处理器通信连接的至少一个存储器,其中,所述存储器存储有可被所述处理器执行的程序指令,所述处理器调用所述程序指令能够执行如上述任一项所述方法的步骤。
本申请实施例中提供的技术方案,至少具有如下技术效果或优点:
本申请实施例提供一种用于识别用户出行场景的方法、装置及计算机设备,方法包括:获取用户在预设周期内的出行数据;根据所述出行数据生成所述用户的出行线路轨迹;根据所述出行线路轨预先确定所述用户在各目标时间点对应的出行场景;检测所述用户在出行过程中,是否在任一当前所处的目标时间点到达对应的出行场景,若不是,则推送用户出行危险的报警信息;如此,预先根据用户的出行习惯确定在目标时间点对应的出行场景,当用户出行时,在交通畅行状态下,若检测到在目标时间点没有到达应该到达的出行场景,则会自动推送用户出行危险的报警信息,以确保用户的出行安全。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1示出了根据本发明一个实施例的识别用户出行场景的方法流程示意图;
图2示出了根据本发明一个实施例的识别用户出行场景的装置结构示意图;
图3示出了根据本发明一个实施例的生成单元的结构示意图;
图4示出了根据本发明一个实施例的添加好友的界面示意图;
图5示出了根据本发明一个实施例的添加紧急联系人的界面示意图;
图6示出了根据本发明一个实施例的分享位置的界面示意图;
图7示出了根据本发明一个实施例的始终允许获取位置提示的界面示意图;
图8示出了根据本发明一个实施例的安全出行的界面示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
本发明实施例提供了一种用于识别用户出行场景的方法、装置及计算机设备,用以解决现有技术的用户出行安全得不到保障的技术问题。
实施例一
本实施例提供一种用于识别用户出行场景的方法,如图1所示,方法包括:
s110,获取用户在预设周期内的出行数据;
一般来说,不是经常出差的用户都会有固定的出行路线,比如上班族或者全职接送小孩的人群,上班族的出行路线在周内一般是家和公司之间,全职接送小孩的人群的出行路线一般是家和学校之间。因此针对该类用户的出行数据对研究用户出行安全是有实际意义的,那么可以获取该类用户在预设周期内的出行数据,本实施例中在获取出行数据时是以天为单位获取的,预设的周期为30天,也可根据实际需求进行设置。
作为一种可选的实施例,在获取用户的出行数据时,可以根据预设的时间间隔获取,那么获取用户在预设周期内的出行数据,包括:
在预设周期内,按照预设的时间间隔获取对应的时间点及各时间点对应的经纬度信息。
比如,可以将时间间隔设置为10s,也就是每隔10s会自动获取当前对应的时间点及各时间点对应的经纬度信息。当然,也可以是由客户端每隔10s会自动获取当前对应的时间点及对应的经纬度信息,然后上报至服务器。
作为一种可选的实施例,在获取用户的出行数据时,也可以根据预设的出行距离间隔获取,那么获取用户在预设周期内的出行数据,包括:
在预设周期内,按照预设的出行距离间隔获取对应的时间点及各时间点对应的经纬度信息。
比如,可以将出行距离间隔设置为200m,那么每间隔200m时会自动获取一次当前对应的时间点及各时间点对应的经纬度信息。这里,也可以是由客户端自动获取当前对应的时间点及对应的经纬度信息,然后上报至服务器。
作为一种可选的实施例,在获取各时间点对应的经纬度信息时,可以利用全球定位系统(gps,globalpositioningsystem)直接获取,也可以通过基站信息或者wifi信息查询地理位置,再通过地理位置确定经纬度信息。
在通过wifi信息确定经纬度信息时,具体实现如下:
扫描并收集终端周围的无线接入点,获取无线接入点的媒体访问控制(mac,mediaaccesscontrol)地址;将无线接入点的mac地址发送至服务器,服务器会根据无线接入点的mac地址信息从位置数据库中检索出每个无线接入点的地理位置信息,将每个无线接入点的地理位置信息进行坐标运算,确定出具体的经纬度信息。当所有无线接入点的经纬度信息都确定出之后,就可以根据所有无线接入点的经纬度信息确定出用户当前的经纬度信息。其中,无线接入点的数量越多,确定用户当前的经纬度信息的准确度就会越准确。
在通过基站信息确定经纬度信息时,具体实现如下:
获取终端当前接入的基站位置信息;
从地理信息系统(gis,geographicinformationsystem)中获取当前接入根据当前接入的基站位置信息周围的地理信息;
根据当前接入的基站位置信息及基站周围的地理信息确定当前接入的基站所属的蜂窝小区,根据所属的蜂窝小区确定用户当前的地理位置信息,再对地理位置信息进行转换,获取对应的经纬度信息。
这里,因运营商在建立基站时,每一个基站都有确切的位置记录,因此可获取到终端当前接入的基站位置信息。
s112,根据所述出行数据生成所述用户的出行线路轨迹;
获取到预设周期内的出行数据后,可利用机器学习算法,将出行数据生成用户的出行线路轨迹。
作为一种可选的实施例,根据出行数据生成用户的出行线路轨迹,包括:
从出行数据中提取出训练出行数据;
对出行训练数据进行合并,形成训练数据集;
利用训练数据集进行出行线路轨迹模型训练,以生成出行线路轨迹模型;
利用出行线路轨迹模型预测出出行线路轨迹。
这里,因出行数据太多,为了提高处理效率,可以随机从出行数据中提取出一些样本数据作为训练出行数据,也可以按照预设的提取规则从出行数据中提取出一些样本数据作为训练出行数据,在此不做限定。
作为一种可选的实施例,利用训练数据集进行出行线路轨迹模型训练,以生成所述出行线路轨迹模型,包括:
针对训练数据集,通过机器学习算法(如神经网络算法、逻辑回归算法)进行训练,得到出行线路轨迹模型。
s112,根据所述出行线路轨迹预先确定所述用户在各目标时间点对应的出行场景;
作为一种可选的实施例,预测出出行线路轨迹后,可以根据出行线路轨迹预先确定用户在各目标时间点对应的出行场景,包括:
获取目标时间点对应的经纬度信息;
利用地图数据库对目标时间点对应的经纬度信息进行匹配,确定经纬度信息对应的地标信息(该经纬度信息依然为目标时间点对应的经纬度信息);
根据地标信息确定出对应的出行场景。
这里,地图数据库中预先存储有经纬度信息对应的建筑物名称,当获取到经纬度信息后,可在地图数据库中查找对应的建筑物名称,以此来确定对应的出行场景。
比如,在早上8点半到9点钟之间获取用户a的经纬度信息为(a,b),根据此经纬度信息确定到对应的建筑物为某写字楼,那么就可以确定出对应的出行场景为上班场景。
当下午6点到6点半获取到用户a的经纬度信息为(c,d),根据此经纬度信息确定到对应的建筑物为某小区楼,那么就可以确定出对应的出行场景为到家场景。
需要说明的是,在根据地标信息确定对应的出行场景时,是可以有一个距离阈值范围的,当用户的经纬度信息满足此阈值范围,也可视为是到达了某出行场景。比如下午6点到6点半获取到用户a的经纬度信息为(e,f),检测到经纬度信息为(e,f)与经纬度信息为(c,d)之间的距离满足预设的距离阈值范围时,也可视为用户a当前的出行场景为到家场景。其中,一般会将预设的距离阈值范围设置为小于或等于500m。
当然,用户在也可以手动设置上下班场景的位置信息、上下班时间,以能确保精确度。
并且,当匹配到用户有新的出行场景时,会弹出展示有是否扩充新的场景的提示信息,当接收到用户的确认信息时,则会自动添加新的场景。
比如,在周六上午10点左右匹配到用户a到健身馆了,就会弹出展示有是否增加“健身场景”的提示信息,当接收到用户的确认信息时,则会自动添加“健身场景”。
作为一种可选的实施例,为了确保信息的连续性,客户端在无网络状态下也会将目标时间点及对应的经纬度信息缓存至本地存储中,当有网络时,会将本地存储中的信息上传至服务器中。其中,终端上传的信息格式可以如下:
{"latitude":"39.98336029","longitude":"116.49137878","time":"1533785724","state":"walking"}
latitude表示纬度、longitude表示经度、time表示时间戳,可以精确到秒;state代表当前状态。比如上述时间戳"1533785724"可以转换为时间:“2018/8/911:35:24”,当前状态可以包括:静止still、行走walking、驾驶driving等状态,状态可根据终端的传感器数据确定。
s113,检测所述用户在出行过程中,是否在任一当前所处的目标时间点到达对应的出行场景,若不是,则推送用户出行危险的报警信息。
预先确定用户在各目标时间点对应的出行场景后,用户出行时,在出行过程中,检测用户是否在任一当前所处的目标时间点到达对应的出行场景,若不是,则推送用户出行危险的报警信息。
比如,用户a下午6点到6点半之间对应的出行场景应该是下班场景,此时若检测到用户a在该时间段到达的是陌生场景,则将该陌生场景视为高危场景向好友推送用户出行危险的报警信息。其中,陌生场景可以包括:郊外、酒店等场景。
但是,若检测到户a在该时间段到达的是办事的一些场景(比如:银行、营业厅等),则会为用户预留延迟时间,若用户在延迟后的时间内到达了下班场景,也视为用户a是正常出行。比如,若预留的延迟时间为半个小时,即使用户a晚到家半个小时,也会向好友推送“好友a正常到家”的提示信息。
当获取不到交通状态时(比如在无网络状态下),即使用户在任一当前所处的目标时间点没有到达对应的出行场景,也会用户预留延迟时间。这里可以获取用户的守时类型,根据守时类型为用户预留延迟时间;比如:若用户的守时类型为良好时,预留的延迟时间可以为10min。若用户的守时类型为一般时,预留的延迟时间可以为30min。
作为一种可选的实施例,为了提高检测的精度,防止误判,作为一种可选的实施例,方法还包括:
检测所述用户在出行过程中的交通状态,若所述交通状态为畅行状态,执行检测所述用户是否在任一当前所处的目标时间点到达对应的出行场景的步骤;
若交通状态为非畅行状态,根据交通状态预估所述用户的延迟时间;
根据延迟时间及目标时间点确定应到达时间点;
检测所述用户是否在应到达时间点到达对应的出行场景,若不是,则推送用户出行危险的报警信息。
作为一种可选的实施例,根据交通状态预估用户的延迟时间时,包括:
从第三方地图数据库中获取交通拥堵的时间,根据交通拥堵的时间确定延迟时间。
比如,预计交通拥堵的时间为5min,那么就将延迟时间设置为5min。
或者,某天检测到当前路段限速时,可以直接根据t1+s/v来确定应到达时间点;其中,t1为当前时刻,s为剩余距离,v为当前限速的速度。
而对于用户自动增加的场景,比如上文所说的健身场景,当用户a周六到达健身馆时,会向好友自动推送“好友a去健身了”的提示信息。
作为一种可选的实施例,在推送报警信息时,可以向用户的好友、紧急联系人及报警平台中的任一对象推送报警信息。也可以按照用户的好友、紧急联系人、报警平台这样的优先级进行推送。
按照用户的好友、紧急联系人、报警平台这样的优先级进行推送时,首先向好友推送报警信息,在向好友推送用户出行危险的报警信息时,会优先选用网络通道向好友推送,也可以通过qq、微信等即时通信软件推送。
作为一种可选的实施例,向好友推送用户出行危险的报警信息后,包括:
检测报警信息是否从网络通道推送成功,若没有推送成功,表明此时网络通道是不通的,则通过短信形式向好友发送报警信息。并且会继续检测是否存在紧急联系人,若存在紧急联系人,也向紧急联系人发送短信报警信息。
作为一种可选的实施例,若检测到不存在紧急联系人,包括:向报警平台自动拨打报警电话。
作为一种可选的实施例,推送用户出行危险的报警信息后,包括:自动分享所述用户的实时位置信息。
这里,在分享位置信息时,可以同时向多个好友分享,本实施例中设置为5个。
同样的,在有网络状态下,该实时位置信息会优先选用网络通道向好友分享,也可以通过qq、微信等即时通信软件分享。在无网络状态时,会通过短信形式向好友或紧急联系人分享。其中,紧急联系人与好友可以是相同的人,也可以是不同的人。
这里,需要说明的是,步骤s110~s112均执行一次即可确定用户的出行场景,步骤s113可执行多次,即用户每次出行时,都可根据步骤s110~s112确定的出行场景进行识别。
基于同样的发明构思,本申请实施例还提供一种用于识别用户出行场景的装置,详见实施例二。
实施例二
本实施例提供一种用于识别用户出行场景的装置,如图2所示,装置包括:获取单元21、生成单元22、确定单元23及检测单元24;其中,
一般来说,不是经常出差的用户都会有固定的出行路线,比如上班族或者全职接送小孩的人群,上班族的出行路线在周内一般是家和公司之间,全职接送小孩的人群的出行路线一般是家和学校之间。因此针对该类用户的出行数据对研究用户出行安全是有实际意义的,那么获取单元21可以获取该类用户在预设周期内的出行数据,本实施例中预设的周期为30天,也可根据实际需求进行设置。
作为一种可选的实施例,获取单元21具体用于:在预设周期内,按照预设的时间间隔获取对应的时间点及各时间点对应的经纬度信息。
比如,可以将时间间隔设置为10s,也就是每隔10s会自动获取当前对应的时间点及各时间点对应的经纬度信息。当然,也可以是由获取单元21每隔10s会自动获取当前对应的时间点及对应的经纬度信息,然后上报至服务器。
作为一种可选的实施例,获取单元21具体用于:
在预设周期内,按照预设的出行距离间隔获取对应的时间点及各时间点对应的经纬度信息。
比如,可以将出行距离间隔设置为200m,那么每间隔200m时会自动获取一次当前对应的时间点及各时间点对应的经纬度信息。这里,也可以是获取单元21自动获取当前对应的时间点及对应的经纬度信息,然后上报至服务器。
作为一种可选的实施例,获取单元21在获取对应的经纬度信息时,可以利用gps直接获取,也可以通过基站信息或者wifi信息查询地理位置,再通过地理位置确定经纬度信息。
在通过wifi信息确定经纬度信息时,具体实现如下:
扫描并收集终端周围的无线接入点,获取无线接入点的mac地址;将无线接入点的mac地址发送至服务器,服务器会根据无线接入点的mac地址信息从位置数据库中检索出每个无线接入点的地理位置信息,将每个无线接入点的地理位置信息进行坐标运算,确定出具体的经纬度信息。当所有无线接入点的经纬度信息都确定出之后,就可以根据所有无线接入点的经纬度信息确定出用户当前的经纬度信息。其中,无线接入点的数量越多,确定用户当前的经纬度信息的准确度就会越准确。
在通过基站信息确定经纬度信息时,具体实现如下:
获取终端当前接入的基站位置信息;
从地理信息系统gis中获取当前接入根据当前接入的基站位置信息周围的地理信息;
根据当前接入的基站位置信息及基站周围的地理信息确定当前接入的基站所属的蜂窝小区,根据所属的蜂窝小区确定用户当前的地理位置信息,再对地理位置信息进行转换,获取对应的经纬度信息。
这里,因运营商在建立基站时,每一个基站都有确切的位置记录,因此可获取到终端当前接入的基站位置信息。
获取到预设周期内的出行数据后,生成单元22用于根据所述出行数据生成所述用户的出行线路轨迹。具体地,参见图3,生成单元22包括:提取子单元31、合并子单元32、生成子单元33及预测子单元34;其中,
提取子单元31用于从出行数据中提取出训练出行数据;
合并子单元32用于对出行训练数据进行合并,形成训练数据集;
生成子单元33用于利用训练数据集进行出行线路轨迹模型训练,以生成出行线路轨迹模型;
预测子单元34利用出行线路轨迹模型预测出出行线路轨迹。
这里,因出行数据太多,为了提高处理效率,提取子单元31可以随机从出行数据中提取出一些样本数据作为训练出行数据,也可以按照预设的提取规则从出行数据中提取出一些样本数据作为训练出行数据,在此不做限定。
作为一种可选的实施例,利用训练数据集进行出行线路轨迹模型训练,以生成所述出行线路轨迹模型,包括:
作为一种可选的实施例,生成子单元33具体用于:
针对训练数据集,通过机器学习算法(如神经网络算法、逻辑回归算法)进行训练,得到出行线路轨迹模型。
预测出出行线路轨迹后,确定单元23用于根据出行线路轨迹预先确定用户在各目标时间点对应的出行场景。确定单元23具体用于:
获取目标时间点对应的经纬度信息;
利用地图数据库对目标时间点对应的经纬度信息进行匹配,确定经纬度信息对应的地标信息(该经纬度信息依然为目标时间点对应的经纬度信息);
根据地标信息确定出对应的出行场景。
这里,地图数据库中预先存储有经纬度信息对应的建筑物名称,当确定单元23获取到经纬度信息后,可在地图数据库中查找对应的建筑物名称,以此来确定对应的出行场景。
比如,在早上8点半到9点钟之间获取用户a的经纬度信息为(a,b),根据此经纬度信息确定到对应的建筑物为某写字楼,那么确定单元23就可以确定出对应的出行场景为上班场景。
当下午6点到6点半获取到用户a的经纬度信息为(c,d),根据此经纬度信息确定到对应的建筑物为某小区楼,那么确定单元23就可以确定出对应的出行场景为到家场景。
需要说明的是,在根据地标信息确定对应的出行场景时,是可以有一个距离阈值范围的,当用户的经纬度信息满足此阈值范围,也可视为是到达了某出行场景。比如下午6点到6点半获取到用户a的经纬度信息为(e,f),检测到经纬度信息为(e,f)与经纬度信息为(c,d)之间的距离满足预设的距离阈值范围时,也可视为用户a当前的出行场景为到家场景。其中,一般会将预设的距离阈值范围设置为小于或等于500m。
当然,用户在也可以手动设置上下班场景的位置信息、上下班时间,以能确保精确度。
并且,当匹配到用户有新的出行场景时,会弹出展示有是否扩充新的场景的提示信息,当接收到用户的确认信息时,则会自动添加新的场景。
比如,在周六上午10点左右匹配到用户a到健身馆了,就会弹出展示有是否增加“健身场景”的提示信息,当接收到用户的确认信息时,则会自动添加“健身场景”。
作为一种可选的实施例,为了确保信息的连续性,客户端在无网络状态下也会将目标时间点及对应的经纬度信息缓存至本地存储中,当有网络时,会将本地存储中的信息上传至服务器中。其中,终端上传的信息格式可以如下:
{"latitude":"39.98336029","longitude":"116.49137878","time":"1533785724","state":"walking"}
latitude表示纬度、longitude表示经度、time表示时间戳,可以精确到秒;state代表当前状态。比如上述时间戳"1533785724"可以转换为时间:“2018/8/911:35:24”,当前状态可以包括:静止still、行走walking、驾驶driving等状态,状态可根据终端的传感器数据确定。
确定单元23预先确定出用户在各目标时间点对应的出行场景后,检测单元24用于当用户出行时,在出行过程中,检测所述用户是否在任一当前所处的目标时间点到达对应的出行场景,若不是,则向好友推送用户出行危险的报警信息。
比如,用户a下午6点到6点半之间对应的出行场景应该是下班场景,此时检测单元若检测到用户a在该时间段到达的是陌生场景,则将该陌生场景视为高危场景向好友推送用户出行危险的报警信息。其中,陌生场景可以包括:郊外、酒店等场景。但是,若检测单元检测到户a在该时间段到达的是办事的一些场景(比如:银行、营业厅等),则会为用户预留延迟时间,若用户在延迟后的时间内到达了下班场景,也视为用户a是正常出行。比如,若预留的延迟时间为半个小时,即使用户a晚到家半个小时,也会向好友推送“好友a正常到家”的提示信息。
当获取不到交通状态时(比如在无网络状态下),即使用户在任一当前所处的目标时间点没有到达对应的出行场景,也会用户预留延迟时间。可以获取用户的守时类型,根据守时类型为用户预留延迟时间;比如:若用户的守时类型为良好时,预留的延迟时间可以为10min。若用户的守时类型为一般时,预留的延迟时间可以为30min。
作为一种可选的实施例,为了提高检测的精度,防止误判,检测单元24用于:
检测所述用户在出行过程中的交通状态,若所述交通状态为畅行状态,执行检测所述用户是否在任一当前所处的目标时间点到达对应的出行场景的步骤;
若交通状态为非畅行状态,根据交通状态预估所述用户的延迟时间;
根据延迟时间及目标时间点确定应到达时间点;
检测所述用户是否在应到达时间点到达对应的出行场景,若不是,则推送用户出行危险的报警信息。
作为一种可选的实施例,根据交通状态预估用户的延迟时间时,包括:
从第三方地图数据库中获取交通拥堵的时间,根据交通拥堵的时间确定延迟时间。
比如,预计交通拥堵的时间为5min,那么就将延迟时间设置为5min。
或者,某天检测到当前路段限速时,可以直接根据t1+s/v来确定应到达时间点;其中,t1为当前时刻,s为剩余距离,v为当前限速的速度。
而对于用户自动增加的场景,比如上文所说的健身场景,当用户a周六到达健身馆时,会向好友自动推送“好友a去健身了”的提示信息。
作为一种可选的实施例,在推送报警信息时,可以向用户的好友、紧急联系人及报警平台中的任一对象推送报警信息。也可以按照用户的好友、紧急联系人、报警平台这样的优先级进行推送。
按照用户的好友、紧急联系人、报警平台这样的优先级进行推送时,检测单元24首先向好友推送报警信息,在向好友推送用户出行危险的报警信息时,会优先选用网络通道向好友推送,也可通过qq、微信等即时通信软件推送。
作为一种可选的实施例,向好友推送用户出行危险的报警信息后,检测单元24还用于:
检测报警信息是否从网络通道推送成功,若没有推送成功,表明此时网络通道是不通的,则通过短信形式向好友发送报警信息。并且会继续检测是否存在紧急联系人,若存在紧急联系人,也向紧急联系人发送短信报警信息。
作为一种可选的实施例,若检测到不存在紧急联系人,检测单元24用于:向报警平台自动拨打报警电话。
作为一种可选的实施例,参见图2,装置还包括:分享单元25,向好友推送用户出行危险的报警信息后,分享单元25用于:向好友自动分享所述用户的实时位置信息。这里,在分享位置信息时,可以同时向多个好友分享,本实施例中设置为5个。
同样的,在有网络状态下,该实时位置信息会优先选用网络通道向好友分享,也可通过qq、微信等即时通信软件分享。在无网络状态时,会通过短信形式向好友或紧急联系人分享。其中,紧急联系人与好友可以是相同的人,也可以是不同的人。
本申请实施例中提供的技术方案,至少具有如下技术效果或优点:
本申请实施例提供一种用于识别用户出行场景的方法、装置及计算机设备,方法包括:获取用户在预设周期内的出行数据;根据所述出行数据生成所述用户的出行线路轨迹;根据所述出行线路轨迹预先确定所述用户在各目标时间点对应的出行场景;检测所述用户在出行过程中,是否在任一当前所处的目标时间点到达对应的出行场景,若不是,则推送用户出行危险的报警信息;如此,预先根据用户的出行习惯确定在目标时间点对应的出行场景,当用户出行时,若检测到在任一当前所处的目标时间点没有到达应该到达的出行场景,则会自动向好友、紧急联系人或报警平台推送用户出行危险的报警信息,以确保用户的出行安全。
实施例三
实际应用中,可利用上述方法及装置识别用户的出行场景,具体实现如下:
首先是添加家人信息,家人信息也可称为是上文所述的好友,添加好友界面如图4所示。
家人信息添加好之后,用户和家人之间可以进行实时位置分享、聊天等。当利用上述实施例中的方法及装置检测到用户在目标时间点到达上班场景或到家场景时,会自动向家人推送“我已上班”或“我已到家”的提示信息。
当检测到用户在目标时间点没有到达上班场景或到家场景时,则会向家人推送出行危险的报警信息。
为了能在无网络状态下发送报警信息,本实施例还可设置紧急联系人,用户通过点击主界面上的“紧急求助”可添加紧急联系人,设置成功后,当在无网络状态时,可将出行危险的报警信息以短信形式发送至紧急联系人。其中,紧急联系人可以从家人中选择,也可以另外添加。设置紧急联系人的界面如图5所示。
当家人信息及紧急联系人都设置好之后,可以与家人进行位置分享,在分享成功后,家人可在1小时之内查看用户的实时位置。当检测到发送过出行危险的报警信息时,也可自动向家人或紧急联系人分享实时位置,以能让家人或紧急联系人采取应对的安全措施。分享位置的界面如图6所示。
当用户需要始终获得位置提醒时,可以点击主界面上的“位置提醒”来设置,以能让服务器始终提醒家人或紧急联系人用户的当前位置。始终允许获取位置提示的界面如图7所示。
本实施例中还可设置安全出行,在安全出行中可下载第三方用车软件,如滴滴出行、神州出行等,以方便用户出行。安全出行界面如图8所示。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述,构造这类系统所要求的结构是显而易见的。此外,本发明也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明的内容,并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本发明实施例的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
本发明公开了,a1、一种用于识别用户出行场景的方法,所述方法包括:
获取用户在预设周期内的出行数据;
根据所述出行数据生成所述用户的出行线路轨迹;
根据所述出行线路轨迹预先确定所述用户在各目标时间点对应的出行场景;
检测所述用户在出行过程中,是否在任一当前所处的目标时间点到达对应的出行场景;若不是,则推送所述用户出行危险的报警信息。
a2、如a1所述的方法,获取用户在预设周期内的出行数据,包括:
在所述预设周期内,按照预设的出行距离间隔获取对应的时间点及各所述时间点对应的经纬度信息。
a3、如a1所述的方法,获取用户在预设周期内的出行数据,包括:
在所述预设周期内,按照预设的时间间隔获取对应的时间点及各所述时间点对应的经纬度信息。
a4、如a1所述的方法,所述根据所述出行数据生成所述用户的出行线路轨迹,包括:
从所述出行数据中提取出训练出行数据;
对所述出行训练数据进行合并,形成训练数据集;
利用所述训练数据集进行出行线路轨迹模型训练,以生成所述出行线路轨迹模型;
利用所述出行线路轨迹模型预测出所述出行线路轨迹。
a5、如a1所述的方法,所述根据所述出行线路轨迹确定所述用户在各目标时间点对应的出行场景,包括:
获取所述出行线路轨迹中所述目标时间点对应的经纬度信息;
利用地图数据库对所述目标时间点对应的经纬度信息进行匹配,确定所述经纬度信息对应的地标信息;
根据所述地标信息确定出对应的出行场景。
a6、如a1所述的方法,所述方法还包括:
检测所述用户在出行过程中的交通状态,若所述交通状态为畅行状态,执行检测所述用户是否在任一当前所处的目标时间点到达对应的出行场景的步骤;
若所述交通状态为非畅行状态,根据所述交通状态预估所述用户的延迟时间;
根据所述延迟时间及所述目标时间点确定应到达时间点;
检测所述用户是否在所述应到达时间点到达对应的出行场景,若不是,则推送所述用户出行危险的报警信息。
a7、如a1或a6所述的方法,所述推送用户出行危险的报警信息,包括:
向好友推送所述用户出行危险的报警信息。
a8、如a7所述的方法,所述向好友推送用户出行危险的报警信息后,包括:
检测所述报警信息是否推送成功,若没有推送成功,则继续检测是否存在紧急联系人,若存在所述紧急联系人,则向所述紧急联系人发送短信报警信息。
a9、如a8所述的方法,,若检测到不存在所述紧急联系人,包括:向报警平台拨打报警电话。
a10、如a1所述的方法,其向好友推送用户出行危险的报警信息后,包括:向所述好友分享所述用户的实时位置信息。
b11、一种用于识别用户出行场景的装置,所述装置包括:
获取单元,用于获取用户在预设周期内的出行数据;
生成单元,用于根据所述出行数据生成所述用户的出行线路轨迹;
确定单元,用于根据所述出行线路轨迹预先确定所述用户在各目标时间点对应的出行场景;
检测单元,用于检测所述用户在出行过程中,是否在任一当前所处的目标时间点到达对应的出行场景,若不是,则向好友推送所述用户出行危险的报警信息。
b12、如b11所述的装置,所述获取单元具体用于:
在所述预设周期内,按照预设的出行距离间隔获取对应的时间点及各所述时间点对应的经纬度信息。
b13、如b11所述的装置,所述获取单元具体用于:
在所述预设周期内,按照预设的时间间隔获取对应的时间点及各所述时间点对应的经纬度信息。
b14、如b11所述的装置,所述生成单元包括:
提取子单元,用于从所述出行数据中提取出训练出行数据;
合并子单元,用于对所述出行训练数据进行合并,形成训练数据集;
训练子单元,用于利用所述训练数据集进行出行线路轨迹模型训练,以生成所述出行线路轨迹模型;
预测子单元,用于利用所述出行线路轨迹模型预测出所述出行线路轨迹。
b15、如b11所述的装置,所述确定单元具体用于:
获取所述出行线路轨迹中所述目标时间点对应的经纬度信息;
利用地图数据库对所述目标时间点对应的经纬度信息进行匹配,确定所述经纬度信息对应的地标信息;
根据所述地标信息确定出对应的出行场景。
b16、如b11所述的装置,所述检测单元用于:
检测所述用户在出行过程中的交通状态,若所述交通状态为畅行状态,执行检测所述用户是否在任一当前所处的目标时间点到达对应的出行场景的步骤;
若所述交通状态为非畅行状态,根据所述交通状态预估所述用户的延迟时间;
根据所述延迟时间及所述目标时间点确定应到达时间点;
检测所述用户是否在所述应到达时间点到达对应的出行场景,若不是,则推送所述用户出行危险的报警信息。
b17、如b11或b16所述的装置,所述检测单元用于:
向好友推送所述用户出行危险的报警信息。
b18、如b17所述的装置,所述检测单元用于:
向好友推送用户出行危险的报警信息后,检测所述报警信息是否推送成功,若没有推送成功,则继续检测是否存在紧急联系人,若存在所述紧急联系人,则向所述紧急联系人发送短信报警信息。
b19、如b17所述的装置,所述检测单元用于:若检测到不存在所述紧急联系人,向报警平台拨打报警电话。
b20、如b11所述的装置,所述装置还包括:分享单元,用于向好友推送用户出行危险的报警信息后,向所述好友分享所述用户的实时位置信息。
c21、一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现a1至a10任一项所述方法的步骤。
d22、一种用于识别用户出行场景的计算机设备,包括:
至少一个处理器;以及
与所述处理器通信连接的至少一个存储器,其中,所述存储器存储有可被所述处理器执行的程序指令,所述处理器调用所述程序指令能够执行如a1至a10任一项所述方法的步骤。