到目前为止, 全国已建立各种类型、不同级别的自然保护区3381个. 保护区的巡护人员需要定期对其进行巡护, 记录巡护信息. 在自然保护区内, 生态环境破坏活动时有发生, 巡护作为自然保护区管理工作中最基础、最重要、最艰苦的工作, 目的是及时地掌握管护区域内的人为活动及破坏动植物资源的情况, 以采取针对性的保护策略, 打击制止保护区内的非法活动, 提高保护的有效性和科学性^[1,2]. 传统的巡护方式是: 巡护人员主要手持GPS定位仪记录坐标点信息, 携带相机进行拍照、录像, 填写纸质的巡护表格, 然后手动录入到系统中, 造成巡护操作复杂、巡护数据记录繁琐、数据容易丢失、数据整合复杂、无法检索等不便. 现在还有很多自然保护区还是以传统的巡护工作方式为主.

随着国内移动网络的全覆盖, 包括自然保护区内网络信号的不断改善, 在自然保护区内能够正常使用移动网络. 移动GIS在野外应用的逐渐发展, 已经成为野外数据采集的主要方式^[3–5], 但移动端不适合对数据进行管理, 使用Web端能有效解决数据的管理问题. 目前, 结合移动端和Web端在自然保护区的应用并不多^[6–8]. 基于位置的服务(Location Based Service, LBS), 是在GIS平台的支持下, 根据用户的位置信息为用户提供相应服务, 如今已广泛应用在紧急救援、位置跟踪、定位导航、本地搜索、社交娱乐、广告促销等方面. 野外巡护过程中需要对巡护人员进行跟踪, 巡护过程中采集的数据几乎都含有位置信息, 但国内针对自然保护区的LBS应用还比较少^[9,10].

本文旨在结合LBS技术构建自然保护区移动巡护系统来取代传统的巡护方式. 本文还在轨迹和关键点巡护数据(含有经纬度坐标信息)存储方面, 使用了KML (Keyhole Markup Language)标记语言^[11], 最终将轨迹和巡护数据整合成KMZ轨迹文件, 使得轨迹数据多样化.

1 系统概述 1.1 系统架构

整个系统分为移动端采集系统、Web端管理系统. 在逻辑上分为用户层、应用层、服务器端和位置服务, 整个架构如图1所示. 位置服务为应用层提供地图服务和定位服务; 服务器端用来存放用户信息、用户采集的巡护信息、KMZ轨迹文件, 并使用Tomcat作为Web服务器, 给应用层提供访问. 应用层则提供可视化界面给用户进行操作, 分为移动端APP和Web端系统; 用户层有保护区巡护人员和管理人员. 移动端APP主要给保护区的巡护人员使用, 用来采集数据; Web端系统主要给保护区的管理人员使用, 用来管理数据, 并及时了解巡护人员的工作情况和实时位置等.

1.2 系统功能设计

移动端采集系统的用户是巡护人员, 巡护人员在开始巡护时, 首先需要在移动终端上进行登录, 开启轨迹记录功能. 在巡护过程中, 填写巡护数据表, 记录巡护事件, 必要时进行拍照、录音和视频拍摄. 巡护结束后, 结束轨迹记录, 将巡护轨迹和数据同步到服务器端. 移动端系统功能主要包括用户登录和注册、数据记录和管理、数据表的模板管理、轨迹记录和管理、离线地图、用户实时位置记录、系统设置和升级.

Web端管理系统的用户是保护区的管理人员和巡护人员. 管理人员需要对巡护人员进行管理, 检索和查看巡护人员的历史轨迹数据, 统计巡护数据, 以及查看巡护人员巡护时所在的实时位置. 巡护人员可以在巡护结束后, 使用有线网络在Web端系统上上传轨迹文件, 在巡护过程中, 生成的巡护轨迹文件一般都比较大, 不适合使用移动网络上传. Web端系统的主要功能包括用户登录和管理、轨迹上传、轨迹展示(在地图上显示轨迹以及关键点信息)、轨迹搜索、轨迹统计、轨迹下载、巡护人员实时位置展示等.

整个系统的功能结构设计如图2所示.

2 关键技术 2.1 LBS技术

基于位置的服务(Location Based Service, LBS)作为移动互联网时代的基础服务, 已成为人们日常生活中不可或缺的部分, 日常生活中80%的信息与位置有关. LBS是通过无线通信网络定位或外部定位(GPS定位)方式, 获取移动终端用户的位置信息, 并以此为基础而提供的空间信息服务^[12]. 目前国内的地图位置服务提供商已经开放了LBS接口, 包括移动端开发和Web开发的接口, 提供地图展示、定位、检索服务等, 开发者可以调用其接口, 自主开发基于地图和定位服务的应用程序.

由于保护区地理位置偏远, 在选择地图服务时, 需要考虑地图在保护区的精度. 对比主流的地图位置服务提供商: 谷歌地图、腾讯地图、百度地图、高德地图等. 其中谷歌地图提供的地图精度最高, 但在国内无法正常使用; 其次是腾讯地图, 精度高于百度、高德地图, 所以本文使用了腾讯位置服务来为移动端和Web端提供地图服务.

2.2 KML

KML (Keyhole Markup Language)文件是一种在GOOGLE地图浏览器中用于交换地理数据的文件. 它基于XML, 并定义了一些TAG用于规定地理数据的显示方式. KML可用于定义的地理特征包括地点、描述、叠层、路径和多边形等. KML现在是由开放地理空间联盟(Open Geospatial Consortium, Inc., 简称 OGC)维护的国际标准. KMZ文件是压缩过的KML文件. 由于KMZ是压缩包, 因此, 它不仅包含KML文件, 也能包含其他类型的文件, 例如图片、视频、音频等. 国内的主流地图服务目前没有支持KML文件格式, 但国内学者武希涛^[13]基于高德地图API研究了加载KML文件的方法, 杜英俊^[14]等人将KML应用在相关GIS系统中, 但很少有将KML应用到保护区中.

本文的KMZ轨迹文件是由RouteRecord.kml、TrackDetail.xml、audio、photo和video组成, 目录如图3所示. RouteRecord.kml文件记录了巡护轨迹的点坐标(Document/Folder/Placemark表示一条轨迹)和关键点信息(Document/Placemark表示一个关键点)等, 如图4所示. TrackDetail.xml文件记录了轨迹的信息, 包括巡护人、巡护轨迹名、巡护开始时间、巡护结束时间、轨迹长度、最高海拔等信息, 如图5所示. 腾讯地图服务没有提供浏览KMZ文件相关的接口, 所以在服务器端需要提取KMZ轨迹文件中的信息, 然后在地图中进行展示. KMZ是压缩文件, 需要使用解压缩技术; RouteRecord.kml、TrackDetail.xml是XML格式文件. 本文使用的是Apache的ant.jar来实现解压缩, 使用资源占用少、快速的SAX解析方式来解析XML格式文件.

2.3 坐标转换

移动端通过GPS定位获取的坐标采用的是标准坐标系, 即地球坐标系(WGS), 腾讯地图使用的是火星坐标系(GCJ-02), 也叫国测局坐标系, 所以需要对其进行坐标转换. 腾讯地图服务只提供了其他经纬度坐标(包括GPS)转换成腾讯地图经纬度坐标的接口, 而在Web端需要用到腾讯地图经纬度坐标转GPS坐标, 具体转换代码如图6所示.

2.4 服务器推送技术^[15,16]

在Web应用中使用的HTTP协议是无状态的, 客户端发起请求并接收到服务器应答后就会断开连接, 所以无法实现“服务器推送”. 目前主要的服务器推送技术有Comet和WebSocket两种. Ajax长轮询是Comet常见的实现方式之一, 就是浏览器通过JS调用XMLHttpRequest对象向服务器发出请求, 收到服务器的返回数据后再重新发出请求, 以保证获取到最新的消息, 一般浏览器都支持这种方式. WebSocket是在新一代HTML标准——HTML5中提供的一种浏览器和服务器间进行全双工通讯的网络技术,与HTTP协议的请求/响应模式不同, WebSocket在建立连接之前有一个Handshake (Opening Handshake)过程, 在关闭连接前也有一个Handshake (Closing Handshake)过程, 建立连接之后, 即可进行双向通信.

3 移动端采集系统

移动端系统主要使用JDK 7、Android 4.2 SDK (API17)、腾讯Android定位SDK、腾讯Android地图SDK进行开发, 使用HTTP协议、JSON数据格式和服务器端进行数据传输. 移动端核心功能有数据记录、轨迹记录和用户实时位置记录. 系统主界面如图7所示.

3.1 数据记录

用户使用定制的模板动态生成数据记录表, 根据用户的操作实现数据的采集录入、保存到本地或者服务器上, 在数据记录上传之前用户也可以对数据进行查看、修改. 模版是根据用户的实际工作需求进行定制. 在本系统中提供了Web方式的模版定制功能, 用户可以在Web页面中创建全新的模版, 或者通过对已有的模版进行修改以生成新的模版. 用户登录进入移动端采集系统之后, 会根据用户的角色从Web端同步数据采集模版, 用户根据实际工作需要选择模版进行数据记录. 为了提高数据记录的效率和准确性, 多数的数据字段都是采用自动填写或者下拉列表点选的方式实现的. 例如时间、经纬度、人员姓名等都采用自动填写的方式, 动植物物种名称、地点名称等都采用下拉列表点选的方式.

3.2 轨迹记录

巡护人员在开始进行巡护时, 需要选择按照特定的时间间隔或特定的移动距离记录活动轨迹, 系统会自动记录用户的坐标信息. 在巡护人员巡护过程中, 填写巡护数据表, 采集动植物数据, 在轨迹中添加关键点标注, 并可以添加文字、照片、音视频等数据. 在用户巡护结束后, APP就会生成KMZ轨迹文件, 在有网的情况下可以选择通过网络将活动轨迹回传给服务器. 用户可以导入生成的KMZ巡护轨迹文件到地图中进行展示.

3.3 用户实时位置记录

为了便于管理人员及时掌握野外工作人员的活动位置, 同时为了保障野外工作人员的人身安全, 系统实现了用户实时位置记录功能. 实时位置功能需要APP以固定间隔时间通过GPS定位获取用户的经纬度坐标, 并实时同步到服务器端的数据库中. 该功能必须要在有网络连接的环境在才能使用.

4 Web端管理系统

Web端核心功能主要有轨迹搜索、轨迹展示、轨迹统计和用户实时位置展示, 系统主界面如图8所示. Web端管理系统主要使用JDK7、Tomcat7、Java Web、腾讯Javascript地图API、JQuery、Bootstrap、Plupload、上传插件、ECharts图表库完成开发. Web端和服务器端主要使用Ajax交互和JSON传输数据.

4.1 轨迹搜索

用户可以通过多种方式进行轨迹记录的搜索, 例如按照巡护轨迹名称、轨迹记录人、轨迹记录的时间范围、轨迹所在的经纬度范围(可在地图上选择区域)等. 搜索后的结果按表格进行分页显示, 用户可查看具体轨迹的详细信息、下载轨迹以及选择轨迹在地图上进行展示.

4.2 轨迹展示

根据轨迹搜索的结果, 用户可以选择一条或多条轨迹进行展示. 通过在轨迹数据库中根据轨迹ID来检索轨迹文件的物理位置, 并对轨迹文件进行解析以获得轨迹的路径信息和关键点信息, 返回给浏览器, 再使用地图服务API进行展示. 对于轨迹中的关键点, 可以展示其中包含的多媒体数据, 包括照片、视频、音频. 为了提高多媒体数据的加载效率, 提升用户体验, 系统会在服务器端对多媒体数据进行压缩处理. 用户可以对轨迹路径进行浏览, 可以对轨迹中关键点的详细信息进行查看, 包括关键点中记录的照片的浏览、音视频数据的播放等.

4.3 轨迹统计

为了便于管理人员掌握野外工作人员的工作情况, 系统提供了轨迹统计功能. 提供了多种统计方式, 包括按时间段查询并统计巡护人员的历史轨迹总长度、历史轨迹长度和出勤次数, 以及排名等. 轨迹统计的结果采用图表方式进行直观有效的显示, 包括折线图、柱状图、表格.

4.4 用户实时位置展示

巡护人员在使用移动端系统进行工作时, 移动端系统会调用服务端的接口实时同步巡护人员的地理位置. 当管理人员登录到Web端系统并进入巡护人员实时位置页面, 服务器端会通过WebSocket方式将巡护人员的实时位置推送到Web端或者Web端通断Ajax长轮询的方式获取巡护人员最新位置, 管理人员就可以看到所有正在巡护的人员位置. 管理人员可以对巡护人员进行检索, 并且查看该人员当天的巡护数据.

5 总结与展望

系统目前已在三江源国家公园、青海湖国家级自然保护区、内蒙古呼伦湖国家级自然保护区、云南无量山哀牢山国家级自然保护区等实际使用, 用户反响良好, 有效提高了野外调查巡护的工作效率. 下一步还将在针对保护区等特定区域的离线高精度卫星遥感影像定制、提升离线地图加载效率、移动端与Web端数据传输的可靠性及安全性方面开展进一步的研究工作, 以提升整个系统的性能和安全水平.