EverCraft一直在关注Web可视化技术的发展，本文对国外一篇感觉很不错的综述性文章进行翻译，供这一领域的爱好者相互学习。这篇paper的信息为：“Mwalongo, F., et al., State-of-the-Art Report in Web-based Visualization. COMPUTER GRAPHICS FORUM, 2016. 35(3): p. 553-575. ”。感兴趣的小伙伴可以直接阅读原文献哈。
PS：
- 全文11302字，很长，可收藏后慢慢查看；
- 由于之前的翻译是分阶段完成，这里将所有系列文章汇总整理，方便各位阅读；
- 限于小编水平，翻译如有不恰当的，欢迎大家给予意见我们及时修正；
- 原文有很多参考文献，这里就没有列出，希望扩展深入了解的小伙伴，请直接阅读英文原文。
1. 概述
远程可视化技术研究在海量医学数据、社交媒体数据或商业数据的可视化应用方面发挥着重要作用。这一需求源自用户终端计算能力的相对不足，比如手机处理能力不够，或者需要可视化的数据量太大。同时，由于传输带宽、延迟时间或者本地存储的限制，即使终端计算能力足够，这些海量的数据也难以实现高效传输。况且，在某些特殊场景下，一些敏感数据或者保密原始数据也并不适合直接向其他人开放。鉴于带宽、网络延迟等问题成为远程可视化的主要瓶颈，过去有大量研究和技术集中于解决这些问题。
尽管过去的研究成绩斐然，但数据量的不断增长和硬件设备的持续发展，使得远程可视化依然一直是研究的热点。由于天然的跨平台属性、以及成为未来协作平台的潜力，基于Web的可视化技术在该领域表现得尤为突出。
基于Web的方式使得一套可视化工具代码可以跨平台执行，这不仅让团队间的协作和分享更加便捷，并且降低了程序的维护复杂度，使得可视化领域的研究者和其他应用行业领域的研究者可以更专注于研究各自领域的核心问题。更进一步，基于Web的方式使得各应用领域的研究者可以随时获得最新的数据（只需要刷新页面即可）。同时，这种可视化研究者和行业应用研究者的协同工作方式，更有助于促进可视化研究成果的落地应用。
基于Web的可视化方案的另一个明显优势则是用户的便利性。用户（比如各行业应用的研究者）只需要通过网页浏览器，而不需要安装其他任何软件。因浏览器基本上在所有的计算终端均可直接使用，用户可随时随地开展工作（只要能上网，同时其具有数据的访问权限）。因为大多的可视化解决方案均是基于GPU的，着色器代码（本质是文本类文件）可与数据同时存在服务器供多客户端使用。这种可视化方案在某些数据不便分享的场景尤具吸引力。比如用户完全可以把数据存在本地终端，通过从服务器获取着色器代码，以实现数据的可视化，而不需要将数据上传到服务器（尤其是当多用户同时在上传数据时，这将带来极大的传输成本）。显然，对于比较大的数据量而言，传输可执行的代码远比传输数据要来得简单。
早期的Web可视化技术主要利用VRML和浏览器的Java插件，或者服务端的渲染实现，以及其他集成Java、JavaScript和Flash的方式。因带宽和网络延迟的限制，这些方式的体验都比较一般。由于浏览器技术的限制，服务端渲染的方式在当时更受欢迎。
但是，近些年Web技术发展迅速，目前Web可视化技术趋势已是通过WebGL和HTML5以充分利用用户终端的GPU加速渲染，而不需要浏览器加装任何的插件。基于GPU的可视化技术将计算渲染的负担由GPU承担，以改善渲染和交互的体验（否则使用javaSript在CPU上是不可行的）。这种通过用户终端进行渲染计算的方式优点在于其避免了网络延迟带来的影响，因为其不再需要反复与服务端交换交互操作参数和渲染生成的图片。当然，虽然有了上述的进步，将部分渲染计算分流到服务端渲染或预处理依然有助于浏览器端对于复杂场景的渲染。
本文主要对Web可视化技术进行综述，包括讨论最新的渲染技术、底层技术、以及优化算法策略等。这些通用技术共同构建了Web可视化应用的基础，因此，本文不仅关注高速、GPU加速的用户终端渲染技术，同样关注服务端渲染技术（比如网格化计算），以及如流媒体、数据压缩等降低带宽需求的技术。同时，我们讨论了各应用领域的一些Web可视化的应用程序，分析这些应用和前文所述基础技术的相关性，并进行了分类。最后，文章讨论了一些特殊的应用场景，并给出了一些落地的应用方案。
2. 技术方面
本节内容主要讨论可视化在web服务、网格化、云服务方面的技术基础，同时也涉及浏览器本地渲染、数据编码、数据传输等方面的技术。
远程可视化及web可视化通常采用CS（client-server）架构。网格化计算和云计算的可视化方法将大量数据的处理问题置于服务端（比如大型模型的渲染任务、复杂的预处理任务等），同时支持多客户端访问。在某些特殊场景下，比如来自仿真计算或其他处理后的结果数据已经存储在网格端或云端，这些源数据基本不大可能迁移，那么只能采取基于网格或云服务的可视化方案。
基于web的可视化方法充分利用了跨平台的浏览器以及对应的web部署和协同技术。在基于网格和基于云的可视化方案里，web可视化同样扮演了重要的作用，如将浏览器作为客户端访问入口。
2.1 作为Web服务的可视化
W3C组织将web服务定义为：用来支持机器与机器之间网络信息交互的软件系统。web服务的主要目标即为尽可能使不同软件应用和工具在共同完成某项特定任务时，其相互之间可以进行流畅的信息交互。因为web服务定义了统一的接口，各不同类型编程代码的应用程序即使在不同的运行环境执行，其相互之间依然可以实现顺畅的信息交互。web服务技术在异构分布式计算系统里显得尤为重要。
根据渲染管线（pipeline）如何拆分，基于web服务概念的可视化方法主要分为三类：
- 将所有的可视化管线作为一个黑盒，一个应用程序视为单个服务，用户通过交互界面配置需要可视化的数据并获得可视化结果。这种方式的优势是对于用户来说十分简单。但是，另一方面则也限制了用户对于更多可视化类型的选择。
- 将管线的每一个阶段分为独立的web服务。这种方式各部分的管线向用户开放，用户可通过集成不同类型的web服务来定制满足自己需求的多样化。各种不同类型的Web服务可由多方开发服务商提供、由不同的执行代码组成、运行在不同的环境。虽然这种方式为用户提供了最大的自由度，但是由于各服务之前的信息交互和数据交换成本，可能带来效率的降低。
- 将管线的每几个阶段打包为独立web服务。这种方式为前两种方式的结合，既为用户提供一定的自由度，又保证信息交换的效率。
若将数据可视化作为数据分析流程的一部分，相对于把可视化应用程序拆分为不同web服务，把其作为单个web服务将更有助于抽象。将可视化应用的管线的不同阶段分为不同的web服务，则更适用于程序开发者。开发者们更愿意集成不同性能的可视化技术，以充分利用不同硬件特性，为用户提供最有效的可视化服务。
另外一个重要的技术点则是如何处理可视化管线不同服务之间的数据交换。Web服务之间可以直接进行数据交换，也可通过数据中心进行数据交换。有研究表明前者的性能通常优于后者。
在实现方面，通用有两种主要的技术路径：基于SOAP的web服务和基于RESTful的web服务。由于RESTful更为简单，并更易与其他web标准集成，目前的主流更倾向于RESTful。但是，虽然基于RESTful的web服务在商业领域和云服务领域广泛应用，但在可视化服务方面却没有得到足够的关注。我们将在2.2和2.3部分讨论网格化和云计算环境下的可视化web服务。
Web服务使得不同工具可以基于标准的方式进行信息交互，不管其是用哪种代码编写的、在什么环境下运行或者在什么设备上。这将使得数据分析可以更加的自动化（在数据分析流程里可视化作为其中一部分）。各组元可以将其实现细节在自己内部封装，相互之间只要遵循一致的通信协议。将接口和实现分开，使得各组元可以更专注于针对某些特殊任务或硬件特性进行优化。
目前关于作为web服务的可视化的工作主要还是关注如何将web服务理念应用于可视化程序本身，关注可视化程序内部各子服务的信息交互，而没有过多关注在数据分析流程中可视化服务和其他数据分析工具的交互（如仿真和分析工具/服务）。不断增长的数据量和复杂的数据分析需求，使得单独的可视化工具并不足以满足某些特定的任务，因此需要考虑可视化工具与数据分析其他工具的融合。
通过为可视化服务提供不依赖于编程语言和运行平台的统一接口，各可视化服务之间的连接变得简单，并将进一步提高数据分析的自动化程度。通过复杂的可视化引擎，用户只需要输入可视化数据和提供部分可视化参数，就可以自动输出可视化结果。这将更有助于各行业领域的研究人员专注于研究各自领域的核心工作，而不用花费更多的时间在软件工具的集成上面。
2.2 基于网格计算的可视化
网格化计算是一种分布式计算模型，通过汇聚各节点的计算和存储资源池来提供高性能的计算架构。各网格的计算资源与集群计算类似分布，区别在于集群的每个计算节点属于同一个组织内，而网格计算的计算节点是跨组织的。因此，相对于集群计算通常是同构资源，网格化计算的资源通常是异构的。
基于网格化计算的可视化源自对于复杂高性能的仿真，需要通过各网格资源来满足计算和存储仿真结果。通常科学仿真和其他科学设备产生的数据量十分巨大，基本不大可能仅使用本地计算资源来实现该类数据的可视化，因此需要网格化计算架构。各网格的计算和存储资源在地理上是分散分布的，所以基于网格计算可视化的算法面临着如何在有限带宽和延迟的条件下高效利用这种分布式架构的挑战。
大多数的网格计算可视化工作充分利用了web服务。考虑到网格化计算资源的异构属性，这很好理解。
2.3 基于云计算的可视化
基于云计算的可视化可视为基于网格计算可视化的进一步发展。云计算为远程可视化带来了更高的弹性和量化平台。通常云服务的接入还是需要具有计算和存储限制的网络终端（比如手机、平板、笔记本等），所以基于云计算的可视化面临的挑战，依然来自于如何在尽量降低对网络终端要求的前提下，提高网络终端和云端之间数据传输的效率。为了应对这一挑战，通常利用云端进行那些要求复杂预处理的任务，仅从终端提取和传输可视化必须的数据。
目前的可视化技术依赖于GPU的计算能力以加速渲染，所以要求这些应用程序能够从云端虚拟机获取GPU资源。虽然大都数的虚拟机管理程序可以有效实现主要计算资源类型的虚拟化，比如CPU、硬盘、I/O设备等，但GPU能力的虚拟化支持并不太够。当前从虚拟机访问GPU的主要方法是通过GPU直通和虚拟GPU（当前由NVIDIA GRID或AMD Multiuser GPU提供）
基于GPU的云端渲染主要应用在游戏和远程桌面解决方案。游戏在远端渲染并以流媒体的形式传输到客户端。为了降低延迟，GPU通常具有内置视频压缩编码，以降低传输视频流时给CPU带来的负担。这些游戏服务的终端多为移动设备、游戏终端、或者电视。对于云端游戏来说，延迟依然是最大的挑战。因为交互性的云端可视化和游戏都对延迟敏感，所以当使用云端渲染方案时，基于云端的可视化面临一样的挑战。将云端计算和客户端渲染技术综合使用，不失为解决对于延迟敏感场景下问题的有效云端可视化方案（我们将在之后讨论）。
云端虚拟机服务并不是就没有上限。因为每一个虚拟机都需要完整的操作系统，存储要求和日常通讯负荷很高。通过I/O接口的日常的通讯来自于运行在虚拟机和实体硬件资源之间的服务、或者不同虚拟机之间的服务。目前轻量化的虚拟技术（如Docker容器）在计算资源共享的性能和效率方面具有更大的潜力。
同时结合云端和客户端计算资源的云端可视化方案，将优于单独的云端渲染方案。对于延迟敏感的可视化应用来说，最理想的是在客户端执行渲染，并将任务的预处理放在云端。GPU移动技术的进步使这种结合成为可能。客户端避免了因网络带来的延迟，适用于交互性的可视化程序。云计算已经在仿真领域应用，这些仿真通常产生巨量的数据，无法通过单个工作站实现可视化。而将仿真数据放在云端，则通过使用云端可视化服务，则避免了这些巨量数据的迁移。
对于云端GPU的使用，不仅限于实现云端的GPU加速渲染。服务端的GPU加速计算（如使用CUDA及OpenCL），能在节省能源的情况下提供更高的性能。因此，尤其对于移动设备来说，将高昂的计算放在云端，将获益不菲。
2.4 浏览器的本地渲染
在客户端渲染（如使用浏览器的本地渲染）的主要优势在于可视化过程中的交互。本地化渲染避免了服务端渲染方式所受的网络延迟影响。最近web技术的发展（尤其是JavaScript的性能提高以及WebGL的广泛使用）使得浏览器已经可以实现高性能的可视化渲染。本部分我们将主要讨论HTML5和WebGL相关的渲染技术，它们已经是浏览器无插件渲染的实际上的标准。
HTML5新引入的元素可通过JavaScript动态地绘制图形，支持2D上下文（context）以及3D上下文。2D上下文提供基于CPU的2D基本绘图渲染（HTML5支持的另外一个2D矢量图元素是）。3D上下文提供基于GPU的支持webgl的3D渲染。WebGL是OpenGL的一个特殊版本：OpenGL ES 2.0，专门用以支持浏览器端的3D渲染。因为上述上下文方式提供的API都是底层接口，所以诞生了很多库和框架，以简化他们的开发使用：（PS：做个预告，小编将在另一个系列翻译一篇专门针对Web 3D图形专题的文章，将更为详细的介绍目前流行的Web 3D图形库。）
- 如X3DOM和XML3D等框架都旨在将3D图形与HTML5的DOM（document object model，文档对象模型）集成。X3DOM通过X3D和HTML5集成以实现浏览器的3D图形支持。这一类的框架通过场景声明式的API完成3D渲染的WebGL顶层实现。这种集成方式与面向2D绘图的SVG类似，一个3D场景使用XML语言来描述，嵌入在元素标签内。
- 另一类通过浏览器访问GPU实现3D渲染的顶层封装库包括如Three.js和Babylon.js等。相比于X3DOM和XML3D类型，Three.js和Babylon.js这类库不再通过XML文档声明方式来实现3D场景，而是以JavaScript库的方式提供可编程的API。
- 虽然Three.js和Babylon已经实现了较高的顶层封装，应用十分广泛，但在更垂直的应用领域，为了更进一步简化编程过程，也出现了很多更顶层的封装库，极度降低了web 3D的可视化编程门槛。这一类的典型代表如EverAPI，最少仅需要四、五条代码即可通过EverAPI实现web 3D的展示，并默认集成了针对机械领域对3D模型常用的操作功能，如结构树、剖切图、标注等。
2.4.1 基于GPU的3D渲染
利用GPU的浏览器渲染技术多使用基于多边形的方法或射线跟踪法。基于多边形的技术通常使用基于WebGL构建的库来生成或从客户端导入网格，并将其上传到GPU渲染。在其他情况下，网格是从服务器传输到客户端。
但是，基于多边形的技术具有一些限制。为了获得顺滑的表面，需要精细的曲面细分（tessellation），从而帧速率与三角面片的数量成比例的降低。此外，大量的三角面片不仅会消耗大量内存，而且每次几何形状发生改变都将需要相当大的CPU-GPU带宽。同时，在浏览器环境中，如果CPU生成几何图形数据的过程被迟滞了，则又将进一步降低渲染性能。将几何图形的生成过程迁移到功能强大的服务器也不总能解决上述问题。网络延迟以及和网络及CPU-GPU互联的带宽可能仍会对渲染性能产生负面影响。为了缓解这些问题，一种更好的方法则是使用隐式、参数化几何体，并通过基于GPU的射线跟踪法渲染。这种方法确保了CPU到GPU之间更少的数据传输，并降低了在JavaScript中的计算代价。
基于GPU的射线跟踪法利用参数定义对象的隐式表面，并且在片段着色器中计算射线与对象的交点以生成物体表面。为了开始渲染并生成这些片段，通常会渲染替代几何体。例如，对象的全屏四边形或者紧密包围盒都可作为对象的一种替代几何体。这些技术的优点是即使对于大量数据也可以提供高渲染性能和高质量图像。根据所使用的实现算法，射线与物体交点的高效计算可能需要采用加速结构。
基于GPU的体积射线行进算法是目前直接提供体绘制的最先进的算法。此技术使用3D纹理（假设使用WebGL 2.0）或2D纹理集或图集进行数据存储。通常使用替代几何体（如体积数据的包围盒）以进行初始化渲染。与PC端的OpenGL类似，有两种途径可使用WebGL来实现此技术：多通道渲染和单通道渲染。
- 多通道渲染方法中，将替代几何体（通常是体积包围盒）渲染为纹理，以便在体积数据中获取射线的入射点和出射点。这些射线然后在体积遍历过程中使用，以获得这些采样射线的起点和方向。在片段着色器中，沿射线对体积进行采样、分类、选择性的着色、并迭代合成得到像素的最终颜色。
- 在单通道渲染方法中，对体积包围盒的正面和背面都进行栅格化。在片段着色器中，射线遍历沿着视线步进穿过体积并合成样本颜色，最终获得像素颜色。在WebGL 1.0中可视化大量体数据的主要限制在于纹理存储和对着色器动态循环的支持。
使用WebGL进行体积可视化的另一种方法是在服务器端提取几何图形并在客户端上执行渲染。如在服务端使用CUDA对原始的MRI数据进行预处理，然后在客户端使用Three.js进行渲染，服务端和客户端通过XML或者JSON格式传输几何文件。或在服务端利用VTK库从体数据提取切片图片，并将JPEG或PNG格式的图片发至客户端通过GPU渲染。
网格渲染：许多网格渲染技术使用渐进式网格来改善交互。这是通过对网格的不同细节程度（LOD，levels of detail）进行渐进解码和渲染来实现的。渐进式网格的主要思想是用低分辨率（基础网格）来表示网格数据，并结合各种算法操作（如定点分割）从基本网格重建网格，以获得所需细节程度的结果。这种表示法可实现高效的加载、解码和渲染。这是因为为了获得所需细节程度的模型表示，仅需要在上一细节程度级别的模型基础上进行网格重建操作，这减少了需要传输到客户端的数据，降低了带宽的使用。
2.4.2 SVG/Canvas的2D绘制
如前文所述，元素除了通过WebGL提供3D绘制外，还有2D图形绘制的API。它提供了使用JavaScript绘制路径及多个2D形状和文本的内置函数。
D3.js是一个用于信息可视化的JavsScript库，它建立在浏览器的DOM以及CSS和SVG之上。SVG为使用标记语言的进行2D图形渲染的另一种方法。D3.js允许用户将要可视化的数据绑定到DOM元素，并根据基础数据的属性值操纵器元素属性。它显示元素的文档模型而不是提供自定义的数据模型（这避免了在模型之间转换时产生额外的开销）。直接操作DOM可能会导致性能下降，尤其是对于大型数据集，因为每当DOM发生变化时，都可能要求浏览器进行布局、绘制和合成。但是，通过使用DOM模型，可以确保与其他Web标准的无缝互操作性。
2.5 数据编码与传输技术
高效的数据编码和传输对于浏览器中的交互可视化非常重要。如果没有有效的数据传输格式，带宽和延迟问题可能导致客户端等待数据加载时间过长。对于动态数据，这可能会妨碍实时数据更新，影响时间序列的动画效果流畅性。尽管数据压缩减少了要传输的数据量并因此节省了带宽，但它不能独自保证交互式数据的更新，因为压缩和解压时间的开销可能超过传输节省的时间。
理想情况下，从数据编码、传输、解码到渲染这个完整的数据传输管线，都应该综合优化，以获得平衡的端到端性能体验。需要技术只关注优化其中的一个或者几个环节。瓶颈通常在解码和渲染阶段，因为这两个阶段在客户端执行。针对网络提出的各种压缩和解压缩方法集中于允许有效的解码和渲染，而不是仅优化压缩率。
流式和渐进式网格格式是一种隐藏的方法，可以隐藏延迟并改善交互性，从而改善用户体验。网格数据通常以不同的细节级别表示，并且每个级别被编码为可以逐步解压缩并在客户端上呈现的单独的数据块。大多数方法专注于基于CPU的高效解码，另一个选择是使用GPU友好格式，可以将其直接上传到GPU。在这种情况下，解码完全在GPU上执行。这不仅可以通过减少客户端上的解码时间来提高性能，而且仅需要更少的CPU-GPU带宽。
3. 基于Web可视化的应用
以下列举一些基于Web可视化的行业应用。
粒子数据可视化
在浏览器中实现分子可视化在互联网的早期就很流行。分子数据可视化，例如小球模型，是基于粒子的可视化的一个示例，其中每个原子都描述为一个球体。每个球体的大小代表相应元素的范德瓦尔斯半径。使用基于多边形的渲染时，必须将这些球体细分为三角形，然后对其进行栅格化。下图为该领域应用的一个案例：
http://proteinformatics.charite.de/ngl/html/ngl.html
分子模拟中动态分子数据（轨迹）的可视化也是该领域科学家的一项重要功能，但是这一实现直到最近几年仅限于桌面解决方案。如2.4.1节所述，两种主要方法可用于渲染球体：基于GPU的射线投射和网格渲染。基于GPU的光线投射技术在渲染性能和图像质量方面提供了更好的结果。
体数据可视化
正如2.4所述，有研究者使用WebGL提出一种基于GPU的体积射线行进算法的早期实现。他们使用基于GPU的多线程体数据射线投射方法来可视化来自医学成像和天气雷达扫描的体数据。也有人提出用于医学图像分割和渲染的CS架构应用程序。这一分割算法使用一种基于图像的方法，从服务器上的原始数据中提取切片，并将它们作为JPEG或PNG图像发送到客户端，在其中可以对其进行操作以出发服务器上的图像分割。完成图像分割后的等值面发送到客户端渲染实现可视化。其服务器使用VTK库，客户端使用Three.js库（这一应用实例如下图）。这种方法最直接的应用为通过MR断层图像分割，获取患者的膝关节三维可视化（话说小编BOSS以前实验室就有做过这个）。
地理空间数据可视化
网络上的地理空间数据（包括4D时空数据）的可视化涵盖了各种数据，例如海洋数据，栅格图像，天气预报数据和城市模型。在所有基于Web的现代地理空间可视化中，常见的是将WebGL用于硬件加速渲染和其他现代HTML5技术。一些方法直接使用WebGL，而其他方法则使用声明性框架，例如X3DOM。X3DOM实现了X3D标准中的一个组件，用于可视化地理空间数据。
信息可视化
比如有研究者介绍了用于大型二维点数据的交互式可视化的散点图技术，该技术基于WebGL实现。该方法解决了常规散点图方式可视化大量点数据集时遇到的数据量过载问题。 原始实现中在CPU上执行的计算已使用“渲染到纹理”技术移至GPU，以获得更好的性能。
3D模型可视化
3D模型可视化历史则由来已久，早在上个世纪60年代就开始存在3D的CAD软件（比如UG、Solidworks等），只不过大多数时间都是基于客户端安装软件的形式而不是Web可视化。随着SAAS服务的发展，各传统的3D CAD公司都在做云端的迁移，逐渐实现基于Web的3D模型可视化，甚至可以直接基于Web 3D做产品的设计（如前端时间以4.7亿美金被PTC收购的onshape）,以及一些主要用于做3D协作项目管理，同时提供Web可视化功能的解决方案（比如EverCraft.co）
通用工具包
有很多基于Web的通用可视化工具包，涵盖了一系列应用领域，包括信息可视化，蛋白质可视化，医学可视化和地理空间可视化。 本节中讨论的大多数工具箱都使用了WebGL之类的基于浏览器的现代Web技术的客户端渲染方式。
比如比较流行的商用云端信息可视化解决方案以Tableau Online和TIBCO Spotfire Cloud为例。 这些解决方案提供了SaaS工具，用于本地或在线数据创建各种交互式可视化，并允许在用户之间共享可视化结果。这些商业解决方案通常可支持非常大的数据集和许多并发用户。
Cesium.js则是用于地理空间数据可视化的通用库，它基于WebGL进行快速渲染。 其支持各种标准数据格式以及glTF格式，用于在客户端和服务器之间进行3D数据交换。
而EverAPI（https://evercraft.co/api）库则主要针对工程类3D模型的可视化，其支持各种工程类数据格式如stp、stl、obj等，并默认集成了针对机械领域对3D模型常用的操作功能，如结构树、剖切图、标注等。
4. Web可视化技术的分类
文章调研了很多Web可视化应用案例（可见原文的参考文献），对基于Web可视化应用程序进行了一个分类，来评估相应可视化的技术应用发展。分类的第一要素是按各类应用程序所采取的可视化基础框架划分（比如Web服务、网格化、云端、浏览器本地渲染方式） ，第二要素则是按渲染的技术和算法方法（与可视化的数据类型相关）划分，第三要素则是按数据传输和渲染的优化算法划分。另外，还使用了其他的特征，比如压缩算法和GPU加速优化算法的使用，因为两者都可能对可视化的交互性产生重大影响。
下图则为文章对第3节中介绍的基于Web的可视化应用程序进行的分类结果，展示了各应用程序使用了哪些技术方法和基础框架。表中，各应用案例根据各自的行业领域进行了分类，同一应用领域之间又按时间的先后进行了排序，以便分析技术发展的潜在趋势。
5.总结
由于仿真技术、传感器技术和各类信息采集技术的发展（更不用说物联网的发展），远程可视化引起了人们的广泛兴趣，并努力利用更为强大的技术资源来辅助科学家和工程师们更好的分析和理解这些庞大的数据集。远程可视化的主要挑战仍然是带宽和延迟。其中带宽的问题大家已通过各种压缩技术和视频编码技术来试图缓解。 而网络延迟还没有得到十分充分的解决方案。
过去服务端进行远程渲染、通过图像/视频流的传输实现远程可视化的方案，是建立在用户客户端没有足够的计算能力以实现交互性渲染的基础上。 但是，随着移动设备上CPU和GPU技术以及网络技术的改进，这种情况正在发生改变。 将昂贵的预处理步骤放到服务器或云端、在用户客户端执行渲染的混合可视化方案可能更加有前途，因为这充分利用了各端的可用计算资源。 此外，在用户客户端渲染可解决网络延迟问题，这对于交互式可视化至关重要。
随着数据集的不断增长，即使有可能可视化所有数据，由于人类视觉系统的限制，生成的图像也可能变得难以理解。于是基于查询的可视化技术也变得越来越重要，其仅提取与当前任务相关的数据子集而不是一次可视化所有数据，这大大减少了带宽需求，并将本地渲染的计算要求降至最低。这种大型数据集的可视化可能需要类似于数据库的数据管理功能辅助。在数据管理和分析平台的基础上构建可视化算法将使可视化算法免于数据管理问题和数据源异构性的挑战。可视化层将仅关注可视化的渲染步骤， 数据访问和过滤可以由单独的数据服务层处理。
WebGL和HTML5使得浏览器有能力成为部署交互式图形应用程序的首选平台。 鉴于跨平台的浏览器无处不在，可视化工具可以利用所有可用的计算资源来支持异地研究团队实现协作可视化。 通过将移动、Web和云计算技术相结合，可以将全球各地的专家召集起来共同解决更为复杂的问题，从而加快科学研究。
总之，Web可视化的优势十分明显，尤其是对于那些潜在用户而言（即那些并不是每天盯着数据，但指不定什么场景下就成为数据可视化展示的观众）。当不需要安装任何软件就可以获得可视化结果的呈现时，Web可视化方案成为内容传播和教育的最佳选择。尤其是随着5G的推广，带宽和延迟带来的限制将越来越少。
EverCraft.co
我们相信。每个人都具有创新的力量，每一份对未来的设计都将让生活变得更有趣。
