cesium介绍+OGC

记录学习cesium的过程，其中涉及专业术语，每次话到嘴边，不知道怎么表达，可能是不理解或者欠缺表达

所以一边学习，一边记录，结合实战经验，巩固学习内容，方便日后查阅

记录的过程中也会涉及到计算机其他方面的术语，以前接触过，同样缺少表达，因此一块记录下来，方便理解。

一、Cesium

Cesium是AGI公司计算机图形开发小组与2011年研发的三维地球和地图可视化开源JavaScript库，Cesium一词来源于化学元素铯，铯是制造原子钟的关键元素，研发小组通过命名强调Cesium产品精益求精，专注时间数据可视化。Cesium为三维GIS提供了一个高效的数据可视化平台。即：
（1）Cesium是一个跨平台、跨浏览器的展示三维地球和地图的JavaScript库
（2）Cesium使用WebGL来进行硬件加速图形，使用时不需要任何插件支持。
（3）Cesium是基于Apache2.0许可的开源程序，可以免费用于商业和非商业用途。

Cesium是一个用于显示三维地球和地图的开源js库。它可以用来显示海量三维模型数据、影像数据、地形高程数据、矢量数据等等。三维模型格式支持gltf、三维瓦片模型格式支持3d tiles。矢量数据支持geojson、topojson格式。影像数据支持wmts等。高程支持STK格式。

（跨平台：跨平台概念是软件开发中一个重要的概念，即不依赖于操作系统，也不依赖硬件环境。一个操作系统下开发的应用，放到另一个操作系统下依然可以运行。相对而言如果某种计算机语言不用修改代码即可做到高度跨平台，那么此语言就越抽象，硬件控制力就越低，只适合开发高度抽象的模型系统。诸如PHP和易语言，都已做到了跨平台。它们将可以在多种系统下开发，运行和维护。

跨平台泛指程序语言、软件或硬件设备可以在多种作业系统或不同硬件架构的电脑上运作。

严格而言是指用某种计算机语言编制的程序只需要做小量的修改，编译之后即可在另外一种平台下运行，此时并不提供Runtime/中间件环境。例如Java是一种提供Runtime环境的跨平台解决方案，而C是一种标准且严格的跨平台语言。

WebGL(全写Web Graphics Library)是一种3D绘图协议，这种绘图技术标准允许把JavaScript和OpenGL ES 2.0结合在一起，通过增加OpenGL ES 2.0的一个JavaScript绑定，WebGL可以为HTML5 Canvas提供硬件3D加速渲染，这样Web开发人员就可以借助系统显卡来在浏览器里更流畅地展示3D场景和模型了，还能创建复杂的导航和数据视觉化。显然，WebGL技术标准免去了开发网页专用渲染插件的麻烦，可被用于创建具有复杂3D结构的网站页面，甚至可以用来设计3D网页游戏等等。
WebGL完美地解决了现有的Web交互式三维动画的两个问题:第一，它通过HTML脚本本身实现Web交互式三维动画的制作，无需任何浏览器插件支持;第二，它利用底层的图形硬件加速功能进行的图形渲染，是通过统一的、标准的、跨平台的OpenGL接口实现的。

WebGL，是一项用来在网页上绘制和渲染复杂三维图形（3D图形），并允许用户与之进行交互的技术。

优势：

1.WebGL内嵌在浏览器中，不需要安装插件和库就可以直接在浏览器当中使用，最大优势。

2.WebGL直接使用文本编辑器就可以去开发，不需要搭建开发环境。

3.轻松跨平台，只要有浏览器就可以打开WebGL。

4.WebGL的技术规范继承自免费和开源的OpenGL标准，而后者在计算机图形学、电子游戏、计算机辅助设计等领域已被广泛使用多年，意味着你可以更简单的学习和使用WebGL。

Three,js简单地可以将它理解成three + js就可以了。three表示3D的意思，js表示javascript的意思。那么合起来，three.js就是使用javascript 来写3D程序的意思。three.js是JavaScript编写的WebGL第三方库。提供了非常多的3D显示功能。

）

二、OGC

OGC 全称是开放地理空间信息联盟(Open Geospatial Consortium),是一个非盈利的国际标准组织，它制定了数据和服务的一系列标准，GIS厂商按照这个标准进行开发可保证空间数据的互操作。

（常见）地图服务：

1.网络地图服务（WMS）利用具有地理空间位置信息的数据制作地图。其中将地图定义为地理数据可视的表现。WMS的设计是把数据发布之后将其变成图片再切分的服务，在服务器端把地图渲染成图片，浏览器端显示地图图片。地图图片大小根据浏览器视窗大小来定。WMS支持网络协议HTTP，所支持的操作是由URL定义的，能够根据用户的请求，返回相应的地图，包括PNG、GIF、JPEG等栅格形式，或者SVG或者WEB CGM等矢量形式。缺点显而易见，因为是现做，所以慢，它的优点是能保证数据的时效性，同时更新了数据之后不必重新切片，管理方便。适合数据更新频率高，数据量并不大的数据。

WMS提供如下操作:

GetCapabitities：返回服务级元数据，它是对服务信息内容和要求参数的一种描述。

GetMap：返回一个地图影像，其地理空间参考和大小参数是明确定义了的。

GetFeatureInfo：返回显示在地图上的某些特殊要素的信息。

GetLegendGraphic：返回地图的图例信息。

2.WMTS，网络地图瓦片服务（OpenGIS Web Map Tile Service），提供了一种采用预定义图块方法发布数字地图服务的标准化解决方案。WMTS标准定义了一些操作，这些操作允许用户访问切片地图。WMTS不同于WMS,它最重要的特征是采用缓存技术能够缓解WebGIS服务器端数据处理的压力，提高交互响应速度，大幅改善在线地图应用客户端的用户体验。WMTS是OGC主推的缓存技术规范，是目前各种缓存技术相互兼容的一种方法。

WMTS牺牲了提供定制地图的灵活性，代之以通过提供静态数据（基础地图）来增强伸缩性，这些静态数据的范围框和比例尺被限定在各个图块内。这些固定的图块集使得对WMTS服务的实现可以使用一个仅简单返回已有文件的Web服务器即可，同时使得可以利用一些标准的诸如分布式缓存的网络机制实现伸缩性。

下面以HTTTP KVP方式为例，介绍WMTS服务包含的三个操作，通过这三个操作可以实现对WMTS服务的读取。
GetCapabilities操作，获取服务的元信息；
GetTile操作，获取切片；
GetFeatureInfo操作，获取点选的要素信息。

3.切片地图服务（tile map Servcie,TMS）定义了一些操作，这些操作允许用户按需访问切片地图，访问速度更快，还支持修改坐标系，与WMTS类似，本质上遵循同样的切片规则。。缺点就是不够灵活，一旦数据更新，就要重新生成一次切片，数据更新频繁且地理范围大的情况下不建议使用。（不是OGC提出）

简单说来吧TMS和WMTS差异主要在于协议、瓦片组织方式，据说WMTS理论模型更好，反正且说吧。(摘抄https://www.csdn.net/tags/NtjaEgzsODQ4NjItYmxvZwO0O0OO0O0O.html)

1.协议

TMS是纯RESTful的；而WMTS可以有三种：KVP、SOAP、RESTful。

2.瓦片组织方式

三点：TMS瓦片是正方形、WMTS瓦片是矩形；在纵轴方向上面相反；WMTS中对应的不同比例尺瓦片可以尺寸不同。

4. WFS是指OGC的Web矢量（要素）服务（Web Feature Service），返回的是矢量级的地理标记语言GML编码，并提供对矢量的增加、修改、删除等事务操作，是对Web地图服务的进一步深入。WFS通过OGC Filter构造查询条件，支持基于空间几何关系的查询，基于属性域的查询，还包括基于空间关系和属性域的共同查询。WMS返回的是图层级的地图影像，而WFS是为了返回纯地理数据而设计的，它不包含任何关于绘制数据的建议。

（

瓦片地图原理：使用瓦片地图时，我们看到的是一张铺满整个屏幕的大的地图图片。实际上，这张大的图片是多个尺寸相同（通常是256*256像素）的小图片按照既定规则无缝拼接而成的，这些小图片就是瓦片。瓦片按照如下图所示的金字塔结构组织，每张瓦片都可通过级别、行列号唯一标记。在平移地图、缩放地图时，浏览器根据金字塔规则，计算出所需的瓦片，从瓦片服务器获取并拼接。

瓦片地图的优势：由于瓦片是静态的图片，可预先生成，通过缓存和CDN技术，瓦片服务器可提供高效的瓦片读取服务。此外，浏览器并行获取和显示多张小图片，比获取和显示一张大图片要高效的多。显示地图变成和显示图片一样简单，这也是互联网地图能够承载亿级规模用户的原因。

）

地图数据格式：

1. 一张图片是肯定可以作为地图数据源的。例如一张tiff格式的遥感影像，作为地图当然可以，另外，我们从arcgis中导出一张jpeg，png格式的地图，再通过网络发布出去当然也行。

那么，第一种地图数据源我们暂且可以概括为image（图片）类型的。

2 .矢量形式的，就像在arcgis里我们用编辑工具绘制的那种第五轮廓的多边形。还有一些不随放大程度改变而失真的SVG图形。这些都是矢量类型的。举个例子就是我们从arcgis中导出一个shapefile，shp文件，把它发布成互联网地图，也是可以的。这种类型我们归纳为vector（矢量）类型。

一个shape在数据库中实际上就是一张表每一个要素（feature）是表中的一行或者多行。shape的属性数据和普通的二维表一样存储，而几何图形信息被存放在一个叫geomtry的字段里。这个字段能够用文字描述图形形状信息。

一个shape再导入数据库之后一般是这样的：

那么他转化为json是这样的：

{
"type":"Feature",
"id":"indexmap_1984.32",
"geometry":{"type":"MultiPolygon","coordinates":[[[[122.5924457,39.20893603],[122.5924457,39.20889616],[122.59237779,39.20895737],[122.59235704,39.2090558],[122.59235704,39.20916682],[122.5923879,39.20926604],[122.59240432,39.20930654],[122.59244569,39.20931714],[122.5924814,39.20930969],[122.59257018,39.20929116],[122.59259042,39.20921871],[122.59253881,39.2091195],[122.59246644,39.20902658],[122.59245621,39.20898192],[122.5924457,39.20893603]]]]},
"geometry_name":"geom",
"properties":
{"gid":1,"gname":"保税区","shape_leng":0E-11,"shape_le_1":110.131221956,"shape_le_2":0.00105811399614,"shape_area":5.85151805058E-8
}
}

不同于往常的json，这种格式把数据库表里的图形字段geom里面的010600001.......转化成了"type":"MultiPolygon","coordinates":[[[[122.5924457,39.20893603]........这个看起来像是很多个坐标啊，事实上对于多边形来讲，记录的就是每个顶点的坐标值。于是，这种格式命名为GeoJSON类型。

3. GeoJSON是互联网地理数据传输过程中重要的格式，GeoJSON的强大之处在于它可以作为一种数据格式媒介，和其它几种数据格式进行相互转化，就例如上文提到的可以和数据库表格做转化，他也可以直接和shape格式的文件做转化。非常方便。而且它保存的数据是完整的，数据体积也很小。

4.既然提到了json，xml可是json 的老大哥啊，最早互联网数据传输的格式就是xml，后来人们觉得这种标记语言比较麻烦，数据量也大，才发明的json。于是地理学会的人们为了照顾一些互联网老年人，也在地理数据方面适配了xml类型的数据，叫做KML，GML，这两种都是用标记语言标记地理数据，如果有朋友喜欢用也是可以的。那么这种类型我们叫做KML，GML类型吧。

综上所述，互联网地图的数据源类型，从大层面上来分就两种，一种是栅格，一种是矢量。栅格数据源一般就是image类型的图片，tiff格式的遥感影像等等。而矢量数据源的形式多种多样，有GeoJSON，KML，GML，shapefile，svg等等。

OGC这个组织呢，根据上面讲到过的数据源分别为他们设计了一些服务。

第一种image类型的，图片格式的地图被封装成了叫做WMS的服务。

第二种矢量类型的数据源被封装成了WFS服务。意思是 web feature service 网络要素服务。矢量图形不会随着放大程度的改变而失真，图片做不到；两要素方便与交互和编辑，修改形状等，这一点图片也做不到。

第三种是image进行切片后的服务，叫做WMTS。WMTS比WMS 好的地方就是它能够加快加载速度，提升加载效率。可是它同时也失去了灵活性，你看的每一个区域都是被提前划分好的，限制在固定条带内的。

参考网站：

https://blog.csdn.net/weixin_45782925/article/details/122687181

https://blog.csdn.net/qq_30100043/article/details/70767241

https://younghappy.blog.csdn.net/article/details/85630292?spm=1001.2101.3001.6650.2&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-2.pc_relevant_default&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-2.pc_relevant_default&utm_relevant_index=5

https://blog.csdn.net/lz5211314121/article/details/116456296