APP下载

全景配置动态生成方法及实现

2016-12-20徐溯阳蔡阳军杜震洪刘仁义

浙江大学学报(理学版) 2016年6期
关键词:配置文件全景引擎

徐溯阳, 蔡阳军, 张 丰, 杜震洪*, 刘仁义

(1. 浙江大学 浙江省资源与环境信息系统重点实验室, 浙江 杭州 310028; 2. 浙江大学 地理信息科学研究所, 浙江 杭州 310027; 3. 杭州市住房保障办公室, 浙江 杭州 310006)

表1 配置文件标签数及比例

表2 传统方案中的配置文件

表3 动态生成方案下的配置文件

表4 2种方案的文件数量对比

表5 2种方案的请求获取时间对比



全景配置动态生成方法及实现

徐溯阳1,2, 蔡阳军3, 张 丰1,2, 杜震洪1,2*, 刘仁义2

(1. 浙江大学 浙江省资源与环境信息系统重点实验室, 浙江 杭州 310028; 2. 浙江大学 地理信息科学研究所, 浙江 杭州 310027; 3. 杭州市住房保障办公室, 浙江 杭州 310006)

基于配置静态存储方法的全景应用模式已能较好地满足一般的全景浏览应用要求.但在更新频繁、交互量大、场景数多的环境下,此方法容易造成维护困难、服务器数据量激增等问题.针对在不同场景图像配置中存在重复的静态内容这一问题,提出了一套具有普适性和可移植性的全景配置文件动态生成方法:提炼静态内容,存储动态内容,并根据不同场景的请求参数动态生成配置文件.经实验对比,相较配置静态存储方法,动态生成方法显著减少了服务器文件数量,在传输时间、可维护性与浏览器缓存利用方面均优于传统方案.

全景;配置;动态生成

全景图像是一种能为用户提供超过人类正常视野范围的实景图片,在机械、计算机视觉、监控以及虚拟现实领域有着广泛应用[1].全景是GIS的重要组成部分,也是传统仿真三维技术的一种替代方案[2].近年来,各类全景系统发展迅猛,具有代表性的有国外的谷歌街景,国内的腾讯街景、百度街景等.

行业内的小型全景应用常采用商业全景引擎与自定义配置文件相结合的方式实现.其中,全景引擎封装了全景应用的核心功能,而配置文件则定义了应用的图像、展现形式和交互逻辑,是全景应用必不可少的组成部分.

目前对于全景配置管理的研究尚不成熟.文献[3]自主实现了一套配置文件标准规范,但在组织方式上还是最原始的多景配置.文献[4]提出了配置拆分思想,将各类功能性配置文件分开组织,而将景相关配置统一组织.文献[5]设计了一个全景生成系统,但其配置在访问前而非访问时生成.文献[6]提出了对配置进行编辑管理的思想,但只采用了简单的I/O文件操作.

以上研究在配置管理上均未突破静态性.每一景的配置文件均于事先制作完成,访问时直接调用.这类方案在景数较少的场合效果较好,但在景数大于100的中大型全景应用中,具有数据冗余、修改维护困难、实时性不足等缺点.

本文拟设计并实现一套具有普适性和可移植性的全景配置文件动态生成方法,并用实验验证所搭建的原型系统.

1 全景应用和配置静态存储方法

1.1 全景应用组成

1.1.1 全景引擎

全景引擎又称全景播放器,是全景应用的核心.全景引擎封装了实现全景浏览功能的主要模块,允许用户根据设定的参数,对已有全景切片进行获取、融合、拼接和渲染.

全景引擎必须通过特定的配置文件来传递配置信息.

1.1.2 配置文件

全景配置文件的作用是传递全景应用每一景初始化时的各类配置信息.读取全景引擎解析配置文件中相应内容到内存并进行维护.初始化结束后,配置文件即被丢弃,在用户浏览交互过程中不再起作用[7].

配置文件的具体格式和写法与使用的引擎相关.本文使用的Krpano全景引擎要求配置文件以XML格式书写.各类配置项实际上都是XML文档中带属性的标签与子标签.

1.1.3 全景脚本程序

严格来说,全景脚本函数也是配置文件的一部分,定义在〈action〉标签中.

全景脚本程序是全景引擎提供的一种用户接口,允许用户使用其支持的脚本语言对全景场景进行控制.包括样式修改、景切换、视角转换、兴趣点增删、事件绑定等.

1.1.4 前端控制程序

前端控制程序即是传统的javascript前端脚本.前端控制程序负责对一些没有定义在全景内的DOM对象以及BOM对象进行控制和操作.Krpano引擎提供了前端控制程序与全景脚本相互调用的直接接口.在前端代码中,可以使用krpano.call()调用全景脚本函数,而在全景脚本函数中,可以通过js()调用前端.

1.2 全景配置静态存储方法

全景配置的静态存储方案如图1所示.静态存储方案没有服务器端程序.服务器端只发布包含全景配置文件与全景切片数据的文件系统,供全景引擎调用.

图1 静态存储方法架构Fig.1 Architecture of static storage method

在配置文件的组织上,存在“多景-配置”与“一景-配置”2种情况.前者为每一景存储一个配置文件,后者将部分或者所有景的配置置入同一个配置文件的〈scene〉标签中.

在实践中发现,全景系统的传统配置方案导致了以下问题:

1.2.1 配置存在大量冗余

在配置文件中,每一景独有的配置信息包括景名、视角、切片地址与兴趣点,而其他配置项,包括样式、显示效果、全景脚本程序等各景都基本相同,从而造成相同的配置项在多个配置文件中重复出现.

以本实验所用的数据为例(见表1),平均每份配置文件定义样式8项、脚本动作函数25项,平均行数410,占配置文件数据总量的70%以上.

表1 配置文件标签数及比例

Table 1 Number and proportion of tags in configuration file

1.2.2 兴趣点的创建维护困难

兴趣点(hotspot)是指景空间中预先定义的、拥有固定位置和样式、可承载一定信息的对象[8].功能上,可以分为跳转兴趣点、链接兴趣点、图片展示兴趣点、文字介绍兴趣点、评论兴趣点、语音兴趣点等.样式上,可以分为面状兴趣点和点状兴趣点.除了全景图像外,兴趣点是全景应用信息传递的最主要方式.

配置静态存储方法很难解决创建和维护兴趣点的问题.在创建方面,因为兴趣点属于景外内容,Krpano引擎的配置文件自动生成的工具,其兴趣点录入生成功能不尽完备,开发人员需根据资料,在配置文件生成之后,手动修改、写入〈hotspot〉标签,并增加相应属性.

其次,兴趣点具有动态性和时效性.店铺、公共设施、仪器器材等重要兴趣点的信息处于动态变化中,需要不断对其进行更新维护.

由于〈hotspot〉标签写在配置文件中,很难通过代码修改,只能采用手工方式修改,工作量巨大.当与同一个实体对应的兴趣点出现在N个景中时,一个实体改变,就需要修改N个景的配置文件.

1.2.3 无法利用浏览器缓存

在全景应用中,由于全景引擎首先需要获取配置文件才能进行渲染,在配置文件的请求响应到达前,一切工作都将挂起.所以配置文件的请求阻塞性是全景应用中的瓶颈.能否快速地从服务器获取配置文件,关系到全景应用用户体验能否流畅.

为了追求最快的浏览速度,现代浏览器都会将访问网页时依赖的一些静态资源缓存到本地[9].当使用传统方法时,每访问一个新景,都要重新下载该景的配置文件,而之前缓存的其他景的配置文件在逻辑上与其无关,相同内容无法再利用,这在一定程度上降低了浏览速度.

2 全景配置动态生成方法

全景配置本质上是对全景应用中的各类功能、展现效果和特性的设置.这些功能、展现效果和特性可被抽象为全景对象.

全景对象A与全景配置C之间存在不完全映射关系.认识全景对象是进一步认识和分析全景配置的必要前提.

2.1 全景对象

2.1.1 全景对象抽象

分析现有全景应用中的各类功能、展现效果和特性,结合配置文件格式,对全景应用中的概念及其之间的关系进行抽象,如图2所示.

图2 全景对象ER图Fig.2 Entity relationship diagram of panoramic object

结合图2,对以上抽象对象进行描述.

a) PanoSystem:对全景应用本身的抽象.代表一个完整的全景应用.

b) View:对全景图视角的抽象.包括当前视角方向、视角宽度和视野范围.

c) Display:对全景图展示质量的抽象.包括帧率、锐化等配置项.

d) Control:对用户操作和交互细节的抽象.

e) Autorotate:对全景自动旋转功能的抽象.

f) Cursors:对鼠标样式的抽象.

g) Events:对各类事件的抽象.

h) Action:对全景脚本的抽象.

i) Scene:对景的抽象.景是全景应用中最重要的概念之一,全景应用本身即是以景为单位进行组织的.

j) Hotspot:对兴趣点的抽象.兴趣点是景内最重要的表现数据和内容的概念.兴趣点从样式上可分为两类,其中一类为Image Hotspot.

k) Entity:对Hotspot所对应的真正实体对象的抽象.

l) Layer:对全景图内的自定义区域的抽象.

m) Image:对景内全景图片配置的抽象,分为CUBE、CUBESTRIP、SPHERE、CYLINDER等.

n) Level:对全景切片层级的抽象.只有当Image开启了Multiles选项时才可以使用.

o) Polypoint:对组成Polygon Hotspot的点的抽象.Polypoint与Hotspot是多对一关系.

p) Preview:对景预览图的抽象.

q) Style:对样式的抽象.

2.1.2 全景对象分析

从图2中可以看到,全景对象被分为上下2个部分.上方的对象引申自PanoSystem,是PanoSystem的子对象.下方的对象引申自Scene,是Scene的子对象,而Scene本身又是PanoSystem的子对象.

PanoSystem的直接子对象具有全局性和一致性,即在单个全景应用中只需定义一次,和任何一景既没有逻辑关联也不存在包含关系,所以将其归为静态对象.

而Scene的子对象具有局部性和动态性,即每一景都有自己独特的Hotspot、Image、Preview、Layer和Entity,所以将这些Scene的子对象归为动态对象.

如果用首字母来标志各类全景对象(重复则以下标区分),以广义表的形式来表示全景对象及其之间的关系,则有:

Pa=(Ps,Pd),

(1)

Ps=(V,D,C1,A1,C2,A2,E,S),

(2)

Pd=(S1(H(E,P)),I(L),P2),

(3)

其中,Pa代表全景应用整体,Ps代表全景应用中的静态内容,Pd代表全景应用中的动态内容.将全景对象映射到全景配置中,则可以得到各配置项的特性和关系.

2.2 全景动态配置思想

根据式(1)~(3),分别处理全景静态对象与动态对象.将动态对象的相关信息保存到数据库中,静态对象对应的配置项保存到几个不同的静态模板文件中.

全景配置动态生成架构如图3所示,生成过程如图4所示,具体步骤为:

1) 获取html页面,载入前端js代码并执行.js代码控制载入全景引擎核心文件,创建全景视窗.全景引擎向web服务器发出获取全景配置的请求.

2) web服务器根据唯一标识符进行数据库查询,判断目标景是否存在,如存在,则进行下一步操作.如不存在,则请求失败,返回错误信息.

3) 根据唯一标识符进行数据库查询,获取目标景的初始视角信息、全景图像信息、兴趣点信息和实体信息.

4) 在web服务器的内存中创建一个空文档,将第3步获取的动态配置信息写入空文档.

5) 获取其他请求参数,根据这些请求参数,对之前的配置项做覆盖和追加,并写入文档.

6) 将静态配置模板引入文档.

7) 修改http response的MIME类型为text/xml.将动态生成的配置文档写入response,并返回http response.

在动态生成模型下,全景浏览需要的配置不再是“统一生成,永久存储”,而是“分类存储,时时更新”.

图3 动态生成方法架构Fig.3 Architecture of dynamic generation method

图4 动态生成方法步骤Fig.4 Procedure of dynamic generation method

2.3 静态配置模板设计

静态配置模板事先编写,有3个文件,分别为:

a) template.xml:配置文件的入口,存放除action和style之外的所有静态配置项.另外2个静态配置模板由它引入.

b) action.xml:存放所有全景脚本配置项.

c) style.xml:存放所有样式配置项.

之所以将action.xml和style.xml拆分,是因为只有1项其他静态配置项,而这2类配置项的数量较大,拆分为2个文件有助于更好地管理和维护.如果文件体量过大,可以进一步拆分.

2.4 动态配置项生成

动态配置项的生成主要由后端服务器程序负责.服务器程序获取用户的请求参数(主要为景名或景编号),与数据库交互,读取与目标景关联的动态配置信息并创建配置项.

2.4.1 动态配置信息

动态配置信息存储在数据库中,主要包括4部分:目标景的初始视角信息、全景图像信息、兴趣点信息和实体信息.

a) 初始视角信息

初始视角信息指图像载入时的视角方向,包括水平角(hlookat)和天顶角(vlookat).静态配置模板中本已设定视角配置,但由于无人机拍摄角度无法固定等,往往需要对初始视角进行调整.

b) 全景图像信息

图像信息指的是该景对应的瓦片层级、瓦片大小、瓦片存储地址以及该景在电子地图上的经纬度等信息.

c) 兴趣点信息

兴趣点信息指的是景内的兴趣点类型、兴趣点关联实体、兴趣点坐标,以及组成Polygon Hotspot的Polypoint的坐标.

d) 实体信息

实体信息指的是兴趣点所对应的场景实体(商家、景观、公共设施、展览对象等)的相关信息.

2.4.2 生成配置项

配置文件的生成主要有3个步骤:

第1步是静态模板文件的引入,实践中通过生成〈include〉标签引入template.xml实现.

第2步是全景图像的配置,实践中通过动态生成〈image〉标签的方式实现.同时,还要根据从数据库中获取的景信息写入〈image〉标签的type属性(投影类型)、url属性(全景图像地址)、multitiles属性(是否采用多级切片)、tilesize类型(切片大小)和progressive属性(是否支持渐进式切片载入效果).如果存在切片,则还要添加〈level〉标签.

第3步是兴趣点的配置,这是配置文件生成过程中的重点和难点.实践中通过动态生成〈hotspot〉标签的方式实现.如果是面状兴趣点(polygonal hotspot),则需要在〈hotspot〉标签内部增加〈point〉标签及其ath与atv属性;如果是点状兴趣点(image hotspot),则需要设定〈hotspot〉的type属性为“image”,并设定ath和atv.

每个兴趣点都对应一个实体(Entity),当初始化兴趣点时,还要通过关联查询获取关联实体的信息,并写入hotspot的配置项中.

3 原型系统的实现与验证

杭州市河道监管中心拟建设河道管理系统(一期)全景展示模块,笔者以此为契机,构建了动态生成配置的全景展示与管理系统,对动态生成方法进行了验证.

平台用PHP作为后台语言,用thinkphp作为MVC框架,DomDocument作为动态构建XML格式配置文件的扩展工具.采用SQLServer2008数据库,测试网络环境为普通互联网,带宽为2 M.

3.1 文件数量缩减

在静态存储方案中,使用最新版本的全景引擎批处理工具.工具为每个景自动生成以下配置文件,文件名中s代表具体的景名或编号.

表2 传统方案中的配置文件

Table 2 Configuration file in static storage method

本系统的景数较多.水面全景,上塘河692景,余杭塘河443景,共计1 135景.空中全景,上塘河36景,余杭塘河22景,共计58景.水面与空中全景总计1 193景.

传统方案中配置文件总数随景数递增.配置文件总数为1 193×3=3 579.配置文件大小为23 kB×1 193=27.44 MB.

动态生成方案下,配置(模板)文件如表3所示.配置模板文件总数固定为3个,不随景数的增加而增加.配置文件的总大小为35 kB.结果如表4所示.

表3 动态生成方案下的配置文件

Table 3 Configuration file in method of dynamic generation

表4 2种方案的文件数量对比

3.2 兴趣点可维护性优化

系统设计并实现了兴趣点创建维护功能.

在本系统中,兴趣点实体是河道监管中需要特别关注的闸泵站、排水口、近水平台等地物.

管理员只要在任一景的幅面上单击选定位置,填写相应的属性信息,就可以创建兴趣点,并将其信息写入数据库,刷新后依然可见.同时,管理员还可以对已有兴趣点进行删除或属性编辑操作,修改结果也可以保存.

在传统配置文件静态存储的方案下,这是无法实现的.

3.3 浏览器缓存优化

在动态生成方案下,访问过的任意一景,其配置模板文件全部被浏览器缓存,模板文件可以从缓存用户本地瞬时读取,通过网络传输的只有动态生成的内容.

而在传统方案中,访问一景后,这一景的配置文件虽然被缓存,但和其他景的配置文件没有关系.当访问第2景时,依然需要通过网络获取第2景的配置文件.在网络环境较差时,如果配置文件没有即刻获得,会给用户造成“黑屏”的视觉印象.

从图5中可以看到,在对某一景的首次访问中,用于动态生成配置文件的http请求(第1行)耗时146 ms,其他3个静态配置模板分别耗时45,247和258 ms.

如图6所示,当下一次访问其他景时,其用于动态生成配置文件的http请求耗时基本不变,而3个静态配置文件均可从缓存中瞬时获取,整体浏览时间大大缩短.

对2种方案进行访问测试,结果如表5所示.可见,动态生成方案能够更好地利用缓存,且请求总体响应时间短于静态存储方案.

图5 动态生成方案下配置文件模板的http请求获取(首次请求)Fig.5 The http request information in method of dynamic generation(first request)

图6 动态生成方案下配置文件模板的http请求获取(从缓存中获取)Fig.6 The http request information in method of dynamic generation(from cache)

表5 2种方案的请求获取时间对比

Table 5 Contrast on http request transmission time between two methods

4 结 论

针对全景应用配置文件大、可维护性差、无法缓存等问题,提出了全景配置动态生成的解决方案,探索了静态配置模板存储与动态配置项生成相结合的配置生成方法;搭建了基于该方法的全景应用并运用于实际项目中.实例验证表明,本文采用的方法能较好地解决以上问题.

然而,本文的探索尚处于初步阶段,所提方案仍有很大的改进空间,例如,仅把景本身作为控制动态内容的变量进行传递.下一步可考虑增加其他控制动态配置变量,以增强动态性.

[1] GLEDHILL D, TIAN G Y, TAYLOR D, et al. Panoramic imaging:A review[J]. Computers&Graphics,2003,27(3):435-445.

[2] 丁峰,万远,雷雨,等.基于三维全景的在线漫游及GIS集成研究与开发[J].南开大学学报:自然科学版,2014(4):54-58. DING Feng, WAN Yuan, LEI Yu, et al. Online roaming and GIS integration research and development based on three-dimensional panoramic[J]. Journal of Nankai University:Science Edition,2014(4):54-58.

[3] 杨仁杰. 基于Web的全景技术研究[D].郑州:郑州大学,2012. YANG Renjie. The Research for Web-Based Panorama Technology[D]. Zhengzhou:Zhengzhou University,2012.

[4] 王延朝.基于Krpano的三维全景系统的开发和应用[D].上海:华东师范大学,2012. WANG Yanchao. The Development and Application of Three-Dimensional Panorama System Based on Krpano[D].Shanghai: East China Normal University,2012.

[5] 孙磊.全景制作平台的设计与实现[D].西安:西安电子科技大学,2014. SUN Lei. The Design and Implementation of A Panoramic Production Platform[D]. Xian: Xidian University,2014.

[6] 朱国情,李东亮,程刚.基于Krpano的全景编辑系统设计与实现[C]//第14届中国系统仿真技术及其应用学术年会论文集.三亚:科研出版社,2012. ZHU Guoqing, LI Dongliang, CHENG Gang. Design and realization of panorama edit system based on Krpano[C]//Proceedings of 14th Chinese Conference on System Simulation Technology & Application.Sanya:Scientific Research Publishing,2012.

[7] Krpano Gesellschaft. Krpano XML Reference Version1.19[DB/OL].http://www.krpano.com/docu/xml.[2014-10-17].

[8] World Wide Web Consortium. Caching in HTTP[DB/OL].[1999-06-01]. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html.

[9] SHIBATA K, ARAKI S, MAEDA K, et al. High-quality panoramic image generation using multiple PAL images[J]. Electronics and Communications in Japan, 2014,97(6):58-66.

XU Suyang1,2, CAI Yangjun3, ZHANG Feng1,2, DU Zhenhong1,2, LIU Renyi2

(1.ZhejiangProvincialKeyLabofGIS,ZhejiangUniversity,Hangzhou310028,China; 2.DepartmentofGeographicInformationScience,ZhejiangUniversity,Hangzhou310027,China; 3.HangzhouHousingSecurityOffice,Hangzhou310006,China)

A method of dynamic generation of the panoramic configuration file and its implementation. Journal of Zhejiang University(Science Edition), 2016,43(6):726-732

The application model based on static storage of the panoramic configuration file meets normal requirements. But in systems which demand frequent update, complex interaction and contain large number of scenes, it may lead difficulties in system maintenance as well as a sharp rise of the configuration file number. Since some static configuration contents appear repeatedly in different scenes’ configuration files, we propose an improvement method by extracting the static content from the configuration file, storing the dynamic content in database and creating configuration file based on the parameters about the current scenes. Experimental results show that the dynamic generation method can remarkably reduce the number of files, and is superior to static storage method in transmission time, maintainability and cache use.

panorama; configuration; dynamic generation

2015-12-18.

徐溯阳(1990-),ORCID:http://orcid.org/0000-0003-0486-1978,男,硕士研究生,主要从事全景技术和网络地理信息系统研究.

*通信作者,ORCID:http://orcid.org/0000-0001-9449-0415,E-mail:duzhenhong@zju.edu.cn.

10.3785/j.issn.1008-9497.2016.06.018

TP 391

A

1008-9497(2016)06-726-07

猜你喜欢

配置文件全景引擎
从Windows 10中删除所有网络配置文件
新海珠,新引擎,新活力!
戴上耳机,享受全景声 JVC EXOFIELD XP-EXT1
用软件处理Windows沙盒配置文件
车坛往事4:引擎进化之屡次失败的蒸汽机车
互不干涉混用Chromium Edge
基于Zookeeper的配置管理中心设计与实现
全景敞视主义与侦探小说中的“看”
蓝谷: “涉蓝”新引擎
从5.1到全景声就这么简单 FOCAL SIB EVO DOLBY ATMOS