现今网络地图服务已经非常流行，对于经常开发或者使用网络地图服务的人而言，那真是言必称OGC标准、行必用rest地图服务，至于rest服务是啥，OGC标准源起，则毫无知情，能套用就行。
rest网络地图服务源自于rest服务。rest是Representational State Transfer（表述性状态转移）的简称，rest由Roy Thomas Fielding博士在论文《Architectural Styles and the Design of Network-based Software Architectures》中提出，Fielding 博士是 HTTP/1.1 规范的主要制定者，并且深度参与了 URI, HTML 规范的设计。同时也是 Apache HTTP Server 项目的联合创始人，Apache 软件基金会的联合创始人。Fielding 博士的这篇博士论文，是 Web 发展史上极其重要的文献，奠定了现代 Web 架构。
按照中文解释rest:Representational State Transfer ----表述性状态转移，一听就是个很晦涩的词，也不知谁翻译的，基本上现在大家都在用这个词。当然玩计算机的人向来这样，总喜欢把很普通的东西搞得很高深，像什么重定向、分布式、云计算、深度学习、区块链啥的，真是无力吐槽。其实，在英文里面Representational State Transfer 前面还有个主语叫Resource，连起来是 Resource Representational State Transfer，结合网络中的应用，应该翻译为资源在网络中被使用的时候以某种方式进行了表现，使其前后的表现状态发生了改变或者转移。好吧，还是晦涩！比如：客户机在向服务器请求资源信息的时候，会通过URL获取资源的信息，而这个资源在服务器中表现为一种形式，在网络数据交换的时候表现为另外一种形式，在客户端展示的时候又表现为一种形式，这种信息资源在不同介质中的形式转换就是资源的表述性状态转移，REST将资源的状态以最适合客户端或服务端的形式从服务器端转移到客户端，它不关心底层的通信是啥，也不关心应用程序数据交换的动作是啥，只要每个资源是唯一的就行。与瞎子摸象的意思差不多，瞎子从不同角度获取大象的信息，不过大象还是大象，但不同的瞎子摸到象的不同部位，表达出大象的形象却发生了改变。在http上实现这些资源表述性状态转移的动词有：get 、put、post、delete.
当然，rest在实现的时候，也需要遵循IP/TCP，URI、HTTP 和 XML 这些基本协议。
换句话说，rest风格是一种面向服务资源的网络软件架构风格，或者更准确的说是一种网络软件设计思想，rest对资源的规定更加严格，只要某个网络软件架构风格与rest原则一致，都可以说是rest软件架构风格。Fielding 博士的rest本身受Web技术的影响很深，理论上REST架构风格并不是绑定在HTTP或者WEB上，只不过目前HTTP是唯一与REST相关的实例,而REST也确实带有很多的Web痕迹，我们甚至也回避不了URI、HTTP 和 XML 等来实现REST。
（一说到软件设计思想，总会让人觉得是一个玄之又玄的东西，其实也就是一些思维逻辑，比如：观察、比较、分析、综合、抽象、概括、判断、推理等等，表现在软件里面，有：分层、分割、综合、抽象等，至于教科书里的就有面向对象、面向过程的区别，都是思维逻辑的具体表现，不用深究。）
rest服务经历了网络环境下的软件通信---RPC远程调用---web技术下的软件通信----web service（SOA面向服务架构）----soap（面向活动的服务架构）----rest（面向资源的服务架构）等演变过程，现在的主流web服务实现方式就有XML-RPC、SOAP、REST，往往后者比前者更加轻量、简洁。（你如果在百度上随便搜索一个词，比如：思维，其链接形式为：https://www.baidu.com/s?wd=%E6%80%9D%E7%BB%B4&rsv_spt=1&rsv_iqid=0xa1cd971d0001ba58&issp=1&f=8&rsv_bp=1&rsv_idx=2&ie=utf-8&rqlang=cn&tn=baiduhome_pg&rsv_enter=0&rsv_dl=tb&oq=%25E6%2580%259D%25E7%25BB%25B4%25E9%2580%25BB%25E8%25BE%2591&rsv_t=ecdb7l8iifTGRYoOo8r8WRq6%2BSK6XmKBMJuArGvY8gcGtlgG3jWrOwwfxxJo6RIj%2BwGa&rsv_pq=ad24d8f5000b628f&inputT=724&rsv_sug3=42&rsv_sug1=40&rsv_sug7=100&rsv_sug2=0&rsv_sug4=2678。后面会跟一堆的字符串，如果套用rest风格，就会发现它是rest服务。）而这三种web服务实现方式其实也并不简单，看看百度查询链接就知道了，链接真是又长又臭。轻量、简洁的反面就是重量、复杂，XML-RPC、SOAP能实现的很多复杂功能，rest实现不了。
像其他软件设计风格声称的一样（面向过程，面向对象、面向服务、面向活动），rest也说自己是轻量级、跨平台、跨语言的架构方式，其设计原则为：
a，网络上的所有资源都可以被抽象为资源（Resource）
b，每个资源都有一个唯一的资源标识符（Resource identifier），
c，同一资源具有多种表现形式，如 html、xml、json、rjson、jsonp、png、bmp、gif 、jpg、jpeg、classic等。
d，对资源的各种操作不会改变资源的标识符
e，所有的操作都是无状态的（stateless）
（无状态：HTTP是无状态协议。无状态是指协议对于事务处理没有记忆能力，如果后续需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。）
f，符合REST原则的架构方式均可被称为RESTful
REST对资源的操作：
-GET：表示获取一个资源
-POST：表示创建一个新的资源
-PUT：表示修改一个资源的状态
-DELETE：表示删除一个资源
URL的组成
网路协议，这里包含http、https
服务器地址：https://ss2.bdstatic.com/
接口名称：8bo_dTSlR1gBo1vgoIiO_jowehsv/starpic
？参数列表：qt=satepc&u=x=45;y=9;z=8;v=009;type=sate&fm=46&app=webearth2&v=009&udt=20190912
其次URL定义限定
不要使用大写字母
使用中线-代替下划线——
参数列表应该被encode： gzip, deflate, br
http常用的响应状态码
200 操作成功
201 对象创建成功
204 操作成功，但是没有响应体
404 资源不存在
500 后台代码错误，服务器内部错误
貌似rest软件架构风格已经很超脱了，它可以不关心很多东西，有更好地扩展性，其实也不然。rest可以将数据、应用程序、API统一叫做资源，但是每个厂商、每个软件给你的资源排列和命名方式都是不一样的，你依然需要花很大力气去熟悉和实践。
你或许还听过面向服务的架构---SOA:Service-Oriented Architecture,这也是一种设计风格,设计风格还有面向对象、面向过程的呢。按照定义，面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。咋一看，面向服务的架构独立于实现服务的硬件平台、操作系统和编程语言，貌似很吊的样子，这不过是应该而已，其底层的还有COM/DCOM技术。。。。。
“脱离社会环境下的意义看待软件工程，除了造就一大批迂腐的学究，剩下的就是那些可怜又可悲的偏执笃行者。相信的人消费它，为之付出昂贵的生活成本——现实之荣华，制造煽动它的人，售卖它，从中牟取名利。 ”
我们来看看web service发展历史：
公元2000年前，互联网发展非常迅速，HTML得到了越来越多的应用，但专家们对HTML并不满意，因为它只是一个用于描述网页的文档语言，只是一个SGML在具体方面（Web上）的一个应用的实现，HTML不具有良好的扩展性，而SGML虽然无比强大，但又太过复杂，以至于甚至没有人知道它是个什么东西。
在这种情况下，专家们开始设计一种比SGML要简单的多、还要比HTML具有更好扩展性的文档标记语言，于是XML诞生了。
所以，XML并不是为WebService而诞生的。
XML诞生之后，得到了业界的热捧，当时街头巷尾都在传扬XML的伟大和无所不能，随便一个计算机书店里你都能看到半个书架的关于XML的著作。 （似乎计算机行业宣传的套路从未没改变过）
XML确实是很有用的东西，后来的事实也证明了这点，比如SVG、MathML、GML等都是XML的非常棒的具体应用。
但是当一个东西被炒的过热的时候，人们再选择它就不再单单是处于技术原因了，而是希望借助它的热力把自己的产品也捧上去。
这一点微软就做的很好，1998年，一个叫UserLand的小公司的一位牛人Dave Winer设计了XML-RPC,因为跟XML沾边，所以立刻就被微软看好了。这个XML-RPC最初其实就叫做SOAP，直到被微软看上并派人去一起合作。很快他们完成了最早的实现，并被改名为XML-RPC。
好了现在实现上没有问题了，但要推广，还是标准化一下比较好，于是微软把IBM, Oracle, Sun, Apple, Netscape等找来说我们一起把它标准化吧，这样我们大家就一起可以用它赚钱了，于是SOAP就这样形成了。
但大家知道，这些大厂商们制定标准那是各怀鬼胎啊，微软怎么可能把便宜就这么好心的让给其他人分享呢？所以SOAP标准里面除了一丁点的通用部分外，还包括允许私有扩展的内容。而且微软在这个制定过程中，已经开始做这部分内容了，所以SOAP刚刚出来，微软就抢先其他人推出了成熟的WebService产品。这就是后来大家在.NET 1.0中看到的WebService。
当时你会看到微软在宣传WebService时，最喜欢举的例子就是WebService可以传输.NET的数据集（DataSet)，这是一个看似非常强大的功能，但它也是微软对用户的最大误导，微软一边告诉你SOAP是跨平台、跨语言的国际标准，一边大讲特讲用WebService可以方便的传输.NET数据集，但是有一点微软就是不提，那就是这个数据集虽然使用WebService可以传输，但它并不是跨平台跨语言的，你只能在微软的.NET平台上来使用。能跨平台、跨语言的部分仅仅是一些简单类型以及这些类型的一些集合类型。
但微软为什么要这样宣传WebService呢？目的很明显，它就是让你以为用了WebService之后不用再担心跨语言跨平台的问题，但一旦你用它来传输了数据集，事情就不再是这样了，你已经被.NET平台给绑架了，从此你的WebService只能被.NET这一个平台独享，所以这是微软的一个阴谋。直到你真正开始做跨语言应用的时候才会发现的阴谋。
因为微软是最早实现WebService的，其它厂商比起它来慢了不止一点点。所以当WebService被普及开之后，IBM等厂商并没有占到什么便宜，所以，微软以外的厂商不干了，于是SOAP开始了它的重新修订。所以SOAP的修订并不仅仅是处于技术上的目的，更多的是各大厂商对利益的博弈。因此SOAP的每个修订版本跟前一个版本在兼容性上都很不好，甚至新版本会推荐你把旧版本中的特性完全放弃，原因就是旧版本对微软太有利了。
经过几番博弈之后，各大厂商的利益总算是得到了平衡，SOAP也就变成了今天的这般模样，那就是IBM推荐的，你们不要再传对象了，你们直接传XML吧。所以现在在IBM支持下的那些开源实现都是大力支持直接传XML的WebService的。
但它真正解决用户的问题了吗？没有，它非但没有解决用户的问题，而且还饶了一个大圈子最后把如何解决问题推给了用户。
但是对于IBM这些大厂商来说他们的目的已经达到了，经过这么长时间的洗脑，用户被一个不知道为什么这样做却不得不这样照着做的SOAP标准给绑架了，因为它被称为标准，虽然它实际上并不能解决你的问题，但因为你自己确实可以通过一些自己的方法来解决它所带来的问题，以至于让你相信这些问题是它帮你解决的，因为它的权威摆在那里，所以你几乎从来不怀疑它只是给你带来了问题让你解决，而不是帮你解决已有的问题。
但对于制定这个标准的大厂商们来说，他们的钱已经赚到了，所以不管SOAP和WebService本身究竟多差劲，他们是不会在意的，对他们来说赚钱的东西就是好东西，更何况将你绑架在了他们自己的平台和语言上赚钱，还能让你相信是跨平台的跨语言的呢。
直到现在微软在推的WebService仍然跟IBM资助的那些开源Java实现的WebService不能真正的做到互通，不信你就传个数据集试试，你甚至连泛型容器都不能互传，哦～确切的说，你连非泛型的容器（比如.NET中的ArrayList)都不能互传，为什么？因为在.NET中序列化ArrayList到SOAP时，它是被序列化为名称空间是http://schemas.microsoft.com/clr/ns/System.Collections的绑定于.NET平台的特殊类型的数据啦。这种情况下，你怎么可能像SOAP描述的那样跨语言传输真正的对象？
所以，基本上现在用SOAP的人都在用它传输字符串。
好了，现在大家应该明白了，SOAP其实是一个被微软和IBM这样的大厂商绑架了的标准，在这些大厂商自己的实现中包含了太多的私有东西，这样就造成了技术壁垒，你不可能真正的实现它所描述的跨语言跨平台特性，另外SOAP和WebService标准本身就非常复杂，WebService有一大串的标准，就连微软自己都无力完全实现这些，更何况那些没有大厂商支持的语言呢，其它的语言有些标称自己支持WebService了，实际上呢，支持的仅仅是最基本的部分而已，而大部分标准中的内容根本就没有实现，甚至有些语言提供的仅仅是XML解析工具，就标称已经支持WebService了，但最后所有的活还是要你自己来干。
可以随便查一下WebService表述为：Web service是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。Web Service技术， 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。依据Web Service规范实施的应用之间， 无论它们所使用的语言、 平台或内部协议是什么， 都可以相互交换数据。Web Service是自描述、 自包含的可用网络模块， 可以执行具体的业务功能。Web Service也很容易部署， 因为它们基于一些常规的产业标准以及已有的一些技术，诸如标准通用标记语言下的子集XML、HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。
至于soap:Simple Object Access Protocol,简单对象访问协议是交换数据的一种协议规范，是一种轻量的、简单的、基于XML（标准通用标记语言下的一个子集）的协议，它被设计成在WEB上交换结构化的和固化的信息。SOAP、WSDL(WebServicesDescriptionLanguage)、UDDI(UniversalDescriptionDiscovery andIntegration)之一， soap用来描述传递信息的格式， WSDL 用来描述如何访问具体的接口， uddi用来管理，分发，查询webService 。具体实现可以搜索 Web Services简单实例 ; SOAP 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。SOAP使用基于XML的数据结构和超文本传输协议(HTTP)的组合定义了一个标准的方法来使用Internet上各种不同操作环境中的分布式对象。
经常有人拿soap和rest比较，总是说rest比soap好，其实也没啥好不好的。发展阶段不一样、针对对象也不一样，后者总是吸收前者的优点，总是有些共性的东西，两者都是用在网络上传递交换数据的，只不过soap更加注重操作，rest更加注重资源，信息的检索查询用rest好一点，数据的操作用soap，比如银行的转账或许soap好一些，其核心业务是数据操作，soap毕竟由键值对演化而来。无论是操作还是资源，都是要为客户提供服务的。
网络地图服务也是随着网络服务的不断发展而发展的，相应web的设计风格和实现方式也在不断推陈出新，很多年前用的是XML-RPC服务，后面使用SOAP服务，到现在Rest服务大行其道。现行webgis层次结构如下：
rest地图服务就在地图服务器上，为客户端提供地图服务。分层使得系统前后端分离，对于开发或维护人员而言，只需要关心其对应的层，每层暴露通用的接口，以便其他业务使用，可扩展性强，缺点也是明显的，整个系统会更加地臃肿，庞大，维护需要更多的专业人员。现行的产品五花八门，了解分层才能将产品正确地对应于某一层上，当然个别产品会给出一整套的解决方案，如arcgis，但是它也毕竟不是万能，行业应用级的服务器需要服务器容器支持：如tomcat\iis\weblogic等等，虚拟容器：vmare \VirtualBox等等，以及各种各样的硬件或软件函数库。例举如下：
前端：dreamweaver,fileworks，axurerp,vue,javascript\html\css,针对于地图的前端开发openlayers
webservice
web应用服务器容器：tomcat\iis\weblogic，用于发布业务服务
地图服务器容器：arcserver\geoserver\mapserver
关系和非关系数据库容器：oracle\mysql\mongodb\haddoop\spark
开发框架或语言：mvc\.net\java\python\C++
虚拟容器：vmare \VirtualBox\docker
操作系统：windows\linux
数据采集终端：arcdesktop\udig
硬件：服务器、存储、旁路网络设备
其实以上有些层还有很多的程序或者软件支撑，甚至可以扩展至整个信息系统，比如数据采集，理论上也可以在web上完成，但是现今的技术却阻碍了它的扩展，很难想象几个T的遥感数据放在web上会是怎样一种结果，不仅仅是现有硬件配置的处理速率跟不上，也因为当今的web软件不能突破诸多瓶颈，我们了解到最好的遥感处理软件web工作方式也只是以任务的方式提交给系统，后台依然需要在远程服务器上本地执行。虽然esri、谷歌、阿里等公司宣称有web端的在线处理系统，但是具体的影像处理依然是在各自本地服务器上完成的（也是以任务方式提交），而后端更是连接着超大规模的计算机分布式集群。个人终端的web影像处理，光是互联网宽带的网速，就是一个不容小觑的问题。这几年深度学习用于图像分类很时髦，拿它用来做遥感影像处理，跟许多图像分类算法遇到的问题一样，依然跳不出参数多、有限元、耗费时间长、局部最优解、不能完全用作工程应用等难以自拔的怪圈。当然，有总比没有强，至少在进步。
对于使用rest地图服务的人而言，可以只关心rest地图服务能否使用即可。
百度影像地图服务：
高德影像地图服务：
https://webst04.is.autonavi.com/appmaptile?style=6&x=107107&y=57200&z=17
很明显也带有rest服务特征的，几乎现在所有的地图服务供应商都是使用Rest地图服务。但是他们的地图服务链接都是具有各服务商自己的标签，所规定的服务地址、样式、地图级别、层次各有各的风格，没有一个统一的标准，很难真正实现各个平台间数据真正共享。
针对上述情况，为了解决Web地图服务互操作的困难，实现互操作接口机制的开放性和标准型，作为全球最主要的地理信息互操作规范的制订者和提倡者，OGC（Open Geospatial Consortium，开放地理信息联盟） 做了多方面的努力，希望地图服务能够规范统一，OGC 服务是 OGC制定的一系列 GIS 服务规范，涉及多个领域，包括：地理信息科学与环境；安全防卫（包括国防）与地理空间情报；智慧城市，包括物联网与传感网、移动通信技术、三维与建筑环境；应急响应与灾害应对、航空运输、能源与公用事业等。通过国际标准化组织（ISO/TC211）或技术联盟（如OGC）制定空间数据互操作的接口规范，GIS软件商开发遵循这一接口规范的空间数据的读写函数，可以实现异构空间数据库的互操作。OGC 服务统称为 OWS（OGC Web Services）,比较热门的标准有wms、wfs、wcs、wmts、kml、gml等等.
Catalogue Service CS 用以发现、浏览服务器上数据、服务的元数据
CityGML 用以交换城市3D模型
KML KML 提供 XML 编码的地理数据集（从 Google 引入）
Coordinate Transformation Service CT 用以提供坐标系统及其转化的服务
Geography Markup Language GML 提供XML编码的地理数据集
Grid Coverage Service 栅格服务
Location Services LS 位置服务
Simple Features SFS 简单要素对象的通用描述
Web Coverage Processing Service WCPS 栅格处理Web服务
Web Coverage Service WCS 栅格Web服务 （Coverage栅格）
Web Feature Service WFS 要素Web服务（矢量）
Web Map Service WMS 地图Web服务
Web Map Tile Service WMTS 切片地图Web服务
Web Processing Service WPS 地理处理Web服务
Web Service Common OWS 描述了OGC Web服务的通用规范
OGC定义了三种地理参考信息模型：
Web Map Server(WMS)
Web Feature Server(WFS)
Web Coverage Server(WCS)
OGC 服务schema如下：
WMS
Web 地图服务（WMS）能够根据用户的请求返回相应的地图（包括PNG，GIF，JPEG等栅格形式或者是SVG和WEB CGM等矢量形式）。
WMS支持网络协议HTTP，所支持的操作是由URL定义的。
有三个重要操作GetCapabilities，GetMap，GetFeatureinfo。
GetCapabilities返回一个描述服务和XML文档。
GetMap返回一个地图影像。
GetFeatureinfo返回显示在地图上的某些特殊要素的信息。
还有一些其它操作如DescribeLayer，GetLegendGraphic，GetStyles，SetSytles。
事实上用传统的观点来解释，GetMap获得的就是在桌面程序中画在控件上的里的结果，是数据的表现。
GetFeatureInfo更容易理解，它和几乎所有的桌面程序上都用的Info按钮功能相同，都是用来获得屏幕坐标某处的信息，GetFeatureInfo中的参数是屏幕坐标、当前视图范围等，在一定程度上也方便了客户端的编写。
GetFeatureInfo可以同时返回多个图层中的要素信息，这一点和ArcGIS Desktop等也都是相同的。
WMS还包括一些GetLegend之类的返回图例信息的请求，也是完全按照桌面既有的标准定义的。
WFS
Web 要素服务（WFS）支持对地理要素的插入，更新，删除，检索和发现服务。该服务根据HTTP客户请求返回GML数据。
其基础接口是：GetCapabilities，DescribeFeatureType，GetFeature。
GetCapabilities返回一个描述服务和XML文档。
DescribeFeatureType返回要素结构，以便客户端进行查询和其他操作。
GetFeature可根据查询要求返回一个符合GML规范的数据文档。GetFeature是最重要的接口。
其它接口如Transaction 它不仅能提供要素读取，同时支持要素在线编辑和事务处理。
WFS对应于常见桌面程序中的条件查询功能，WFS通过OGC Filter构造查询条件，支持基于空间几何关系的查询，基于属性域的查询，当然还包括基于空间关系和属性域的共同查询。
在Web上，WFS的请求不是以SQL实现的，而是通过Filter XML来实现，可扩展性更强。WFS所返回的是查询的结果集，从某种程度上说，区别于WMS的“数据的表现”，WFS的结果集是由完整的Schema定义和约束的结果集，以GML为载体。这个结果集，类似于桌面程序查询结果的数据表。
Web地理覆盖服务（WCS）：提供的是包含了地理位置信息或属性的空间栅格图层，而不是静态地图的访问。
根据HTTP客户端要求发送相应数据，包括影像，多光谱影像和其它科学数据.
有二个重要操作GetCapabilities，GetCoverage：
GetCapabilities返回一个描述服务和XML文档，从中可获取覆盖的数据集合。
GetCoverage是在GetCapabilities确定查询方案和需要获取的数据之后执行，返回覆盖数据。
还有可选操作DescribeCoverageType。
WCS对应基于栅格数据的功能，与WMS基于矢量数据的特点相对应。
WPS
WPS 服务是通过网络向客户端提供 GIS 空间分析和处理功能的服务，这些 GIS 处理功能的操作对象是空间数据。
用于提供地理处理功能，取决于 GIS 服务器，我们可以提供多种功能，也可以自己去扩展这些功能。WPS 支持以下重要操作：
GetCapabilities请求服务元数据，查看该 WPS 支持的操作（指服务所规定的操作），以及所提供的地理处理功能列表和对应的简要描述
Describe Process请求某个地理处理的详细描述
Execute请求运行地理处理。该请求通常为带 XML 的 POST 方式。返回的响应是经过处理的数据。
WMTS
切片地图Web服务（OpenGIS Web Map Tile Service）当前版本是1.0.0。WMTS标准定义了一些操作，这些操作允许用户访问切片地图。WMTS可能是OGC首个支持RESTful访问的服务标准。
WMTS提供了一种采用预定义图块方法发布数字地图服务的标准化解决方案。WMTS弥补了WMS不能提供分块地图的不足。WMS针对提供可定制地图的服务，是一个动态数据或用户定制地图（需结合SLD标准）的理想解决办法。WMTS牺牲了提供定制地图的灵活性，代之以通过提供静态数据（基础地图）来增强伸缩性，这些静态数据的范围框和比例尺被限定在各个图块内。这些固定的图块集使得对WMTS服务的实现可以使用一个仅简单返回已有文件的Web服务器即可，同时使得可以利用一些标准的诸如分布式缓存的网络机制实现伸缩性
在一个WMTS服务中包括以下三个重要操作：
GetCapabilities获取服务元信息；
GetTile获取切片；
GetFeatureInfo获取点选的要素信息。
http请求和响应：
OWS可以通过GET和POST两种方式对服务请求-响应。而请求的参数编码也有两种：一种是键值对应（KVP1）、另一种是XML对象（XML）。它们的组合情况如下：
因此，结合soap、rest,比如某OWS服务的GetCapabilities操作，可能会有3种请求方式，当然，不同种类的服务并不一定实现所有的这些组合：
KVP格式
xml-soap格式
xml-rest格式
只要使用了OGC服务标准，都明显带有OGC标签----ows。
请求
操作请求在OGC中有不同的参数要求，
GetCapabilities请求基本参数：
响应
在调用 WMS 服务的时候，对于 GetCapabilities 请求，WMS服务器 将返回一个包含服务元数据格式的响应，并且该响应基于 WMS Capabilities XML schema。
GetTile参数：
GetFeatureInfo参数：
扫一扫
1340
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
