文|济南市房产测绘研究院 马亚敏 李春光 李守鹏 王姣 李鲁锋
【关键字】智慧住建一张图;住建数据全生命周期;数据更新;工地防疫
现今,住建部门掌握全量的城镇住房和房建项目信息,以济南市为例,截止至2022 年6 月,住建数字化信息总数据量过13.8T,总记录数超9.7 亿条,每日新增超5 万条,涉及用地规划、工程规划、项目招投标、施工图审查、施工许可、配套费征收、扬尘监测、房产测绘、房产交易、维修资金、物业管理、房屋安全、城市更新、老旧小区、房改房、公房等21 大类业务数据,以及矢量底图、遥感影像、房屋基础幢面、物业区范围、房屋底层数据普查、既有建筑抗震普查、自然灾害风险普查、城市房屋建筑违法违规专项清查、土地招拍挂等28 类空间数据,如何有效的管理这些海量数据,并充分分析挖掘数据内在价值,是本文研究的出发点和动力。
目前,为了提高数据的稳定性,数据更新模式较独立,同业务处室分管的业务多个系统之间可以实现数据共享及更新,不同处室分管的业务系统之间一般为定期批量的进行数据更新与共享,难以保持数据的时效性与正确性,住建所有业务系统之间保持数据的一致性与正确性,有效的数据共享更新的解决方案是当下迫切需要的。
根据《济南市数字政府建设实施方案(2019-2022 年)》,加快推进智慧住建“1114+N”规划建设[1],借助信息化、智慧化技术手段,推进基于GIS 技术的“智慧住建一张图”管理系统建设,基础数据管理全覆盖和业务数据全融合,做到“数出一源”,全面实现住建行业智慧管理,完善智慧图审、智慧建筑、智慧工地、智慧物业、智慧租赁等功能[2]。本文结合“智慧住建一张图”,深入分析“智慧住建”大数据,得到“住建数据全生命周期模型”和基于业务驱动和ETL 技术的两种数据更新模式,助力“智慧住建一张图”建设和推广应用。
“智慧住建一张图”大数据,根据其表现形式,分为业务数据和地图数据。业务数据不带有空间属性,是住建系统日常运行产生的数据;地图数据带有空间信息,在“一张图”上可视化的数据,配合业务数据,让呆板的数据生动形象,展示结果直击重点。如扬工地扬尘监测信息,其业务数据以列表形式表现(图1),毫无感染力,重点不突出。
图1 扬尘监测信息列表
扬尘监测地图数据将在建工程项目的扬尘监测位置可视化的展示在一张图上,并赋予了监测位置业务属性信息,如图2,空气质量等级,让系统用户一目了然,可以直观的了解“济南高新万达广场项目8#地块”正处于土方开挖阶段,空气污染比较严重,相关部门应重点关注,并根据风速和风向数据,可以估算对周边具体区域的影响,如图3,超过阈值时,需采取强制措施。
图2 扬尘监测地图分布
图3 受扬尘影响较大的在建工程信息
“智慧住建一张图”将住建业务数据和地图数据完美融合,给业务数据赋予空间位置和业务关注要点,产生比单一数据或多种数据组合而更有价值的高级信息,创造出1+1>2 的效果,为政府部门提供有效的决策支撑。
本文深入住建局各处室调研分析,梳理出以济南市为例的项目全生命周期模型,下图4 所示,共分为五大阶段,立项阶段、土地规划阶段、工程建设阶段、交付阶段和灭失阶段,住建业务全部的数据均产生于该项目全生命周期的五大阶段。
图4 住建项目全生命周期
并结合济南市住建局下属的建设工程招投标系统、济南市质量安全监督管理系统、扬尘网格化管理系统、济南市房产交易管理系统、维修基金和保障性住房电子票据应用系统、济南市国有土地上房屋征收信息系统等39 个业务系统所生产业务数据的种类,最终将住建业务数据整合为“房建工程”和“住房管理”两个大类。
以“房建工程”和“住房管理”两大核心业务为数据源头,初步摸索出“住建数据全生命周期”的数据模型。从一块土地开始规划使用,到项目施工建设,到商品房网签、物业管理最后到征收拆迁、城市更新收回土地,整个生命周期共分为21个节点。按业务数据产生时间先后,该生命周期21 个节点具体为:
1-项目立项,2-用地规划许可,3-工程规划许可,4-项目招投标,5-施工图审查,6-施工许可,7-配套费征收,8-扬尘监测,9-工地实名制,10-工程质量与安全监督,11-预售许可,12-竣工验收,13-房产测绘,14-房产交易,15-维修资金管理,16-房地产市场监管,17-物业管理,18-住房保障,19-房屋普查,20-征收拆迁,21-城市更新。
本文以房建工程和住房管理全生命周期为基线,将住建系统业务数据串联融合在一起,形成一个有机的整体,是开展“智慧住建一张图”系统建设的基石。
“智慧住建一张图”运用GIS 技术将住建全生命周期数据展示到地图上,谋求业务数据和空间地理信息数据相结合。在地图上可直观的反映业务信息,同时可通过业务数据定位地图位置,将业务同空间位置联动,在地图上综合分析各业务数据,实现以图管房建项目,以图管住房的数字化、时空化管控。
截止2022 年6 月底,济南市通过房屋底层数据普查项目,共整理出490 万个房屋幢面图斑,给每个房屋幢面计算其几何中心作为其质心编码属性。住建空间数据以房屋幢面为基础,关联各房屋类业务数据,给每类业务数据赋予关联幢面的质心编码,可视化展示在“一张图”上。
业务专题图是将某类业务数据按照关注的属性信息分类展示,如图6 房屋安全专题图,按房屋类型分为:市直管公房-蓝色气泡,汛期危房-橙色气泡,安全鉴定房屋-绿色气泡,气泡上的ABCD 字母代表危险等级,危险程度依次递增,A 级指房屋完全能够正常使用,B 级指基本能够正常使用,C 级指有点危险需要加固,D 级指房屋整体很危险需要拆除。通过业务专题图,实现业务数据的可视化,能直观地在一张图上抓住关注重点,对各专题进行综合分析,挖掘数据价值。
图5 住建业务数据全生命周期
图6 房屋安全专题图
本文根据梳理的住建数据全生命周期的21 个节点,将涉及到的相关业务关键属性进行融合并赋予房屋幢面质心编码,梳理整合了房产测绘档案专题图、商品房网签专题图、存量房网签专题图、维修资金专题图、物业管理专题图、保障性住房专题图、房改房专题图、直管公房专题图、征收拆迁专题图、城市更新专题图、老旧小区专题图、加装电梯专题图、在建停车场项目专题图、房地产市场监测专题图、近三年土地招拍挂专题图、城建档案专题图、12345 热线专题图、基础房屋普查专题图、自然灾害普查专题图、抗震普查专题图、城市房屋建筑违法违规清查专题图、自建房普查专题图、在建工程专题图、扬尘监测专题图等25 类业务专题图。
其中商品房网签数据是较为重点关注的业务数据,因此在全局-小比例尺和局部-大比例尺两种模式下分别进行专题展示。小比例尺模式下,可查看全市商品房网签价格的热力图,如图7 所示,红色越艳丽表明网签价格越高,其中左侧面板展示了济南市各区县的网签均价、近一年各月份网签均价、近一年各月份成交总金额这三类统计信息。
图7 商品房网签专题图-热力图
大比例尺模式下,可查看每幢楼的网签情况,如图8 所示。
图8 商品房网签专题图-气泡图
基于上述这25 类业务专题图,可基本满足住建局日常数据调度分析工作,并可深入分析住建数据内在联系和变化趋势,为行业发展和科学决策提供依据。
由于住建系统业务有着数据量大、变化快、变动大等特点,为保证房屋业务数据时效性,需要制定有效的数据抽取、空间化和更新入库的解决方案,通过分析各类业务数据实时性的要求,最终更新方案确定为以下两种:
(1)实时更新:基于业务驱动,通过数据接口,实现跨系统的数据同步更新。
(2)批量更新:借助kettle 软件对数据进行批量抽取、匹配、更新。
业务系统产生数据后,会触发关联业务系统的监听接口,及时捕获数据更新操作并提取变化数据。如济南市房产交易相关的系统就有3 个:交易GIS 系统、济南市房产交易管理系统和济南市房产GIS 管理系统,这三个系统均使用 “房屋用途”这个元数据,其中济南市房产GIS 管理系统生产“房屋用途”数据。为了保证“房屋用途”的实时一致性,因此采用这种基于业务驱动的实时更新模式,只要在房产GIS 管理系统新增、编辑和删除“房屋用途”,就会触发其他两个系统的监听接口,提取这些变化的“房屋用途”,并在各自系统验证无误后,进行更新入库。
基于业务驱动的实时更新模式另一个重要的应用是保证业务数据空间化过程中业务库和空间库的实时一致性[3-7]。第2 章梳理的21 大类业务数据均没有空间坐标信息,要在“一张图”中可视化展示的第一步就是进行业务数据空间化,其具体过程为:
(1)房产GIS 管理系系统中生产的基础幢表、基础户室、测绘房屋面表作为基础数据,其中基础幢表和测绘房屋面的关联字段为“楼幢编码”,具有唯一性;基础幢表和基础户室表的关联字段是“楼幢ID”,也具有唯一性;为每一测绘房屋面计算质心作为房屋面的唯一几何编码-“质心编码”;将房屋面的“质心编码”通过关联关系,更新至基础户室表中。
(2)将商品房网签、存量房网签、维修资金、保障房、房改房、公房、房产测绘档案数据等匹配基础户室表,获取其对应的“质心编码”后,触发“一张图”系统接口,将匹配的“质心编码”更新至“一张图”业务成果库和空间库,在“一张图”平台上即可实时看到业务数据空间化效果和已完成数据量。
基于ETL 技术的批量更新模式,主要适用于实时性要求不高的业务数据的更新,如每天、每周、每月的更新频率,如商品房网签数据、维修资金数据等。更新方案是将源数据获取存放在Postgresql(PG)数据库中,运行Kettle 软件中写好的匹配脚本完成数据匹配工作,再将匹配好的数据传输至目标数据库的一个流程。整个方案主要涉及数据库连接、构建数据传输文件、编写自动匹配的脚本和制定数据动态更新技术路线[8-10]。
制定数据动态更新技术路线是基于ETL 技术批量更新的核心,该模式基于时间概念制定的数据动态更新技术路线是根据源数据表内涵的时间字段,该字段可以记录每条数据增加或者更新的时间,通过在SQL 语句上添加where 条件实现对已存在的、未变化的历史数据进行过滤,每次都只抽取新数据。方案主要包括创建时间戳存储表、获取时间戳并设置变量、添加数据转换文件、更新时间戳。如图9 所示。
图9 数据动态获取方案
自2021 年7 月 至2022 年6 月,基 于ETL 技术批量取更新抽数据量汇总,如表1。
2022 年4 中旬月至5 月初,济南建设工地疫情形势严峻,我们积极响应“疫情就是命令,防控就是责任”的号召,第一时间参与市建设工地疫情防控工作专班,有力支援了建设工地疫情防控工作,为全济南市疫情防控工作取得阶段性胜利,做出了突出贡献。
我们团队深入分析济南市2041 个建设工地,类型(园林、交通、房建、水利)、所属区县、项目负责人及23 万余工地人员等在建项目数据和卫健委核酸检测数据,在“一张图”框架下建设了“工地防疫一张图”,如图10。
图10 工地防疫一张图
将“疫情三区图”与“在建工程项目图”叠加分析,得到“封控区、管控区、防范区”三区内的在建项目详情,如图11,三区内的项目工地人员是需要重点关注的。
图11 管控区内在建项目
通过济南卫健委核酸检测信息接口,实时抽取工地23 万余人的核酸信息,与本地人员库进行核对,排查出“未核酸”人员,如图12,及其所在区县、项目,通报给各区县负责人,敦促全所有工地人员全员核酸,及时监控工地人员核酸异常,助力济南疫情防控。
图12 项目人员核酸信息
本文结合济南住建行业的业务管理和“一张图”可视化应用,深入分析了住建行业21 大类业务数据和28 大类空间数据,制定了基于业务驱动的实时更新和基于ETL 技术的批量更新两种更新方案,并在济南疫情期间,积极响应政府号召,有力支援建设工地疫情防控工作,取得了较好的应用效果。但是目前总结的21 大类业务数据中还有更细的子类,比如商品房网签数据,包括网签人员信息、网签合同信息、变更信息、基础幢信息、户室信息等,需要再深入梳理。并且,在空间数据更新方面,目前未找到较好的增量更新模式,还需要进行再分析再研究,找到一条高效的更新途径。