关于全国poi兴趣点数据

1、POI数据介绍

 POI是“Point of Interest”的缩写,中文可以翻译为“兴趣点”。POI数据会包含各种信息,如前面提到的名称、别名等信息,可以将这些信息看成一个个的标签(tag),而分类是其中最重要的一个tag,在OSM中 “An OSM element should represent a single on-the-ground feature once and only once”作为一个基本规则,一般来说POI数据可以进行一级和二级分类,每个分类都有对应的行业和名称,这些分类在数据采集和应用中都是十分重要的信息,通常在OSM展示中依靠分类进行信息展示,而名称、地址、坐标在OSM展示和检索作为基础信息来使用。而兴趣是一个非常主观性非常强的词语,在特定的情况下例如用户想发一封电子邮件的时候,电话远远没有邮箱地址有趣。所以POI在不同使用场景下,对POI数据有不同需求,当一个POI数据平台提供一系列接口和数据输出的时候必须考虑不同场景下用户的需求和数据特点。

  通常我们将POI的信息划分为基础信息和详情信息,随着社会的发展,LBS、O2O服务相继出现,用户的需求也在不断演化:

    以前我们在网上搜索全聚德在北京有几个店,那个离自己最近,如何换乘地铁或公交,这时候地图是用来寻址规划路线的;

    现在我们直接搜索某个区域有什么店铺,那个评分更高服务更好,招牌菜是否符合口味,甚至直接团购下单,现在地图是为了生活服务的;

  这时候我们发现POI包含的信息演化包含了三个部分:

    1. 基础信息:名称、地址、坐标、别名、电话、分类等

    2. 详情信息:评分、菜单、价格、评论、团购信息、营业时间、图片等垂直行业信息。

    3. 挖掘信息:营业状态、可信度等挖掘产生的数据

    有了第1部分我们可以提供基础的检索服务,可以根据用户输入的名称或者当前位置检索到需要的特定类型的POI信息,完成用户的搜索需求;而第2部分可以优化一定场景下的用户体验或者提供高附加值的服务;第3部分数据优化用户体验,避免用户流失。    

  当然,在地图上POI可能不是一个点,而地图上点也未必是一个POI,如一个步行街、一片海滩又或者两条铁路的交叉口。通常人们会将步行街或者海滩这些区域简化为一个点也就是POI,而铁路的交叉口在地图上可能呈现一个点,可实际上并非一个POI或者有价值的POI,因此,地图上的点和POI实际并非一个概念,虽然我们通常将POI映射为一个点。

  地图数据的最终愿景是复刻这个世界,而POI则是这个愿景的基石。

2、POI数据处理流程

POI数据根据数据源不同,接入数据获取的信息会有所不同,但无非是基础数据和详情数据。

  数据接入后处理流程也可以统一为: 

    数据接入 => 数据标准化 => 数据判重 => 数据融合 => 数据发布 => 持续更新

    不同的数据在步骤中操作可能会有所差异,但是基本上都会遵循上述步骤,下面将逐一介绍每个步骤

    1. 数据接入:根据数据来源的不同接入方式也是多种多样,如图商的数据最为标准,通常为mid/mif的文件提供,此时转化为流程可处理的数据格式即可;互联网抓取的数据内容丰富但是遵循的规范多种多样,此时进行初步判断是否符合接入的条件以向下流转;合作方的数据相对标准,但业务侧重不同,而通常合作方的数据需要进行反馈数据接入时做好对账和反馈查询接口;ugc数据相对较少但是需要给与及时处理和反馈...。不同数据源数据重要性和数量级会所有不同,针对数据较大但是重要性相对较低的数据需要做好数据准入验证;对数据量少、但是重要的数据要有通用的对账和反馈机制,这会减少后期业务展开时的工作量。

    2. 数据标准化:数据标准化一般包含三部分内容:1)字段对齐,对于某些数据源相同内容字段名称可能不一致,此时将其转换为统一的名称和路径;计算分类、状态等字段值补全到数据中;2)数据正确性验证,例如根据坐标校验地址的省市区划是否一致,3)剔除部分分类的数据或者触发黑名单数据,如涉黑涉恐等违法数据类型。标准化的过程不复杂但会随着接入数据源的增加而变得繁琐,因此一个健壮的可配置的标准化服务可以使得后续工作事半功倍。

    3. 数据判重:数据源接入后如何判断新接入数据是否与原有的数据重复,也就说新接入的了某个数据源的POI如果当前已经有了这个POI那么应该将新增的POI与原有的POI融合并更新原有的POI信息,如果当前没有该POI,那么应使用新接入的POI独立新增一个POI数据到自己的系统。判重流程比较负责,在这里暂不详述,简单说是将已有的POI的关键信息建立倒排索引,根据新增的POI的信息查询倒排索引,根据倒排索引返回的POI列表计算相似度,如果有相似度达到阈值的那么判断为重复。

    4. 数据融合:是将不同来源标识相同的POI的数据融合为一条数据,这条数据在各个源中的数据选择最可靠的基础数据,和不同业务的详情数生成一条POI。这条POI可以满足不同的业务需求。

    5. 数据发布:数据发布指数据融合得到的POI数据推送到各个业务方进行线上操作。同数据接入一样,发布对接多个业务方,根据不同的业务进行数据适配和校验,一个通用的发布模式是十分必要。

    6. 数据更新:数据生成是一个持续交付过程,数据不断采集和融合,数据也会不断更新,数据发布的交付也是一个持续的过程。

3、POI数据存储

POI数据存储是指在整个数据处理过程产生的结果数据和中间数据的记录和存储,在这个过程中不同的数据存储的目的也不尽相同。

  为了描述方便,我们这里将数据接入的poI称为pp,融合后产生的结果称为poi

  按照目的不同,我们将数据存储分为若干类:

  1. 数据输出:计算流程的结果,也就是POI数据,是最重要的数据。

  2. 数据计算:计算流程的中间结果,例如每个已接入的pp数据的规范化输出(我们输出的POI是若干判定为相同pp融合产生的POI,那么每个接入pp规范化的结果在每次融合的时候都会用到)

  3. 历史追踪:或者说问题排查或者数据变更分析,历史POI的历史是如何变更的,如在高德地图搜索古北水镇,返回结果包含了古北水镇的位置,电话,售票信息以及评论,这些数据可能来自多个数据源,我们假设古北水镇的位置信息来源于高德自己的数据生产,售票信息来自飞猪等平台数据,评论来自大众点评等平台,而这三个源的pp分别接入,那么该poi的数据就会由最开始的基础信息,逐步增加售票信息和评论信息,该数据与关联的原始poi数据是对应的,以此来发现分析问题。

  不同目的的数据,可能存储的数据是相同的,例如poi,数据输出给用户或者业务方的融合后结果数据,而此数据在数据计算过程中也会用到,在历史追踪过程中对poi的变化也就是记录每次poi融合的结果数据。对于数据输出根据输出方式不同,存储方式也会不同,如用户需要实时查询那么比较适合的方式应该是kv数据库,当然关系型数据库满足性能情况下也是可以的,但是当数据需要批量输出时候,尤其是涉及到全国poi数据时候(当期高德、百度地图、腾讯地图的poi总量均达到7千万左右)数据库显然不能满足需求,这个时候最好通过hive进行数据输出;而历史关系数据因为需要根据id查询多个历史版本,这时候比较好的方式应该是hbase或者高性价比的kv数据库。

  在这个过程中,数据输出和数据计算是必须满足稳定且高效的性能要求,是最紧迫的需求,相反的历史追踪功能,不会影响当前线上服务,不那么紧迫,而其数据存储量远远超过1,2需求,因此可以牺牲部分性能要求去实现。

从大学到研究生,也算是从事GIS行业7年了,这是这7年来积累的全国POI兴趣点数据,数据量还是挺大的,有从事GIS行业的同学可以一起交流讨论。

4、POI数据发布和保障

POI数据发布:

     数据发布方式有多种,具体方式和需求由业务决定,发布方式主要分为两类,一类是通过数据打包整体发布,一类是通过api请求逐条调用。

     1. 打包整体发布:通过提取归档数据,根据业务需求的模板进行数据提取转换,将数据以文件形式推送到需求端,该方式适用于有独立处理数据并提供业务服务的情况;

     2. 通过api请求:该方式通过服务调用请求数据,以数据id进行数据查询,或者类似地图查询以关键词进行数据匹配。

  第一种方式数据发布量大,如果发布全国的POI数据那么将是超过五千万的数据量,数据发布和加载时间将是一个较长的过程,这决定了打包发布不会是一个实时的数据方案,该方案适用于数据量大,但是实时性不强的情况

  第二种方案,实时性强,但是数据量因为服务请求的原因,受限于服务qps限制数据量无法达到较大的量级,即便qps达到满足较短时间内同步全量数据,也难以保证数据的全量更新,这种方式提供实时的数据查询,无需进行数据全量的保证,只需保证服务请求数据准确性和实时性。

  两种发布方案虽然方式不同,但是同为发布需要满足发布的基本需求:1. 正确性   2. 实时性   

  1. 正确性,包含两个因素,单条数据的准确性,数据整体的正确性

    单条数据的准确性可以通过字段校验来提供保证,字段校验是针对字段类型和值范围的校验,对每条数据进行字段校验可以保证一定的数据正确性

    数据整体正确性,可以通过数据差分来进行保证,对上一次发布的数据进行数据比对:数据上线和下线数据量的比较,在线数据更新字段变更值的比较,通过字段变化率的比较可以确定新的数据和历史数据变化情况可以确定数据没有因为策略异常或者服务异常造成的数据错误。当数据差异率超过阈值的时候需要进行人工介入,确定数据变更是否符合策略预期。

  2. 实时性,打包发布只要保证数据发布成功可以保证实时性,api请求需要保证数据同步正常服务稳定

5、POI数据校验 

POI数据校验是POI数据正确性的保证,而针对结果校验是数据发布正确性的最后一道保障,所以对数据校验需要在多个纬度进行,力求POI的正确性。

  数据变更主要分为状态变更、关键字段变更以及详情字段变更。其中状态变更影响最大,可以造成线上POI的上下线状态改变,而基础字段和详情字段则会影响业务的正确性。须知数据变更引起的原因有多种,基本可以分为3类:

      1. 数据来源变更   

      2. 处理策略变更   

      3. 系统性错误

  1.  数据来源变更,数据新增、下线接入来源或者既有来源的大量数据变更都可能造成POI数据变化;

  2. 处理策略变更,处理过程中针对状态或者关键字段的策略变化会引起数据变化,例如新增一个名称过滤策略,如果名称不合法则将数据直接过滤下线,如果这个策略影响面较大会造成数据的大面积下线;而如果名称策略只是将不合法字符屏蔽那么数据会上线,而名字可能和实际POI有出入。

  3.  系统性错误则是指在处理过程中bug造成的数据错误,这种错误影响的数据会比较集中造成的数据面影响会比较大,但是也最容易发现,只需比较新的数据结果与上一版本数据是否变更,变更率是否有明显变化则可以迅速预警数据系统性错误。

  数据校验:

    字段校验: POI数据字段的值类型,取值范围的校验,实现过程可以将规则写入配置,当规则有变化时可以通过修改配置实现与代码分离

    规则校验:对数据整体设置校验规则,如某个字段必须有值以及和某个字段有校验规则,某个字段有值率的占比,当不符合规则时则进行拦截

    变更校验:比较本次发布数据和上一次发布数据的变更,包括数据新增和下线,以及两次发布同时存在的数据字段的变更,当没有变更时名称、地址、坐标作为关键字段其变化率应少于1‰,如果变更多余该值则应该确认数据来源、策略是否有变更,且变更结果符合预期。

  因此数据校验和策略、数据接入应进行联动;当数据接入有变化时如数据在一段时间内接入数据变化可能引起的POI集合变化;数据策略变更引起的结果变化以及预期的结果应有告知的流程,并与校验的结果互相印证;当变更预期与预先设计不符时,应该引入人工评测,评估本次数据变更是否对数据有积极影响,判断是否上线。

6、POI数据变更校验

变更校验:比较本次发布数据和上一次发布数据的变更,包括数据新增和下线,以及两次发布同时存在的数据字段的变更,当没有变更时名称、地址、坐标作为关键字段其变化率应少于1‰,如果变更多余该值则应该确认数据来源、策略是否有变更,且变更结果符合预期。

  变化维度:数值变更(变更范围);字段存续变更;POI存续变更

  变化体现:数据变更数据值大小,如果非数值类型可能体现为数据长短变化;

       字段存续是变更是指数据POI某个字段可能因为某种原因缺失,可能是正常也可能是因为字段产生过程数据丢失;

       POI存续是指poi的新增或者下线在两次发布中出现新增和丢失的情况;

  校验方式:

数值变更:数值不同数据校验方式不同,如经纬度字段,因为经纬度经度问题,其值每次取值会有不同,如果单纯因为字段取值不同进行判定则可能造成误报,按照经纬度取值经可以截取小数点后五位进行判定,或者将前后版本经纬度进行距离计算,如果距离在30米范围内可以认为位置没有变化;如果字段值为字段或者数组等结构体,甚至包含二级、三级的键值的时候那么比对将相对麻烦,尤其是结构体可能将值转为string类型时可能无法以通用的手段进行比较。此时可以根据字段配置表进行数据比较,比对到相对字段配置表指定的数据层级,将字段大小变更纳入比对策略。
字段存续变更:根据配置字段比较两个版本字段是否存在
POI新增减少,只比POIid和上一版本的新增或者减少即可
  报警策略:三个校验的关键在于报警阈值的设定,根据多个版本的变化数据进行比较,获得数据报警阈值的。

  相应报警数据还需要报警后的问题分析,如数据变更范围,数据类型,数据变化较大的数据地理区域,数据分类,数据源组成方便问题定位分析

7、突发事件的下POI数据应对策略

近日来武汉新型肺炎对地图行业的及时应对提出了考验,大量和疫情的POI需要上线,很多服务行业、电影院,景区等POI暂停营业。这些信息在地图上显示和POI实际状态是否相同,能否真实的反映现实世界,是否能为用户提供有价值的信息。

  相关的POI信息变化可以分为三类:

    1.  新增的医疗的地点,如发热门诊

    2. 停止运营的交通设施,如地铁、长途客运、火车站点

    3. 停止营业的景点、餐饮、电影院等娱乐场所

  数据搜集方式有多种,其中较为简单有效的是人工运营,新增医疗地点,发热门诊的信息可以有运营人员关注官方发布的信息,微博以及各个重点医院的公告信息,获取第1类的信息,这些信息数据量相对较小,且相对重要,需要人工运营确认,此类信息人工运营较为合适。第二类信息和第一类相似,但是具体信息则相对负责,如长途客运停运公告,可能涉及线路只有几条,但是每条线路涉及的站点则十倍二十倍增长。第三类则数据量相对较大,且分布广泛,不能简单按照时间类型进行处理,需要实时抓取商户公告信息,这需要多个渠道获取信息的能力,如公众号、企业新闻公告,和poi关联处理,不过这需要研发预先开发信息获取渠道、以及相应的处理上线能力。第一类和第二类数据量级和重要性相似,但是信息不同,第一类需要匹配相应的坐标、名称,第二类只是状态变更;在数据变化方面第二类和第三类相同。

  数据上线方式,第一类则需要数据动态新增或者增量更新,第二类可由人工操作后动态更新,第三类可以动态新增,但是没有信息获取渠道和处理流程的时候手动操作较为复杂且数较大,可以由客户端新增策略进行话术提示。但是根据策略和分类进行批量处理较为笼统,需要用户确认商户状态对用户体验较差。最好的处理方法是增强信息获取渠道和处理上线能力。

 交流学习QQ:1148212080

posted @ 2020-06-16 10:33  豌豆创意工作室  阅读(2947)  评论(0编辑  收藏  举报