智慧城管数据架构设计Word文件下载.docx
《智慧城管数据架构设计Word文件下载.docx》由会员分享，可在线阅读，更多相关《智慧城管数据架构设计Word文件下载.docx（45页珍藏版）》请在冰点文库上搜索。
通过地理编码技术对城市部件进行分类分项管理，最终实现城市管理山盲LI到精确,山人工管理到信息管理的转变。
地理编码数据类型可分为行政区域地名、地片与小区地名、街巷地名、门（楼）牌地址、标志物地址、兴趣点地址。
行政区域地名
行政区域地名应包含市、区、街道（乡镇）信息，宜包含社区（村）信息和单元网格信息。
行政区域的基本地点名称应与标准地名一致，是描述该行政区域名称的最小单元。
行政区域可通过代码信息进行地理坐标的匹配，其编码规则应符合《城市市政监管信息化单元网格划分与编码》的规定。
地片与小区地名
地片与小区地名应包含地片名称、居住小区名称的信息。
地片与小区的基本地点名称应为标准地名，是描述地片、居住小区最小单元。
街巷地名
街巷地名应包含有地名标牌的街巷等。
街巷地名的基本地点名称应为街牌和巷牌标示的汉字名称，是描述街巷地名信息的最小单元。
2.1.3.单元网格数据
根据国标《数字化城市管理信息系统第1部分：
单元网格》标准规范要求，结合城市地理空间特点划分智慧城管单元网格和责任网格。
单元网格是指智慧城管的基本管理单元，是基于大比例尺地形数据，根据智慧城管的需要，按照一定原则划分的、边界清晰的多边形地理区域（面积约为10000m2）o以路、街为主体，形成不跨越社区管理的最小单元网格，即社区图与单元网格图重叠，构成智慧城管单元网格。
责任网格是指在单元网格基础上建立的城市管理监督责任区域，是城市管理信息采集员的基本工作区域。
单元网格数据的建设规范按照国标《数字化城市管理信息系统第1部分：
单元网格》编写。
2.13.1.单元网格的划分
单元网格数据包括行政区界、街道界、社区界以及单元网格界，以上数据均为面状。
单元网格的划分应综合考虑以下原则：
法定基础原则：
单元网格的划分应基于法定的地形测量数据进行，地形测量数据比例尺一般以1/500或于1/1000为宜，但不应小于1/2000o
属地管理原则：
单元网格的最大边界为社区的边界，不应跨社区分割。
地理布局原则：
按照城市中的街巷、院落、公共绿地、广场、桥梁、空地、河流、山丘、湖泊等自然地理布局进行划分。
现状管理原则：
为强化和实施有效管理，单位自主管理的独立院落超过10000m2时，不应拆分，以单位独立院落为单元进行划分。
方便管理原则：
为方便实施管理，应尽可能使管理路径便捷。
负载均衡原则：
兼顾建筑物、管理部件的完整性，单元网格的边界不应穿越建筑物、管理部件，并使各单元网格内的管理部件的数量大致均衡。
无缝拼接原则：
单元网格之间的边界应无缝拼接，不应重叠。
相对稳定原则：
单元网格的划分宜保持相对稳定。
单元网格划分除遵循上述原则外，还应注意：
任意一个下级区域（社区对于街道，下同）必须完全包含于上级区域（街道对于社区，下同）内；
与其它区县相邻的街道办事处边界必须和区边界吻合；
下级区域与所属上级区域如有接边，必须正确接边；
同级区域（街道与街道，或者社区与社区，下同）必须正确接边，不能互相叠压。
2.13.2.单元网格编码
一个单元网格在时间和空间定义上应有一个唯一的编码，单元网格变更时,其原代码不应占用，变更后的单元网格按照原有编码规则进行扩展。
单元网格编码由14位数字组成，依次为：
6位县级及县级以上行政区划代码、3位街道（镇）代码、3位社区代码和2位单元网格顺序码，编码结构如下图-4所示：
□□□□□□□□□□□□□□
图-4编码结构图
2.13.3.单元网格数据要求
1.时间要求
是描述单元网格的重要的属性数据之一，它记录了单元网格划分与变更的历史过程。
分为：
初始时间：
第一次划分单元网格的时间。
变更时间：
原有的单元网格进行再定义的时间。
时间信息的记录应使用8位日期格式，以YYYYMMDD的方式表达。
2.计量单位要求
单元网格数据应以法定计量单位进行描述，其中，面积的计量单位为平方米、长度的计量单位为米。
3.单元网格空间要求
单元网格的儿何特征为面状，面与面之间应具有拓扑关系。
单元网格数据采用的坐标系应与所在城市基础测绘的坐标系一致。
组成单元网格的多边形角点的定位中误差应不超过±
lm。
4.属性要求
单元网格数据包括单元网格编码、面积、初始时间、变更时间以及备注等。
2・1・3・4•责任网格的划分
监督网格是指在单元网格基础上建立的城市管理监督责任区域，是城市管理
信息采集员的基本匸作区域。
监督网格以划分的单元网格为基础，将相邻或相近的儿个单元网格合并为一个监督网格，划分时应考虑实际地理范围和方便监督责任人的实际工作。
可参考图
L201010001
1201010佃
1Z01010014
120】036
】201010017
120101
126018饴
220L0103凶
1201010010
120101OOD7
图・5监督网格划分示意图
2.1.4.事部件普查
城市部件数据普查工作在数字城管系统建设中非常重要，是系统建设和运行的前提和基础，其U的是要建立稳定、适用、合理、科学的单元网格数据库、城市部件数据库、地理空间框架数据库，为数字城管系统建设和运行提供必要的空间数据支持与地理信息服务。
这项工作完成的好坏不仅与空间数据库的质量好坏息息相关，而且将直接影响到整个系统的运行效率和运行效果，所以在项LI建设中具有非常重要的意义。
2.1.4.1.普查范围
本次智慧城管的普查范围为3.6平方公里xx县主城区面积。
（1）对城市道路范圉内的规定部件全部普查，道路两侧有建筑物的普查到临街房屋墙角线或围墙；
对于道路两侧是开阔区域（没有建筑物或者较远建筑物是破房子的），范围是路基线（有人行道按人行道算，没有按机动车道算）向外延伸5米；
（2）公共开放的广场及公共场所对其范围内进行普查，对相对封闭管理的小区、公园、单位范围内部不进行普查；
开放或半开放式城市居住小区对其主要内部道路（6米以上含6米道路，如果开放或半开放式居住小区主要道路小于6米也要普查）范围及其两侧区域进行普查，其他楼宇间的小通道、绿地区域不进行普查；
对老式居住区（含城中村、巷弄居民区等）普查其主要通道（含人行道4米含4米以上，对有文物遗址、名人故居、政府单位、学校、商业街等不足4米的道路也要普查）范围及其两侧区域进行普查，其他区域不普查。
（3）对于将拆迁区域不予普查，以政府公告为准。
2.1.5.普查要求
2・1・5・1•部件普查精度要求
依据《数字化城市管理信息系统第2部分:
管理部件和事件»
（GB/T30428.2-
2013）标准要求，部件普查精度须满足表-4要求：
表-4部件普查类型表
序号
精度等级
精度要求
（m）
说明
1
一类
<
0.5
给水井盖，污水井盖，雨水井盖，中水井盖、雨水算子，电力井盖，路灯（灯光）井盖，电信井盖，电视井盖，网络井盖，热力井盖，燃气井盖，公安井盖，消防设施，不明井盖，电信交接箱，电杆路灯，地灯，射灯，防蚊闸，国防井盖，有线电视交接箱，饰灯，停车咪表，出租车站牌，交通控制箱，路名牌，闭路监控电子眼，地铁站指示牌，公厕指示牌，洒水车供水器，古树名木，行道
树，树池算子，花架、花钵，护树设施
2
二类
2.0
电力设备，报刊亭，电话亭，邮筒，信息亭，自动售货亭，健身设施，高压线铁塔，路灯（灯光）变压器，路灯（灯光）配电房，路灯（灯光）配电箱，公交站亭，交通标志牌，存车支架，交通电子告示牌，交通岗亭，地铁通风口，地铁出入口，公共厕所，公厕化粪池，垃圾站，果皮箱，灯箱霓虹灯，广告牌匾，环境监测塔，环卫工具房，垃圾容器，垃圾容器间，毒鼠屋，绿地，雕塑，街头坐椅，喷泉喷灌，绿地护栏、防撞柱，园林建筑小品，绿地护坡，宣传栏
3
三类
10.0
指空间位置概略表达的部件，如桥、停车场、工地等。
2・1・5・2•部件普查考核指标
参照全国数字化城市管理先行城市经验，部件普查成果的考核建议釆用抽查方式，为避免普查与验收时间间隔过长导致的部件位置、属性等变化，原则上,部件普查验收应在数据普查单位提出申请后三个月内，山业主单位和监理单位随机选定至少三块区域，总面积不得低于普查总面积的5%o
部件普查位置偏差指标
每平方公里内位置误差超出允许范围的个数与该范用内部件总数之比超过1%时为不合格。
部件普查遗漏指标
每平方公里内遗漏个数不得超出总数的5%,否则为不合格。
部件普查属性错误指标
部件权属属性是部件普查的重要内容，每平方公里内部件属性错误个数不得超出部件总数的1%,否则为不合格。
针对无主部件，在普查完成后应统一提交监理及业主，经过业主协调应进一步确认部件的权属，业主协调后仍无法确权的部件，确定为无主，其权属属性为无主，不视为属性错误；
2.1.6.成果提交
在完成数据建设后，将根据各个阶段的普查内容进行成果的提交，主要包含以下儿个方面：
2・1・6丄资料的提交
在外业调查工作完成并通过自检后，将向质量审核小组和内业数据建库组移交，外业调查完成的资料移交需办理资料交接手续，填写资料交接单，并由移交人和接收人签字，程序如下：
培训后，技术组向各作业小组移交调查技术设计方案；
外业调查图、调查表、调查的属性数据文件、图历簿，山外业调查组负责人向质量检查组移交，质量检查组检查后移交给内业处理组。
在移交时需要注意如下事项：
1.资料是否齐全；
2.调查图、调查表是否已有所有相关人员签字，并装订成册；
3.移交时必须填写《部件调查工作流程控制表》并签字；
4.相关电子文档是否已经刻录并做到双备份。
资料的提交主要包含以下方面：
部件分类与编码资料：
•所有野外调查图、调查表；
•全部电子数据文件的光盘，要求GIS格式；
•所有部件照片原始电子文件；
•工作总结报告书；
•质量检查验收报告。
地址普査成果：
•所有野外调查图、调查表;
•全部电子数据文件的光盘，要求为GIS数据格式；
2・1・6・2•数据的提交
1.部件数据均按GIS数据格式提供；
2.部件普查的每个小类为一个独立的图层，不应分块或分区提供，釆用城市独立坐标系；
3.所有图层提供整幅数据；
4.对于每一个图层文件的命名，按照小类的名称命名。
部件图层类型有点状、线状的也有面状的，按照实际情况确定。
2丄6・3・单元网格数据成果提交
网格数据按照图层名称进行分类，每一个小类为一个单独的图层。
对于数据
文件的命名按照该图层数据的内容来命名，参考表-5所示：
表-5网格数据按照图层表
图层名称
图层类型
备注
行政图
面状
街道图
补区图
单元网格图
2丄6・4•部件分类与编码数据提交
部件数据以住建部标准为基准，按照小类进行划分，每一个小类为一个单独的图层，不应分块或分区提供，按照shp格式以本项LI建设的范R］整幅提交。
如果有扩展的部件，同样按照部件的小类整幅、分层提供，同时还需提供该小类对应的部件符号库字体文件（ttf格式）和图示。
对于每一个图层数据文件的命名，按照小类的名称命名。
部件图层类型有点状、线状的也有面状的，按照实际情况确定，所有数据以光盘形式提交。
2・1・6・5•地理编码普查数据提交
根据住建部有关标准规范和已划分的城市管理万米单元网格和监督网格，编制单元网格图集手册和监督网格图集手册。
2.1.7.实景三维数据影像建设
2・1・7・1•三维实景建设范围
根据项口要求，三维实景建设范围主要包括xx县主城区3.6平方公里实景影像数据。
2.1.7.2.三维实景数据采集与建库提交
城市三维实景影像数据采集基于移动测量系统（MMS）技术，可安全、高效地完成城市部件普查工作的同时，并建立城市连续可量测实景影像库，使传统平面的网格管理升级为实景可视化的立体网格管理，还可结合可视化测量功能在违章建筑、市政管理、园林管理、门前五包管理及城市应急指挥管理上创造崭新的管理模式。
城市实景三维影像釆集采用移动道路测量系统进行可量测实景影像库和360度连续全景影像采集与建库：
采用移动道路测量系统采集规定普查范围内的可量测实景影像和360度连续全景影像进行采集、处理与建库。
要求全部采用大文件格式存储。
实景三维数据的建设范围建议为：
数据普查范圉内管理区域的主干道、部分支干道路，以及建设范围内的公园、广场、市场、车站、中心商业区、等约3.6平方公里，以后可根据实际需要进行适当扩展。
现有城管系统多基于二维地图构建，二维地图数据在信息量、数据表现形式和使用方便性等方面存在诸多局限；
二维地图信息量有限，不能显示细致的城市环境信息；
数据平面化，不能有效支持城市立面U标的管理等。
随着近年来测绘技术、计算机与网络技术的迅速发展，实景化影像地图高新技术应运而生，它以一种可量测影像直接反映制图物体的地图。
实景化影像是现实空间的真实写照，它以一种完全真实的方式来展现空间，在影像所表达的世界里包含着大量的地理、环境、社会、经济的、人文的信息及可供挖掘知识。
把影像地图无缝的集成到城管系统中，真实的表达现实世界，更好的支持网格管理、市容环境、突发事件等各方面的业务应用显得尤为迫切，为此需要对原城管系统扩展实景化影像进行升级改造。
在基于移动测量系统（MMS）技术可安全、高效地完成城市部件普查工作的同时，并建立城市连续可量测实景影像库，使传统平面的网格管理升级为实景可视化的立体网格管理，还可结合可视化测量功能在违章建筑和广告牌管理、市政园林管理、门前五包管理及城市应急指挥管理上创造崭新的管理模式，可如图-6所示：
图-6实景三维数据管理示意图
2.2.数据处理
数据处理是智慧城管数据基础数据建设的一个重要内容，它连接着业务应用系统，实现从智慧城管相关信息系统中采集数据，并建立综合数据库，实现数据积累，为数据统计、分析、挖掘做准备。
数据归集主要分为数据抽取、数据转换、数据装载三个步骤，也即ETLoETL（Extract,Transact,Load）,是建设综合数据库过程中最重要的环节之一。
ETL过程将所需要的用户数据从应用系统中抽取出来，经过数据筛选、数据清洗、数据转换，按照预先定义好的综合数据库模型，填充到综合数据库中。
2.2.1.数据抽取
数据抽取是将综合数据库所需要的业务数据从各业务应用系统中抽取出来的过程。
通常有全量抽取、增量抽取、文件抽取等儿种常见形式。
对不同应用系统，可以采用不同抽取方式；
甚至对同一应用系统中不同的业务数据，也可以采用不同抽取方式。
1）全量抽取
全量抽取类似于数据迁移或数据复制，它将数据源中的表或视图的数据原封不动的从数据库中抽取出来，并转换成自己的ETL工具可以识别的格式。
2）增量抽取
增量抽取指抽取自上次抽取以来数据库中要抽取的表中新增、修改、删除的数据。
在ETL使用过程中。
增量抽取较全量抽取应用更广。
捕获增量数据的方法有：
触发器、时间戳、全表比对、日志比对。
3）文件抽取
文件交换是指应用系统将需要抽取的业务数据保存为有格式的文本文件，然后ETL服务通过读此文件内容来获取业务数据的数据抽取方式。
文件交换是U前比较常用、对原数据库系统造成影响较小的一种方式。
采用此方式时，应用系统将需要抽取的数据按照约定格式保存在文件中，并通过FTP、文件共乍等方式将保存有业务数据的文件传递约定位置。
ETL服务器从约定位置取出数据文件,并通过文件分析引擎对文件进行分析，取出业务数据。
2.2.2.数据转换
数据转换是将从不同应用系统抽取出来的业务数据转换为跟综合数据库系统模型要求一致的过程。
由于不同应用系统的开发厂商不同，因此同一业务数据在不同应用系统中的具体实现形式不同，而且存储格式可能完全不同：
而且由于对名称相同的业务数据，在不同应用系统中，具体含义可能有差别。
比如收费期间，有的系统按照自然月计算，有的系统按照上月25号到本月24号计算；
再比如日期数据，在有的应用系统按照日期格式存储，在有的系统中按照字符存储;
再比如客户用电等级，在有的系统中根据计量单元进行判断，在有的系统中根据客户信息判断。
这些都导致了应用系统中的数据和综合数据库中要求的数据不一致，需要进行数据转换才能将应用系统中的数据装载到综合数据库中。
在进行数据转换时，通常有以下转换方法：
1）字段映射
综合数据库中的某个字段内容跟应用系统中的某个字段内容完全相同，这时可以直接转换。
如果两个字段存储格式不同，则需要进行格式转换，同时还可能需要删除应用系统中数据中的前置或后置空格。
比如业务上代表一个数值，但在系统中存储为字符格式的，需要将字符格式转换为数字格式：
再比如保存为字符格式的日期数据，则需要转换为日期格式。
2）代码转换
不同应用系统中对与维度数据的划分粒度与划分层次都不完全相同，而综合数据库只可能采用一种划分方式。
因此需要将应用系统中的维度数据转换为跟综合数据库中的维度数据一致。
在转换时，需要对每一个维度表进行分析，将综合数据库中的维度数据、维度层次和应用系统中的维度表里的数据一一分析，确定应用系统中每一个代码对应的综合数据库中的代码。
通常，两边的代码无法完全对应，也就是说，既有在应用系统中存在而在综合数据库中缺失的代码，也有在综合数据库中存在而在应用系统中缺失的代码。
如果应用系统中的代码缺失，可以忽略；
如果综合数据库中的代码缺失，则需要确定是增加新的代码，还是增加“无对应”的代码。
3）字段拆分
如果综合数据库中的多个字段对应应用系统中的同一字段，也就是说，综合数据库中多个字段的信息都可以从应用系统中的同一字段获取，则需要进行字段拆分。
比如，有的应用系统将客户姓名、地址、联系电话等信息都保存在一个字符类型的字段中；
而在综合数据库中，客户姓名、地址、联系电话是分开存放的。
这个时候，就需要将应用系统中的客户信息字段进行拆分。
拆分时，通常采用数据库提供的函数进行。
如果数据库提供的内置函数无法满足拆分需要，则应该编写自定义函数进行拆分。
4）字段合并
如果综合数据库中的一个字段在应用系统中分为多个字段存储，也就是说，综合数据库中一个字段的信息，在应用系统分为多个字段进行存储，则需要进行字段合并。
比如，有的应用系统中，将客户地址中的省份、地区、街道等分为多个字段存储；
而在综合数据库中，客户地址是一个字段时，就需要将应用系统中的多个地址字段合并为一个字符串，然后保存到集市中。
字段合并时，通常采用数据库提供的函数进行。
如果合并的字段需要预先处理，则在合并前还需要进行预处理。
5）字段运算
如果综合数据库中存储经过初步运算后的综合数据，则需要对应用系统中的多个字段进行运算转换。
比如用户电费数据，在有的应用系统中保存有详细的分时段用电数据、电价数据、电费数据；
如果在综合数据库中只需要保留每个用户的当月总用电数据、总电费数据，则需要将应用系统中的分时段用电数据和电费数据进行求合运算，然后将运算结果保存在综合数据库中。
再比如用户交费日期，在有的系统中直接保存为日期数据；
如果在综合数据库中需要保存为从交费期间开始日期之后的天数，则需要计算交费日期和交费期间开始日期之间的时间间隔,将间隔天数保存到综合数据库中。
在大多数情况下，可以釆用数据库提供的函数进行字段运算。
在遇到需要使用数据库不提供函数的复朵讣算时，则需要自行编写il•算函数进行运算。
6）字段补充
对原来信息表示不完整的字段，将其信息补充完整。
比如日期数据，在应用系统可能只保留了年的后两位，则在保存到综合数据库前，应该根据具体数据，在前面将19或20补充完整。
7）行列转换
如果综合数据库中的一行数据，在应用系统中保存在多行中，则需要进行行列转换。
比如用户用电数据，在应用系统可能每个用户每个月的峰、平、谷用电数据分为三条记录保存，而在综合数据库中直接保存为一行里的三列数据，则需要进行行列转换，将应用系统中的三条记录转换为一条记录，再保存到综合数据库中。
山于行列转换比较复杂，因此在转换时通常无法简单的通过函数来实现，而需要编写代码。
在代码中，需要确定综合数据库中除主键外的其他所有列，在应用系统中如何根据主键信息来获取。
2.2.3.数据装载
数据装载是将经过转换后满足综合数据库要求的业务数据装载到综合数据库中的过程。
在装载时，通常可以采用数据库厂商提供数据装载工具进行批量装载，以提高装载效率；
也可以编写代码釆用数据库服务器提供的API函数进行数据装载。
通常数据装载有以下方法：
1）全部覆盖
在装载数据前，清空综合数据库中对应的历史数据，然后将转换后满足综合数据库要求的业务数据装载到相应的表中。
通常可以采用数据库提供的装载工具直接进行装载。
2）记录追加
在装载时，不清空也不更改综合数据库中的历史数据，直接将
升级会员 