论文部分内容阅读
一、基于信息化城市管理系统和多普达D600“城管通”手机开发一套基础数据动态更新系统的可行性分析
网格化城市管理数据普查采用的传统方法是将所有城市部件、地址兴趣点参照物、区界、街道范围线、监督员责任区范围线、社区线、万米单元网格等数据套印在比例为1∶500地形图中，监督员手拿地图到现场审核，将变化的数据在地图上标注和在表格中进行登记。
能否将这些数据同样装在多普达D600“城管通”手机中，监督员利用多普达D600“城管通”手机在平时工作中随时发现情况随时上报呢？
(一) 多普达D600“城管通”手机端数据容量及工作效率的可行性分析
北京市东城区共有574幅比例为1∶500地形图，一幅图（已由专业公司保密处理）容量大约在0.5M-1M，574幅地形图矢量数据大约有280M，处理压缩后也有近220M，加上比例为1∶500地形图是保密资料也不允许安装在“城管通”手机中。显然依照目前手机的配置，一是无法将这么巨大的数据装入手机使用；二是不符合保密要求。
我们通过对这些资料进行认真细致研究，从现有的资料中抽取需要的要素，有效地解决了上述问题，具体方法如下：
一是依照传统基础数据普查资料制作了如下专题图层，在“城管通”手机端再现了“普查用的地图”。（1）依据最新的地形图资料，制作了东城区现状道路分布图；（2）依据最新的地形图资料，制作了东城区平房院落范围线和楼房范围线分布图；（3）东城区界范围线分布图；（4）东城区10个街道分布图；（5）东城区115个社区分布图；（6）91个监督员责任区分布图；（7）东城区1577个万米单元网格图；（8）东城区近30万个城市部件分布图、3.3万多个地址兴趣点参照物数据分布图。以上八类原始矢量数据共有194.7M。
同时采取以下处理手段：（1）利用ArcGIS的数据简化工具对线、面数据进行抽稀简化；（2）是利用数据转换工具，采用压缩技术将Shape格式的原始数据转换为手机端专用的数据格式，在不影响数据质量的情况下，减少冗余数据，进而减少数据的容量。经专业技术人员的处理，目前手机中八层数据容量大约只有18M。
二是更换“城管通”手机安装数据的方式。按照监督员所属分队（街道）只安装本街道的地图，只显示本责任区内的所有城市部件、地址兴趣点参照物。目前10个街道中“城管通”手机端最大数据量是和平里分队，有6.25M, 最小的是朝阳门分队，有5.09M，完全满足工作使用要求，不会影响“城管通”手机的正常使用。
三是在开发“城管通”手机端程序中通过优化的显示控件、分图库和视野的逐级显示方式，提高了地图操作的响应速度，减少了内存的占用和等待时间，保障了“城管通”手机的工作效率。
四是多普达D600“城管通”手机在Windows Mobile5.0操作系统中增加了Flash的容量，减少RAM的容量，增加了微硬盘，解决了系统存储空间小的问题，为开发数据动态更新功能提供了基础保障。
(二)“城管通”手机端采集数据精度可行性分析
依据中华人民共和国城镇建设行业标准《城市市政监管信息系统管理部件和事件分类、编码及数据要求》（CJ/T214—2007）中的部件空间数据定位精度要求：
（1）空间位置或边界明确的部件，如井盖、灯等，中误差≤±0.5m，在比例为1∶500地形图中误差≤±0.1mm；
（2）空间位置或边界较明确的部件，如亭、广告牌、果皮箱等，中误差≤±1.0m，在比例为1∶500地形图中误差≤±0.2mm；
（3）空间位置概略表达的部件，如桥梁、停车场等，中误差≤±10.0m，在比例为1∶500地形图中误差≤±2.0mm。
目前东城区使用的多普达D600“城管通”手机，配置一块2.8英寸65K色的TFT屏幕，有效显示尺寸是4.5cm×6cm，分辨率为QVGA240×320。
在数据动态更新系统的程序设计中，要求监督员使用“城管通”手机采集数据时的视野控制在30〜50m之内进行。对城市部件、地址兴趣点参照物密集地区可放大到30m视野采集，稀疏地区可放大到50m视野内进行采集。此时“城管通”手机端屏幕显示的比例尺大致为1∶700〜1∶1100;以“城管通”手机中的“再现的普查图”作为基础，以显示的城市部件、地址兴趣点参照物作为依据，采集相应的变更信息，从理论上讲基本可以满足数据采集精度要求。
(三)监督员日常巡视发现变化的城市部件、地址兴趣点参照物，及时上报的可行性分析
一是由于目前在岗的监督员大多已从事过数据普查工作，对城市部（事）件分类较为清楚，加上每年例行的业务培训、业务练兵，监督员业务能力应该有了很大提高。
二是从2008年开始，每次大规模数据更新完成后，基于监督员责任区建立了城市部件、地址兴趣点参照物的数据档案。
两者完美结合，为监督员最终能够正确使用动态数据更新系统更新城市部件等数据提供了前提和条件。
（四）维护公司技术实力雄厚，技术力量能够满足用户提出的各项功能要求
自2008年底，东城区采用了无线多媒体信息采集系统（“城管通”）和信息化城市管理系统一体化的搭建方式对原有系统进行升级改造。目前东城区的“城管通”与信息化城市管理系统均由北京数字政通公司开发和维护。该公司拥有将基于无线技术的移动应用系统与政务管理系统有机结合的开发与实践经验，技术力量能够满足用户提出的各项功能要求。
综上所述，基于信息化城市管理系统和多普达D600“城管通”手机端开发基础数据动态更新系统的基础条件、技术力量均已具备。
二、信息化城市管理基础数据动态更新系统
（一）基础数据动态更新系统的架构
基础数据“动态更新”系统是基于多普达D600“城管通”手机中Windows Mobile5.0操作系统开发的功能模块，通过中国移动通信网上传到“城管通”系统服务器，再通过政务专网上传到信息化城管系统服务器中，系统管理员定期导出监督员通过动态更新系统上报的数据，转交专业测绘公司进行后期的数据制作。见图1。
运用动态数据更新系统上报更新信息是不需要信息化城市管理系统人工干预，也不会影响信息化城市管理系统的正常业务办理。
（二）基础数据动态更新系统采用的技术
1.采用适应网络发展的三层体系结构
数据层、业务逻辑层和表现层。
采用DNA体系三层结构，具有如下优点：
（1）实现了分布式数据处理，能完全利用平台的灵活性、Internet的优势和通讯能力；（2）在一个共享的中间层封装了商业规则；（3）使用标准的数据访问接口，跟所使用的数据库无关；（4）中间层的业务逻辑采用组件技术开发，灵活性大，易于移植，可以快速开发、部署应用程序，不需要对开发者进行重新培训，降低开发者必须写的代码；（5）各模块皆具有互操作能力，可以方便地向现有系统增加功能，符合开放的协议与标准，可以集成其他厂商的产品。
2.采用技术领先的J2EE框架
Java 2平台企业版（Java 2 Platform Enterprise Edition，J2EE）是一种利用Java 2平台来简化诸多与多级企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java 2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如“编写一次、到处运行”的特性，方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对 EJB（Enterprise Java Beans）、Java Servlets API、JSP（Java Server Pages）以及XML技术的全面支持。
3.采用面向对象的C#
C#作为微软自主开发的语言，除了继承了C与C++的所有优点特性，更具有在 Windows 操作系统下的高效性，它不但适用于各种操作系统，并且能与 Windows 紧密的结合在一起。
（三）系统使用方式、在多普达D600手机中实现方法及数据更新成果展示
1.监督员使用动态数据系统方式
监督员在平时巡视过程中，发现新增、删除、变更的城市部件、地址兴趣点参照物等情况，通过“城管通”中的“动态数据”更新系统将变更信息及时上报信息化城管系统即可。
2.动态更新系统在多普达D600手机中实现方法
在“城管通”手机开发动态更新系统时，充分考虑了监督员的工作习惯，数据更新系统上报模式与正常工作时的问题上报基本类似，操作简单、通俗易懂。
具体操作步骤：点击“动态更新”→选择类别（城市部件、地址兴趣点参照物）→选择操作内容（新增、变更、删除）→地图（位置）选择、照片选择、录音选择、问题描述→点击“发送”即可。
3.信息化城市管理系统中导出的数据更新成果展示
系统管理员定期从信息化城市管理系统中导出监督员上报的数据更新成果，主要内容有：
（1）动态更新成果明细（以城市部件为例），含：任务号、类别、变更类型、监督员、大类、小类、部件编码、X（Y）轴坐标、街道、社区、万米单元网格号、问题描述、上报时间。
（2）多媒体信息目录，内含全部监督员上报的任务号，每个任务号内含：上报问题的照片、一个录音文件、一张含有上报问题定位的地图。
三、基础数据动态更新系统测试情况分析
2009年7月底、11月底，我们先后两次组织监督员进行了基础数据动态更新系统现场测试，主要存在如下问题：一是监督员上报问题时的视野过大，影响定位的精度和数据的准确性；二是建议增加院落范围线和楼房范围线，为监督员上报问题定位时提供参照依据，进一步确保监督员上报问题时定位的精确性。
2009年12月底，针对两次测试情况，系统开发组从动态数据更新程序和基础数据制作两个方面对系统进行了优化和补充，改进了测试发现的问题。
2010年1月中旬，又组织监督员进行以上报新增、删除“监控电子眼”的测试，从测试结果来看，基本符合要求，达到了预期的效果。
四、基础数据动态更新系统前景分析
研发基础数据动态更新系统，这是东城区进行基础数据更新机制新的探索，是对传统数据更新方式有益的补充，对比常态的基础数据更新有明显的优点：
一是方便快捷；二是周期短，方式灵活，可以根据需要随时进行更新；三是省时省力，减轻了监督员的工作强度；四是克服了部分监督员由于业务不熟练，导致普查时城市部件分类错误问题的发生；五是可以用此功能对信息化城市管理系统拓展的项目（如：酒类经营场所、污染源等数据）进行实时的动态数据更新。
总之，动态数据更新系统有良好的发展前景。
五、基础数据动态更新系统存在的不足
由于基础数据动态更新系统是刚研发并正式投入运用的，其存在一些问题待今后加以改进。比如：
一是目前开发的动态数据更新系统对点状城市部件、地址兴趣点参照物定位毫无问题，但对线状、面状信息采集就有一定的局限性，待今后版本加以改进。
二是基础数据动态更新系统，对地形变化大（拆迁等）的地区有一定的局限性，需要用常规方法进行测量和外业调绘。
（责任编辑：文雪峰）
网格化城市管理数据普查采用的传统方法是将所有城市部件、地址兴趣点参照物、区界、街道范围线、监督员责任区范围线、社区线、万米单元网格等数据套印在比例为1∶500地形图中，监督员手拿地图到现场审核，将变化的数据在地图上标注和在表格中进行登记。
能否将这些数据同样装在多普达D600“城管通”手机中，监督员利用多普达D600“城管通”手机在平时工作中随时发现情况随时上报呢？
(一) 多普达D600“城管通”手机端数据容量及工作效率的可行性分析
北京市东城区共有574幅比例为1∶500地形图，一幅图（已由专业公司保密处理）容量大约在0.5M-1M，574幅地形图矢量数据大约有280M，处理压缩后也有近220M，加上比例为1∶500地形图是保密资料也不允许安装在“城管通”手机中。显然依照目前手机的配置，一是无法将这么巨大的数据装入手机使用；二是不符合保密要求。
我们通过对这些资料进行认真细致研究，从现有的资料中抽取需要的要素，有效地解决了上述问题，具体方法如下：
一是依照传统基础数据普查资料制作了如下专题图层，在“城管通”手机端再现了“普查用的地图”。（1）依据最新的地形图资料，制作了东城区现状道路分布图；（2）依据最新的地形图资料，制作了东城区平房院落范围线和楼房范围线分布图；（3）东城区界范围线分布图；（4）东城区10个街道分布图；（5）东城区115个社区分布图；（6）91个监督员责任区分布图；（7）东城区1577个万米单元网格图；（8）东城区近30万个城市部件分布图、3.3万多个地址兴趣点参照物数据分布图。以上八类原始矢量数据共有194.7M。
同时采取以下处理手段：（1）利用ArcGIS的数据简化工具对线、面数据进行抽稀简化；（2）是利用数据转换工具，采用压缩技术将Shape格式的原始数据转换为手机端专用的数据格式，在不影响数据质量的情况下，减少冗余数据，进而减少数据的容量。经专业技术人员的处理，目前手机中八层数据容量大约只有18M。
二是更换“城管通”手机安装数据的方式。按照监督员所属分队（街道）只安装本街道的地图，只显示本责任区内的所有城市部件、地址兴趣点参照物。目前10个街道中“城管通”手机端最大数据量是和平里分队，有6.25M, 最小的是朝阳门分队，有5.09M，完全满足工作使用要求，不会影响“城管通”手机的正常使用。
三是在开发“城管通”手机端程序中通过优化的显示控件、分图库和视野的逐级显示方式，提高了地图操作的响应速度，减少了内存的占用和等待时间，保障了“城管通”手机的工作效率。
四是多普达D600“城管通”手机在Windows Mobile5.0操作系统中增加了Flash的容量，减少RAM的容量，增加了微硬盘，解决了系统存储空间小的问题，为开发数据动态更新功能提供了基础保障。
(二)“城管通”手机端采集数据精度可行性分析
依据中华人民共和国城镇建设行业标准《城市市政监管信息系统管理部件和事件分类、编码及数据要求》（CJ/T214—2007）中的部件空间数据定位精度要求：
（1）空间位置或边界明确的部件，如井盖、灯等，中误差≤±0.5m，在比例为1∶500地形图中误差≤±0.1mm；
（2）空间位置或边界较明确的部件，如亭、广告牌、果皮箱等，中误差≤±1.0m，在比例为1∶500地形图中误差≤±0.2mm；
（3）空间位置概略表达的部件，如桥梁、停车场等，中误差≤±10.0m，在比例为1∶500地形图中误差≤±2.0mm。
目前东城区使用的多普达D600“城管通”手机，配置一块2.8英寸65K色的TFT屏幕，有效显示尺寸是4.5cm×6cm，分辨率为QVGA240×320。
在数据动态更新系统的程序设计中，要求监督员使用“城管通”手机采集数据时的视野控制在30〜50m之内进行。对城市部件、地址兴趣点参照物密集地区可放大到30m视野采集，稀疏地区可放大到50m视野内进行采集。此时“城管通”手机端屏幕显示的比例尺大致为1∶700〜1∶1100;以“城管通”手机中的“再现的普查图”作为基础，以显示的城市部件、地址兴趣点参照物作为依据，采集相应的变更信息，从理论上讲基本可以满足数据采集精度要求。
(三)监督员日常巡视发现变化的城市部件、地址兴趣点参照物，及时上报的可行性分析
一是由于目前在岗的监督员大多已从事过数据普查工作，对城市部（事）件分类较为清楚，加上每年例行的业务培训、业务练兵，监督员业务能力应该有了很大提高。
二是从2008年开始，每次大规模数据更新完成后，基于监督员责任区建立了城市部件、地址兴趣点参照物的数据档案。
两者完美结合，为监督员最终能够正确使用动态数据更新系统更新城市部件等数据提供了前提和条件。
（四）维护公司技术实力雄厚，技术力量能够满足用户提出的各项功能要求
自2008年底，东城区采用了无线多媒体信息采集系统（“城管通”）和信息化城市管理系统一体化的搭建方式对原有系统进行升级改造。目前东城区的“城管通”与信息化城市管理系统均由北京数字政通公司开发和维护。该公司拥有将基于无线技术的移动应用系统与政务管理系统有机结合的开发与实践经验，技术力量能够满足用户提出的各项功能要求。
综上所述，基于信息化城市管理系统和多普达D600“城管通”手机端开发基础数据动态更新系统的基础条件、技术力量均已具备。
二、信息化城市管理基础数据动态更新系统
（一）基础数据动态更新系统的架构
基础数据“动态更新”系统是基于多普达D600“城管通”手机中Windows Mobile5.0操作系统开发的功能模块，通过中国移动通信网上传到“城管通”系统服务器，再通过政务专网上传到信息化城管系统服务器中，系统管理员定期导出监督员通过动态更新系统上报的数据，转交专业测绘公司进行后期的数据制作。见图1。
运用动态数据更新系统上报更新信息是不需要信息化城市管理系统人工干预，也不会影响信息化城市管理系统的正常业务办理。
（二）基础数据动态更新系统采用的技术
1.采用适应网络发展的三层体系结构
数据层、业务逻辑层和表现层。
采用DNA体系三层结构，具有如下优点：
（1）实现了分布式数据处理，能完全利用平台的灵活性、Internet的优势和通讯能力；（2）在一个共享的中间层封装了商业规则；（3）使用标准的数据访问接口，跟所使用的数据库无关；（4）中间层的业务逻辑采用组件技术开发，灵活性大，易于移植，可以快速开发、部署应用程序，不需要对开发者进行重新培训，降低开发者必须写的代码；（5）各模块皆具有互操作能力，可以方便地向现有系统增加功能，符合开放的协议与标准，可以集成其他厂商的产品。
2.采用技术领先的J2EE框架
Java 2平台企业版（Java 2 Platform Enterprise Edition，J2EE）是一种利用Java 2平台来简化诸多与多级企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java 2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如“编写一次、到处运行”的特性，方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对 EJB（Enterprise Java Beans）、Java Servlets API、JSP（Java Server Pages）以及XML技术的全面支持。
3.采用面向对象的C#
C#作为微软自主开发的语言，除了继承了C与C++的所有优点特性，更具有在 Windows 操作系统下的高效性，它不但适用于各种操作系统，并且能与 Windows 紧密的结合在一起。
（三）系统使用方式、在多普达D600手机中实现方法及数据更新成果展示
1.监督员使用动态数据系统方式
监督员在平时巡视过程中，发现新增、删除、变更的城市部件、地址兴趣点参照物等情况，通过“城管通”中的“动态数据”更新系统将变更信息及时上报信息化城管系统即可。
2.动态更新系统在多普达D600手机中实现方法
在“城管通”手机开发动态更新系统时，充分考虑了监督员的工作习惯，数据更新系统上报模式与正常工作时的问题上报基本类似，操作简单、通俗易懂。
具体操作步骤：点击“动态更新”→选择类别（城市部件、地址兴趣点参照物）→选择操作内容（新增、变更、删除）→地图（位置）选择、照片选择、录音选择、问题描述→点击“发送”即可。
3.信息化城市管理系统中导出的数据更新成果展示
系统管理员定期从信息化城市管理系统中导出监督员上报的数据更新成果，主要内容有：
（1）动态更新成果明细（以城市部件为例），含：任务号、类别、变更类型、监督员、大类、小类、部件编码、X（Y）轴坐标、街道、社区、万米单元网格号、问题描述、上报时间。
（2）多媒体信息目录，内含全部监督员上报的任务号，每个任务号内含：上报问题的照片、一个录音文件、一张含有上报问题定位的地图。
三、基础数据动态更新系统测试情况分析
2009年7月底、11月底，我们先后两次组织监督员进行了基础数据动态更新系统现场测试，主要存在如下问题：一是监督员上报问题时的视野过大，影响定位的精度和数据的准确性；二是建议增加院落范围线和楼房范围线，为监督员上报问题定位时提供参照依据，进一步确保监督员上报问题时定位的精确性。
2009年12月底，针对两次测试情况，系统开发组从动态数据更新程序和基础数据制作两个方面对系统进行了优化和补充，改进了测试发现的问题。
2010年1月中旬，又组织监督员进行以上报新增、删除“监控电子眼”的测试，从测试结果来看，基本符合要求，达到了预期的效果。
四、基础数据动态更新系统前景分析
研发基础数据动态更新系统，这是东城区进行基础数据更新机制新的探索，是对传统数据更新方式有益的补充，对比常态的基础数据更新有明显的优点：
一是方便快捷；二是周期短，方式灵活，可以根据需要随时进行更新；三是省时省力，减轻了监督员的工作强度；四是克服了部分监督员由于业务不熟练，导致普查时城市部件分类错误问题的发生；五是可以用此功能对信息化城市管理系统拓展的项目（如：酒类经营场所、污染源等数据）进行实时的动态数据更新。
总之，动态数据更新系统有良好的发展前景。
五、基础数据动态更新系统存在的不足
由于基础数据动态更新系统是刚研发并正式投入运用的，其存在一些问题待今后加以改进。比如：
一是目前开发的动态数据更新系统对点状城市部件、地址兴趣点参照物定位毫无问题，但对线状、面状信息采集就有一定的局限性，待今后版本加以改进。
二是基础数据动态更新系统，对地形变化大（拆迁等）的地区有一定的局限性，需要用常规方法进行测量和外业调绘。
（责任编辑：文雪峰）