基于MapBasic城市部件数据档案管理工具开发与应用.docVIP

基于MapBasic城市部件数据档案管理工具开发与应用 　　摘 要：本文从北京市东城区城市监督管理中心对于城市部件数据档案管理的需求出发，基于城市部件空间数据库，利用MapBasic语言进行二次开发扩展MapInfo系统功能，设计实现了城市部件数据档案管理工具，完全满足东城区城市监督管理中心的要求，极大地方便了城市监督员的部件管理工作。 　　关键词：数字城管 城市部件 档案管理 MapBasic 二次开发 　　中图分类号：TP3 文献标识码：A 文章编号：1672-3791（2013）07（c）-0039-02 　　“数字城管”建设作为城市管理工作信息化的标志，采用万米单元网格管理法和城市部件、事件管理法相结合的方式，应用、整合多项数字城市技术，创建城市管理监督中心和指挥中心两个轴心的管理体制，再造城市管理流程，从而实现精确、敏捷、高效、全时段、全方位覆盖的城市管理模式。 　　为了开展上述工作，北京市东城区按照行政区域划分管理权限，从纵向层面，将东城区的管理区域划分为四个层面：街道办事处、社区居委会、监督员责任区、万米单元网格。其中街道办事处10个，社区居委会126个，监督员责任区92个、万米单元网格1593个。东城区城市部件按照城市管理功能划分，共分为六大类一共60种，城市部件的大类包括：公用设施类、道路交通类、市容环境类、园林绿化类、房屋土地类及其他类。根据统计东城区部件总数为168339个，此外还有各种参照物、兴趣点、地址等数据，整个东城区城市部件的管理任务落实到92个监督员身上，每个监督员平均要管理1800多个城市部件。为了让每个监督员做到对自己辖区范围的部件种类、部件标识码及部件所在的万米单元网格编码心中有数，能对城市部件进行迅速查找和定位，建立一套城市部件档案势在必行。 　　鉴于东城区城市监督管理中心使用的是MapInfo系统，因此本文选用MapInfo的二次开发语言MapBasic对MapInfo系统进行功能扩展，基于城市部件空间数据库，设计了城市部件数据档案管理工具，完全满足东城区城市监督管理中心的要求。 　　1 程序设计方案 　　1.1 设计思路 　　城市部件数据档案管理工具的功能要求主要包括：用户可以根据街道办事处名称、社区居委会名称、监督员责任区名称、或万米单元网格编码对该区域的部件进行查询统计；计算该查询区域内各类部件的总数及该查询区域内各部件的详细信息；将查询的结果最终保存为xls格式的数据。 　　其中的查询采用MapBasic空间查询算法，查询面对象中包含的点对象。根据对现有数据的分析，可以知道街道办事处、监督员管理层面、社区居委会、万米单元网格都是面对象，它们之间有如下的空间关系：万米单元网格社区居委会街道办事处。监督员工作层面是个比较特殊的图层，每个监督员层面由一个或两个社区居委会组成，但“王府井”和“站东街”两个社区居委会例外，由于“王府井”和“站东街”这两个居委会面积较大，因此在监督员管理层面中这两个社区居委会分别被划分成两个监督员层面“王府井东”、“王府井西”和“站东街南”、“站东街北”，所以进行算法设计时主要按照空间查询的思想，对“王府井”和“站东街”进行特殊处理。部件对象是点对象。对落在街道办事处、监督员管理层面、社区居委会、万米单元网格的区域的部件对象进行查询就是所谓空间查询。在MapInfo中查询统计结果无法直接保存为xls的数据格式，需要将结果保存为MapInfo能输出的txt文本格式，然后将这些文本格式的数据批量转成xls格式的文本。 　　1.2 程序实现 　　（1）创建对话框部分。在对话框设置中，用户可以选择查询对象，既可对部件对象查询，也可对门址、参照物、兴趣点查询，这两类数据的属性结构是完全不同的，因此必须分别进行查询。在查询前必须让用户能选择街道办事处、监督员工作层面、社区居委会和万米单元网格图层，可让用户查询某一街道，某一社区、某一监督员管理区域甚至可以精确到某一万米单元网格的，可以选择需要查询的部件种类，这样查询设计可以满足用户的查询需求。查询对话框如图1。 　　Dialog Width 175 Height 290 　　Title 统计窗口 　　Calling Dialog_Sub 　　Control GroupBox 　　Title 选择查询对象 　　Position 5，5 Width 165 Height 35 　　Control RadioGroup 　　Title 部件查询；地址查询 　　ID 6 　　Value 1 　　Position 10 ，15 Width 50 　　calling RadioGroup_Sub 　　Control StaticText 　　Position 70，15