linyang2903
- 浏览: 9228 次
- 性别:
- 来自: 北京
-
i. 序言
这篇文章解释了怎样把WMS扩展到适用于用户自定义的数据符号。你应该参照最新版的WMS说明书一起阅读。最新版的WMS说明书是在WMS1.1.1的基础上写成的。
介绍（Introduction）
地理数据视觉化的重要性不能被过分的强调。用来描绘数据（不管它是地理或制表用的数据）的技术是把原始信息转换成一个说明的或者支持决定的工具。从USGS的地形学地图系列到NOAA,从NIMA的航海图表到AAA的Triptik,细致的控制数据制图上的表达是对任何专业制图人员最基本的要求。
地理空间的用户（人或机器）可以参考这份文件来控制数据的视觉画像。现在的WMS说明书可以让信息的提供者通过为每一个数据组指定一组预先装置的视觉绘图来指明非常基本的设计选择。然而，尽管WMS现在可以为用户提供一系列的设计选项，但是它只能将每个样式的名字告诉给用户，而不能将图像在地图上的样子展示给你。更重要的是，用户不能自定义设计规则。人或机器要想去定义这些规则就需要一种用户和服务器都能理解的设计语言。定义这种语言（SLD）是这篇文章的重点，它可以用于描绘Web Map Servers, Web Feature Servers 和 Web Coverage Servers的输出。然而在很多情况下，用户需要了解一些存在于视讯遥控服务器上的数据，来以此作出一个合理的要求。因此在定义设计语言的基础上还要定义OGC services 新的执行指令。
描绘一个数据组有2种基本的方法。最简单的就是用同样的方法为所有的特征上色。例如，你可以想象WMS把a layer描绘成水道图，包括线条（河流和小溪）和多边形（湖泊，水塘，大海）。用户可能会告诉服务器把所有多边形里面都涂成浅蓝色，把多边形的边和所有的线条染成深蓝色。这种方法不需要了解数据的属性或特征类型，只需要一种语言去描述这些类型。这种方法在SLD文件的FeatureTypeStyle element里有所介绍。
另一个比较复杂的方法是根据一些属性，以不同的方式来描述数据的特征。例如，在一份道路数据组里，用3像素的红线表示高速路；2像素的黑线表示4车道的路；1像素的黑线表示2车道的路。要做到这点，用户需要知道数据组的什么属性代表道路类型。WMS已经有一个选项命令来执行这个要求，叫做DescribeLayer。这个命令返回了特征类型，并且WFS接口的DescribeFeatureType 命令可以告诉我们属性。
SLD执行规则
4．术语和定义
下面是出现在这篇文章里的术语和定义。
4．1
Operation- 一个物体被叫去执行一个改变或疑问的说明。
4．2
Interface- 被命名的命令组，描述一个整体的行为。
4．3
Service- 一个整体通过interface所提供的功能的不同的部分。
4．4
Service instance server- 一个Service实际的执行。
4．5
Client- 软件的组成部分，可以运用一个Server 里的一条执行命令。
4．6
Request- 一条命令被一个Client的执行。
4．7
Response- 从Server 返回到Client的命令的结果。
4．8
Map- 图像化表示的地理数据。
4．9
Capabilities XML- Service水平的描述命令的metadata和可被service instance利用的内容。
Web-Map-Server Integration
6.1 WMS1.1.1的简介
WMS1.1.1描述了以 “styled layer” 形式出现的地图的外观。“styled layer” 可以被看成一张有被符号化了的特征在上面的透明的纸。 “Map”是由许多个以特定顺序放在一起的“styled layer”组成的。它被说成是 “Z-ordered”. 用户可以通过加减“styled layer” 来定义更加复杂或简单的地图。
一个“styled layer” 代表了一种特定的 “layer” 和 “style” 的组合，在“style” 里“layer” 被符号化了。从概念上来说，“layer” 定义了一系列的特征，“style” 定义了这些特征是怎样被符号化了的。这个概念被体现在这样的事实里：一个 “layer” 可以以多种形式符号化。
在WMS的说明书里，对于一张地图的请求被译成一个HTTP-GET的请求，一张地图图像的样子是被“layer”和“style” 这两个参数来决定的。请看下面这个地图请求的例子（不完整的）（被分成多行显示只是为了方便演示）：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Rivers,Roads,Houses&
STYLES=CenterLine,CenterLine,Outline
结果被显示在下面：这个可以被看成是3个‘styled layer’，他们是：
Houses:Outline （房屋：轮廓）
Roads:CenterLine （道路：中线）
Rivers:CenterLine （河流：中线）
冒号用在这里是为了有助于讨论。河流styled layer位于道路styled layer下面，因为WMS使用的是“painter’s model”, 把LAYER列表里每个连续的layer画在前面一个的上面。因此，道路看起来是“跨越”了河流。同样的layer可以重复出现，但很少是以同一种style出现。
在表现直线物体的边界时，一个常用的制图技巧是先用一条彩色的加粗线画，然后再用一条比较细的浅色的线重新描一遍。这个被用在了下面道路绘制的例子里。
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Roads,Roads,Houses&
STYLES=Casing,CenterLine,Outline
根据上面所说的规则所绘制出来的图：被看成是3个styled layers，他们是：
Houses:Outline （房屋：轮廓）
Roads:CenterLine （道路：中心线）
Roads:Casing （道路：外罩）
值得注意的是,WMS不能被询问指出哪些styled layers 可以被有意义的组合和怎样组合。然而，一个可变通的client会允许用户去探究各种不同的可能性。
WMS1.1.1 处理WMS“认识”的，以名字来识别的styles 和layers。鉴于这个原因，在后面的文章里我们把上面提到的这样的styles 和layers 叫做“被命名的styles”和“被命名的layers”。WMS只提供了一种定义styled layer的方法，这里的styled layer是一个被命名的style和一个被命名的layer的组合。
6．2 通用于WMS和SLD的HTTP Request规则
现今，唯一一个直接被OGC网络服务器支持的DCP是WWW,或者更确切一点说是执行HTTP的互联网主服务器。这样每一个被service instance所支持的执行命令的在线资料都是HTTP URL。每个执行命令的URL可以不同也可以相同，由网络服务公司来决定。每个URL应该遵照[IETF RFC 2616]中的规则，要不然就是依赖于执行；只有构成service request的参数被OGC网络服务规范所批准。
HTTP支持2种请求方式：GET和POST。其中之一或者两者都是被定义成某一个OGC网络服务类型并且由一个service instance提供，在线资源URL的用法在每个情况下是不同的。基本的WMS规则为了执行命令只定义HTTP GET（对于某些命令，SLD WMS[10]定义HTTP POST）。
6．3 SLD
6.1介绍了WMS规则下的地图的外观怎样用styled layers的顺序来决定。设计也可以被描述成用用户定义的XML来将地图的外观译成编码，叫做SLD。SLD格式将在7-11部分里被详细的讨论。简单地来说，一个SLD包括一个由一序列styled-layer定义组成的SLD XML元素。这些styled-layer定义可能会使用被命名的或者用户自定义的layer和style。下面是一个简单的SLD例子，对应于前面部分的第一个例子：
<StyledLayerDescriptor version="1.0.0">
<NamedLayer>
<Name>Rivers</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Roads</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Houses</Name>
<NamedStyle>
<Name>Outline</Name>
</NamedStyle>
</NamedLayer>
</StyledLayerDescriptor>
NamedLayer和NamedStyle对应于CGI 参数的LAYERS和STYLES，“painter’s model”同样被用于Z-ordering。用了用户自定义设计后SLD XML文件会变得更加复杂。WMS-1.2 styled-layer 程序和SLD-1.0.0格式是相一致的。
6．4 用SLD的WMS Request
有三种途径可以让一个client得益于SLD符号表示：
Client用HTTP GET和WMS交流，但是Request可以参考一个远程的SLD。
Client用HTTP GET的方法但是包括SLD XML文件以一个SLD_BODY CGI参数并列于GET Request（特征被恰当地编码）。
Client用HTTP POST和WMS交流，GetMap Request被编译在XML里，并且包括一个被嵌入的SLD。
理论上第三种方法优于其他2个，但是缺少卖主对于XML-POST GetMap-request 方法的支持。
第二种方法是介于第一和第三种之间的，使用第二种方法可能会由于过度长的URL而遇到问题。
需要值得注意的是无论在哪种情况下WMS都不会提前知道SLD的内容。Clients的范围很广。其中一些可能会允许用户在一些提前定义好的地图之间转换，每个地图都是由它自己提前定义的SLD来指明。其他的一些会允许用户互动地去描述他们心中地图的样子并且建立必要的SLD。上面所描述的几种方法都允许一个client申请来做，但是第一种需要client能够把SLD文件放置在一个易被WMS获取到的网络地址上。
再来看一下前面部分里那个不完整的GetMap request 的例子：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Rivers,Roads,Houses&
STYLES=CenterLine,CenterLine,Outline&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
在6.2里我们已经讨论了怎样把LAYERS和STYLES参数编译于SLD。Request用了一个SLD参数来提及SLD，这个参数取代了LAYERS和STYLES参数。SLD本身必须易被WMS获取到并且被一个URL指明。URL必须在被包含为一个参数值前被编码，就像layer和style名字已经被编码一样。假设这个准备好的SLD文件的URL是：http://myclientsite.com/mySLD.xml
那么地图request将被转换成：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD=http%3A%2F%2Fmyclientsite.com%2FmySLD.xml&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
这个例子的SLD文件包含了6.2
StyledLayerDescriptor例子里的内容，并带有适当的标准XML题头标签。SLD文件还可以被并列包含在GET request里，就像在下面这个长的例子里：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD_BODY=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%
3F%3E%3C!DOCTYPE+StyledLayerDescriptor+SYSTEM+%22http%3A%2F%2Fsom
.site.com%2Fsld%2Fsld_072.xsd%22%3E%3CStyledLayerDescriptor+versi
on%3D%221.0.0%22%3E%3CNamedLayer%3E%3CName%3ERivers%3C%2FName%3E%
3CNamedStyle%3E%3CName%3ECenterLine%3C%2FName%3E%3C%2FNamedStyle%
3E%3C%2FNamedLayer%3E%3CNamedLayer%3E%3CName%3ERoads%3C%2FName%3E
%3CNamedStyle%3E%3CName%3ECenterLine%3C%2FName%3E%3C%2FNamedStyle
%3E%3C%2FNamedLayer%3E%3CNamedLayer%3E%3CName%3EHouses%3C%2FName%
3E%3CNamedStyle%3E%3CName%3EOutline%3C%2FName%3E%3C%2FNamedStyle%
3E%3C%2FNamedLayer%3E%3C%2FStyledLayerDescriptor%3E
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
如果在7-bit ASCII范围以外的UTF-8字符被应用，除了格外长的URL以外将会有其他复杂的情况出现，因为HTTP被规定使用ISO Latin-1字符组。这种方法的优点是client不需要把SLD文件发布在网络上并且不能用POST的简单的Client可以使用这个方法。
另一种方法是用带有SLD作为WMS1.2+一个组成部分的HTTP POST去和WMS交流。用这种方法，上面的例子可以被翻译成下面这个编译为POST的XML:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE GetMap
SYSTEM "http://some.site.com/wms/GetMap.xsd">
<ogc:GetMap xmlns:ogc="http://www.opengis.net/ows"
xmlns:gml="http://www.opengis.net/gml"
env:encodingStyle="http://www.w3.org/2001/09/soap-encoding" version="1.2.0" service="WMS">
<StyledLayerDescriptor version="1.0.0">
<NamedLayer>
<Name>Rivers</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Roads</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Houses</Name>
<NamedStyle>
<Name>Outline</Name>
</NamedStyle>
</NamedLayer>
</StyledLayerDescriptor>
<BoundingBox srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
<gml:coord>
<gml:X>-180.0</gml:X>
<gml:Y>-90.0</gml:Y>
</gml:coord>
<gml:coord>
<gml:X>180.0</gml:X>
<gml:Y>90.0</gml:Y>
</gml:coord>
</BoundingBox>
<Output>
<Format>image/jpeg</Format>
<Transparent>false</Transparent>
<Size>
<Width>1024</Width>
<Height>512</Height>
</Size>
</Output>
<Exceptions>application/vnd.ogc.se+xml</Exceptions>
</ogc:GetMap>
虽然这个例子描述了一个WMS规则request怎样被转换成可以使用SLD，这个流程可以被用于任何一个有效的SLD。具体来说，它可以被用于一个包含了用户自定义符号表示的SLD。
为了使HTTP-GET更加实用，SLD也可以被用在2个不同模式下，取决于LAYERS参数是否出现在request里。如果没有，那么在SLD文件里的所有被指明的layers被赋予所有定义的styles，相当于XML-POST的用法。如果出现了，那么只有被那个参数指明的layer被赋予，SLD被作为“style图书馆”来使用。
当一个SLD被作为style图书馆来使用，STYLES CGI参数在GetMap request里被按通常的方法来翻译，除了对于style名字的处理被规范化了，为的是要使在SLD里被定义的styles优先于那些储存于地图服务器里的被命名的styles。用户自定义的SLD styles可以被赋予名字，并且它们可以被标注为一个layer预设的style。更具体地来说，如果一个叫做“CenterLine”的style被指定给一个layer并且一个有着同样名字的style在SLD里被定义给了相应的layer，那么这个SLD style定义被使用了。否则标准的建立在地图服务器内部的被命名的style流程被使用。如果一个预设style的使用被指定了并且一个style 被指定成SLD中相对应的layer 的预设选项，那么SLD中的预设layer 被使用了；否则地图服务器里标准的预设style被使用。
6．5 WMS和WFS/WCS
如果一个WMS是用用户自定义的符号使特征符号化，确认特征数据的来源是必要的。设计这个规则的目的是要允许各种各样的支持用户自定义符号表达的WMS的执行。例如WMS会使特征或保存在远程WFS/WCS里的coverage数据符号化，或者它只能符号化来自某个预设特征/coverage 仓库里的数据。
为了支持这个观点，叫做REMOTE_OWS_TYPE 和REMOTE_OWS_URL的选项参数被引入到HTTP-GET GetMap requests,用来指引WMS到一个远程的WFS,WCS或者其他的作为特征/coverage数据预设来源的OWS服务器。目前REMOTE_OWS_TYPE参数允许的数值是“WFS” 和 “WCS”,未来可能会有更多的被允许。REMOTE_OWS_URL参数交出服务器基础的URL来用。（以前，单一的一个WFS参数被提供给这个程序，但是那样局限性很大）。例如，一个WFS的URL是http://anothersite.com/WFS?那么前面部分里的地图request将被转换成：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD=http%3A%2F%2Fmyclientsite.com%2FmySLD.xml&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG&
REMOTE_OWS_TYPE=WFS&
REMOTE_OWS_URL=http%3A%2F%2Fanothersite.com%2FWFS%3
这个例子代表了WMS和WFS/WCS之间最简单的关系。但是还有很多其他有可能出现的关系。为了使讨论便于理解，这篇文章里引入了2个概念：‘component servers’和 ‘integrated servers’
Component servers: 这些服务器松散的连接在一起并且可以在任何组合下工作。例如，一个component WMS 可以将来自任何一个它被指引去的WFS/WCS的特征/coverage数据符号化。
Integrated servers: 这些服务器紧密地联合在一起并且只能在特定的配置下工作。例如，一个integrated WMS可能只能将来自和它联系在一起的WFS/WCS的特征/coverage数据符号化。一个服务器是component还是integrated告诉我们它是怎样被执行的。例如一个WMS是一个有效的OGC WMS使得它正确地支持WMS接口。这并没有告诉我们任何消息关于WMS是怎样被执行的。但是，一个可以将特征/coverage数据符号化的 ‘component’ WMS只能通过WFS/WCS接口和数据接触,这里确实说了关于执行的事。当然一个component WMS被指向什么类型的WFS/WCS(component 或integrated)是不重要的。值得注意的是将会有其他的WMS出现，他们可以用不是来自特征数据的资源制作地图。
有一批可以支持用户自定义符号的WMS。更加详细地说明这一系列的2端是怎样的是最好的解释，一个‘component’ WMS代表着一端，‘integrated’ WMS代表着另一端。
•• Component WMS
主要地它是一个可以把从一个或多个远程WFS/WCS收集来的特征数据符号化的绘图机器。 它主要有以下这些特征：
o 没有事先定义的‘被命名的 ’layers 或styles。
o 只是支持WMS 接口。
o 可以符号化来自任何WFS/WCS的特征数据。
o 支持用户自定义的layers 和styles。
基于XSLT技术的WMS是属于这个类型的。
• Integrated WMS
这个服务器代表了一个紧密联系的特征仓库和一个绘图机器。它主要有以下这些特征：
o 有事先定义的‘被命名的’layers和styles。
o 支持WMS接口，WFS接口的DescribeFeatureType request，WCS接口的GetCapabilities或者 可供选择的 DescribeCoverageLayer requests。
o 只能符号化来自它自身内部的特征仓库的数据。
o 只能支持用户自定义的styles用于事先定义的‘被命名的’layers。
不管是用component 还是integrated WMS，它必须可以讯问潜在的特征仓库（虽然只是在相对表面的水平）。这是因为用户自定义的符号化用到的概念在以前是不被WMS所需要的。例如，WMS1.1使得可以使用[Named]Layer和[Named]Style 这样的概念来接触WMS，而用不到特征类型这样的概念。相反地用户自定义符号化需要能够利用特征类型和特征类型属性来定义新的layers和styles。例如，一个新的layer可能会被定义成某一个特征类型的全部特征。这份规则就是要试着确保建立支持用户自定义符号化WMS的障碍越低越好。
通过WFS/WCS接口，潜在的特征/coverage仓库被询问了。对于一个component WMS来说这不是什么问题，因为特征/coverage仓库本身就是一个远程的WFS/WCS。对于一个integrated WMS来说，服务器必须既支持WMS接口也支持最小范围的WFS/WCS操作。它必须支持WFS的DescribeFeatureType request 或者WCS的GetCapabilities和可供选择的DescribeCoverageLayer。这体现了一个在request里被用名字来指明的特征/coverage 类型的属性。并且如果WMS支持用户自定义layers，那么它必须支持WFS GetCapabilities request。对于一个WFS 的返回，WFS支持所有特征类型的名字。合起来这2个WFS requests允许clients 收集所有建立用户自定义符号化所需要的信息。单独地WCS GetCapabilities request 对于一个WCS已经足够了。
指出在哪里WMS可以找到要被符号化的特征数据也是很重要的.下面是所用到的规则：
1． 如果SLD在UserLayer元素的RemoteOWS元素中指明一个WFS或者WCS,那么它将被使用（见Section 7）; 否则
2． 如果GetMap request包括CGI REMOTE_OWS_TYPE和REMOTE_OWS_URL参数那么那个远程服务器将被使用；否则
3． WMS将使用一个预设的WFS或者WCS。
这种方法不允许来自不同WFS/WCS的特征/coverage被包含在相同的styled layer里;然而，它却允许不同的styled layers建立在来自不同的WFS/WCS的特征数据上。前2个规则只能被用于那些可以被引导到远程WFS/WCS的WMS。在响应一个GetCapabilities request时，WMS将显示出这种能力（见6.7）。对于一个integrated WMS来说，预设的WFC/WCS就是那个和它结合在一起的。然而，没有人知道为什么一个component WMS不能够使一个预设的WFS/WCS被定义。
6．6 DescribeLayer Request
定义一个用户自定义的style 需要被符号化的特征的信息，或者至少知道它们的特征类型。因为用户自定义的styles可以被用于一个被命名的layer， 所以我们需要一个程序，通过它client可以得到一个被命名的layer的特征/coverage 类型信息。这是另一个将WMS概念下的layers/styles和WFS/WCS概念下的特征类型/coverage layer连接起来的例子。为了做到这点，WMS会选择性地支持DescribeLayer request。它适用于多个layers。体现在下面的例子中：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=DescribeLayer&
LAYERS=Rivers,Roads,Houses
例子中的DescribeLayer 是REQUEST 参数的一个新的选项。LAYERS 是一个参数，它允许被命名的layers被用名字来指出。它被认为是一个比使WMS Capabilities 文件更加超负荷的更好的方法。
它的返回将是一个描述被指出的命名的layers的XML文件。如果任何一个被命名的layer都没有出现，那么返回将是一个报告例外的XML文件。
对于每个被命名的layer,描述里应该指出它是否确实建立在特征数据上，如果是，它将显示WFS/WCS（通过一个URL前缀）和特征类型。值得注意的是它对那些不能以这种方式被描述的命名layer是完全有效地。我们可以再利用WFS程序来显示怎样在一个WFS里指出特征类型，那就是使用Query 元素。附件B给出了返回的DTD。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE WMS_DescribeLayerResponse
SYSTEM "http://some.site.com/sld/DSR.dtd" >
<WMS_DescribeLayerResponse version="1.1.0" >
<!-- 'Layer_A' comes from the wfs specified by
the prefix "http://www.mywfs.com/WFS?" and has features
of types 'Road_FT' and 'Route_FT' -->
<LayerDescription name="Layer_A"
wfs="http://www.mywfs.com/WFS?">
<Query typeName="Road_FT" />
<Query typeName="Route_FT" />
</LayerDescription>
<!-- 'Layer_B' cannot be described in terms of
a WFS and so has no wfs attribute and no contents -->
<LayerDescription name="Layer_B">
</LayerDescription>
</WMS_DescribeLayerResponse>
即使是一个integrated WMS也要给出一个WFS/WCS前缀，因为这样可以允许DescribeFeatureType requests 的运行。但是常见的是，也许一个WMS不支持UserLayers 却允许UserStyles 被用于命名的layers。在这种情况下，支持DescribeLayer request 是唯一的可相互操作的方法使得一个client能够指定用户自定义的符号化。
6．7 对于WMS GetCapabilities的加强
被WMS支持的GetCapabilities request 必须返回足够的信息，使client可以继续建立有效的requests。例如，一个WMS的capabilities包括哪个被命名的layers是WMS知道的。GetMap request 不是有效的如果它指向一个WMS不知道的被命名的layer。为了保证和不同的WMS有效地联系，包括上面所说的integrated/component WMS，capabilities 返回已经被加强了。具体地说，它可以描述下面这些信息：
1 WMS提供SLD支持么？
2 Client可以用HTTP POST(有一个嵌入的SLD)和/或HTTP GET(有一个SLD或SLD_BODY参数)去发表一个request么？
3 WMS支持用户自定义的layers么？
4 WMS支持用户自定义的styles么？
5 WMS可以被‘引导’到远程的OWS服务器么？（WMS支持在HTTP-GET requests里的REMOTE_OWS_SERVICE 和 REMOTE_OWS_URL参数么？支持在SLD里的RemoteOWS 么？）
6 WMS支持DescribeLayer request么？
一个WMS可能不支持被命名的layers/styles，体现在当描述它的capabilities时不会返回任何Layer元素。这个方法使得它能支持用户自定义的styles而不用支持用户自定义的layers。这种情况对于那些只描述远程特征的component WMS最为普遍。然而，这个对于WMS capabilities的描述没有明确地提到‘integrated’和 ‘component’类型。
前四条都代表了驾驭用户自定义符号化的能力的不同方面。1.1.0 WMS-Capabilities DTD引入了包含在Capability元素里面的UserDefinedSymbolization元素。这个新的元素包含了WMS支持用户自定义符号化能力的信息：
<!-- Elements indicating the level of support the WMS provides
for user-defined symbolization. By default there is no support.
-->
<!ELEMENT UserDefinedSymbolization (SupportedSLDVersion*)>
<!ATTLIST UserDefinedSymbolization
<!-- If the WMS supports a
StyledLayerDescriptor (SLD) then the
SLD parameter can be used in place of LAYERS and STYLES
parameters in a GetMap request. -->
SupportSLD (0 | 1) "0"
<!-- If the WMS supports UserLayers then users can define their
own layers in the SLD in addition to NamedLayers already known to
the WMS. -->
UserLayer (0 | 1) "0"
<!-- If the WMS supports UserStyles then users can define their
own styles in the SLD to be applied to previously specified
layers. -->
UserStyle (0 | 1) "0"
<!-- If the WMS supports remote WFS or WCS then a remote service
can be specified as the source of features to be symbolized. -->
RemoteWFS (0 | 1) "0"
RemoteWCS (0 | 1) "0">
<!-- Indication of what SLD version(s) are supported by a WMS -->
<!ELEMENT SupportedSLDVersion (#PCDATA)>
最后2条需要是可以被capabilities描绘地，用WMS capabilities的元素来处理，另外加上一个由DescribeLayer元素表现的新request 类型。这个Request元素可以被用来描述是否一个request可以被HTTP操作（作为一个DCP特定的instance）,如果是，这个request是否可以使用HTTP GET 和/或POST。
<!-- DescribeLayer interface: Presence of theDescribeLayer
element means this server can return a description of a specified
layer -->
<!ELEMENT DescribeLayer (Format+, DCPType+)>
现在被DescribeLayer request支持的唯一的格式是XML译码（在附件B里有解释）。对于WMS1.0.0到1.0.7，这种格式被叫做“WMS_XML”。对于WMS1.0.8以上，它是MIME 格式“application/vnd.ogc.wms_xml”.
Layers
7.1 SLD Root Element
一个SLD文件被定义为一个styled layers的序列。Root StyledLayerDescriptor被下面的XML-方案片断所定义：
<xs:element name="StyledLayerDescriptor">
<xs:complexType>
<xs:choice minOccurs="0"
maxOccurs="unbounded">
<xs:element ref="sld:NamedLayer"/>
<xs:element ref="sld:UserLayer"/>
</xs:choice>
<xs:attribute name="version" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
这篇文章解释了怎样把WMS扩展到适用于用户自定义的数据符号。你应该参照最新版的WMS说明书一起阅读。最新版的WMS说明书是在WMS1.1.1的基础上写成的。
介绍（Introduction）
地理数据视觉化的重要性不能被过分的强调。用来描绘数据（不管它是地理或制表用的数据）的技术是把原始信息转换成一个说明的或者支持决定的工具。从USGS的地形学地图系列到NOAA,从NIMA的航海图表到AAA的Triptik,细致的控制数据制图上的表达是对任何专业制图人员最基本的要求。
地理空间的用户（人或机器）可以参考这份文件来控制数据的视觉画像。现在的WMS说明书可以让信息的提供者通过为每一个数据组指定一组预先装置的视觉绘图来指明非常基本的设计选择。然而，尽管WMS现在可以为用户提供一系列的设计选项，但是它只能将每个样式的名字告诉给用户，而不能将图像在地图上的样子展示给你。更重要的是，用户不能自定义设计规则。人或机器要想去定义这些规则就需要一种用户和服务器都能理解的设计语言。定义这种语言（SLD）是这篇文章的重点，它可以用于描绘Web Map Servers, Web Feature Servers 和 Web Coverage Servers的输出。然而在很多情况下，用户需要了解一些存在于视讯遥控服务器上的数据，来以此作出一个合理的要求。因此在定义设计语言的基础上还要定义OGC services 新的执行指令。
描绘一个数据组有2种基本的方法。最简单的就是用同样的方法为所有的特征上色。例如，你可以想象WMS把a layer描绘成水道图，包括线条（河流和小溪）和多边形（湖泊，水塘，大海）。用户可能会告诉服务器把所有多边形里面都涂成浅蓝色，把多边形的边和所有的线条染成深蓝色。这种方法不需要了解数据的属性或特征类型，只需要一种语言去描述这些类型。这种方法在SLD文件的FeatureTypeStyle element里有所介绍。
另一个比较复杂的方法是根据一些属性，以不同的方式来描述数据的特征。例如，在一份道路数据组里，用3像素的红线表示高速路；2像素的黑线表示4车道的路；1像素的黑线表示2车道的路。要做到这点，用户需要知道数据组的什么属性代表道路类型。WMS已经有一个选项命令来执行这个要求，叫做DescribeLayer。这个命令返回了特征类型，并且WFS接口的DescribeFeatureType 命令可以告诉我们属性。
SLD执行规则
4．术语和定义
下面是出现在这篇文章里的术语和定义。
4．1
Operation- 一个物体被叫去执行一个改变或疑问的说明。
4．2
Interface- 被命名的命令组，描述一个整体的行为。
4．3
Service- 一个整体通过interface所提供的功能的不同的部分。
4．4
Service instance server- 一个Service实际的执行。
4．5
Client- 软件的组成部分，可以运用一个Server 里的一条执行命令。
4．6
Request- 一条命令被一个Client的执行。
4．7
Response- 从Server 返回到Client的命令的结果。
4．8
Map- 图像化表示的地理数据。
4．9
Capabilities XML- Service水平的描述命令的metadata和可被service instance利用的内容。
Web-Map-Server Integration
6.1 WMS1.1.1的简介
WMS1.1.1描述了以 “styled layer” 形式出现的地图的外观。“styled layer” 可以被看成一张有被符号化了的特征在上面的透明的纸。 “Map”是由许多个以特定顺序放在一起的“styled layer”组成的。它被说成是 “Z-ordered”. 用户可以通过加减“styled layer” 来定义更加复杂或简单的地图。
一个“styled layer” 代表了一种特定的 “layer” 和 “style” 的组合，在“style” 里“layer” 被符号化了。从概念上来说，“layer” 定义了一系列的特征，“style” 定义了这些特征是怎样被符号化了的。这个概念被体现在这样的事实里：一个 “layer” 可以以多种形式符号化。
在WMS的说明书里，对于一张地图的请求被译成一个HTTP-GET的请求，一张地图图像的样子是被“layer”和“style” 这两个参数来决定的。请看下面这个地图请求的例子（不完整的）（被分成多行显示只是为了方便演示）：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Rivers,Roads,Houses&
STYLES=CenterLine,CenterLine,Outline
结果被显示在下面：这个可以被看成是3个‘styled layer’，他们是：
Houses:Outline （房屋：轮廓）
Roads:CenterLine （道路：中线）
Rivers:CenterLine （河流：中线）
冒号用在这里是为了有助于讨论。河流styled layer位于道路styled layer下面，因为WMS使用的是“painter’s model”, 把LAYER列表里每个连续的layer画在前面一个的上面。因此，道路看起来是“跨越”了河流。同样的layer可以重复出现，但很少是以同一种style出现。
在表现直线物体的边界时，一个常用的制图技巧是先用一条彩色的加粗线画，然后再用一条比较细的浅色的线重新描一遍。这个被用在了下面道路绘制的例子里。
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Roads,Roads,Houses&
STYLES=Casing,CenterLine,Outline
根据上面所说的规则所绘制出来的图：被看成是3个styled layers，他们是：
Houses:Outline （房屋：轮廓）
Roads:CenterLine （道路：中心线）
Roads:Casing （道路：外罩）
值得注意的是,WMS不能被询问指出哪些styled layers 可以被有意义的组合和怎样组合。然而，一个可变通的client会允许用户去探究各种不同的可能性。
WMS1.1.1 处理WMS“认识”的，以名字来识别的styles 和layers。鉴于这个原因，在后面的文章里我们把上面提到的这样的styles 和layers 叫做“被命名的styles”和“被命名的layers”。WMS只提供了一种定义styled layer的方法，这里的styled layer是一个被命名的style和一个被命名的layer的组合。
6．2 通用于WMS和SLD的HTTP Request规则
现今，唯一一个直接被OGC网络服务器支持的DCP是WWW,或者更确切一点说是执行HTTP的互联网主服务器。这样每一个被service instance所支持的执行命令的在线资料都是HTTP URL。每个执行命令的URL可以不同也可以相同，由网络服务公司来决定。每个URL应该遵照[IETF RFC 2616]中的规则，要不然就是依赖于执行；只有构成service request的参数被OGC网络服务规范所批准。
HTTP支持2种请求方式：GET和POST。其中之一或者两者都是被定义成某一个OGC网络服务类型并且由一个service instance提供，在线资源URL的用法在每个情况下是不同的。基本的WMS规则为了执行命令只定义HTTP GET（对于某些命令，SLD WMS[10]定义HTTP POST）。
6．3 SLD
6.1介绍了WMS规则下的地图的外观怎样用styled layers的顺序来决定。设计也可以被描述成用用户定义的XML来将地图的外观译成编码，叫做SLD。SLD格式将在7-11部分里被详细的讨论。简单地来说，一个SLD包括一个由一序列styled-layer定义组成的SLD XML元素。这些styled-layer定义可能会使用被命名的或者用户自定义的layer和style。下面是一个简单的SLD例子，对应于前面部分的第一个例子：
<StyledLayerDescriptor version="1.0.0">
<NamedLayer>
<Name>Rivers</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Roads</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Houses</Name>
<NamedStyle>
<Name>Outline</Name>
</NamedStyle>
</NamedLayer>
</StyledLayerDescriptor>
NamedLayer和NamedStyle对应于CGI 参数的LAYERS和STYLES，“painter’s model”同样被用于Z-ordering。用了用户自定义设计后SLD XML文件会变得更加复杂。WMS-1.2 styled-layer 程序和SLD-1.0.0格式是相一致的。
6．4 用SLD的WMS Request
有三种途径可以让一个client得益于SLD符号表示：
Client用HTTP GET和WMS交流，但是Request可以参考一个远程的SLD。
Client用HTTP GET的方法但是包括SLD XML文件以一个SLD_BODY CGI参数并列于GET Request（特征被恰当地编码）。
Client用HTTP POST和WMS交流，GetMap Request被编译在XML里，并且包括一个被嵌入的SLD。
理论上第三种方法优于其他2个，但是缺少卖主对于XML-POST GetMap-request 方法的支持。
第二种方法是介于第一和第三种之间的，使用第二种方法可能会由于过度长的URL而遇到问题。
需要值得注意的是无论在哪种情况下WMS都不会提前知道SLD的内容。Clients的范围很广。其中一些可能会允许用户在一些提前定义好的地图之间转换，每个地图都是由它自己提前定义的SLD来指明。其他的一些会允许用户互动地去描述他们心中地图的样子并且建立必要的SLD。上面所描述的几种方法都允许一个client申请来做，但是第一种需要client能够把SLD文件放置在一个易被WMS获取到的网络地址上。
再来看一下前面部分里那个不完整的GetMap request 的例子：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Rivers,Roads,Houses&
STYLES=CenterLine,CenterLine,Outline&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
在6.2里我们已经讨论了怎样把LAYERS和STYLES参数编译于SLD。Request用了一个SLD参数来提及SLD，这个参数取代了LAYERS和STYLES参数。SLD本身必须易被WMS获取到并且被一个URL指明。URL必须在被包含为一个参数值前被编码，就像layer和style名字已经被编码一样。假设这个准备好的SLD文件的URL是：http://myclientsite.com/mySLD.xml
那么地图request将被转换成：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD=http%3A%2F%2Fmyclientsite.com%2FmySLD.xml&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
这个例子的SLD文件包含了6.2
StyledLayerDescriptor例子里的内容，并带有适当的标准XML题头标签。SLD文件还可以被并列包含在GET request里，就像在下面这个长的例子里：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD_BODY=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%
3F%3E%3C!DOCTYPE+StyledLayerDescriptor+SYSTEM+%22http%3A%2F%2Fsom
.site.com%2Fsld%2Fsld_072.xsd%22%3E%3CStyledLayerDescriptor+versi
on%3D%221.0.0%22%3E%3CNamedLayer%3E%3CName%3ERivers%3C%2FName%3E%
3CNamedStyle%3E%3CName%3ECenterLine%3C%2FName%3E%3C%2FNamedStyle%
3E%3C%2FNamedLayer%3E%3CNamedLayer%3E%3CName%3ERoads%3C%2FName%3E
%3CNamedStyle%3E%3CName%3ECenterLine%3C%2FName%3E%3C%2FNamedStyle
%3E%3C%2FNamedLayer%3E%3CNamedLayer%3E%3CName%3EHouses%3C%2FName%
3E%3CNamedStyle%3E%3CName%3EOutline%3C%2FName%3E%3C%2FNamedStyle%
3E%3C%2FNamedLayer%3E%3C%2FStyledLayerDescriptor%3E
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
如果在7-bit ASCII范围以外的UTF-8字符被应用，除了格外长的URL以外将会有其他复杂的情况出现，因为HTTP被规定使用ISO Latin-1字符组。这种方法的优点是client不需要把SLD文件发布在网络上并且不能用POST的简单的Client可以使用这个方法。
另一种方法是用带有SLD作为WMS1.2+一个组成部分的HTTP POST去和WMS交流。用这种方法，上面的例子可以被翻译成下面这个编译为POST的XML:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE GetMap
SYSTEM "http://some.site.com/wms/GetMap.xsd">
<ogc:GetMap xmlns:ogc="http://www.opengis.net/ows"
xmlns:gml="http://www.opengis.net/gml"
env:encodingStyle="http://www.w3.org/2001/09/soap-encoding" version="1.2.0" service="WMS">
<StyledLayerDescriptor version="1.0.0">
<NamedLayer>
<Name>Rivers</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Roads</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Houses</Name>
<NamedStyle>
<Name>Outline</Name>
</NamedStyle>
</NamedLayer>
</StyledLayerDescriptor>
<BoundingBox srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
<gml:coord>
<gml:X>-180.0</gml:X>
<gml:Y>-90.0</gml:Y>
</gml:coord>
<gml:coord>
<gml:X>180.0</gml:X>
<gml:Y>90.0</gml:Y>
</gml:coord>
</BoundingBox>
<Output>
<Format>image/jpeg</Format>
<Transparent>false</Transparent>
<Size>
<Width>1024</Width>
<Height>512</Height>
</Size>
</Output>
<Exceptions>application/vnd.ogc.se+xml</Exceptions>
</ogc:GetMap>
虽然这个例子描述了一个WMS规则request怎样被转换成可以使用SLD，这个流程可以被用于任何一个有效的SLD。具体来说，它可以被用于一个包含了用户自定义符号表示的SLD。
为了使HTTP-GET更加实用，SLD也可以被用在2个不同模式下，取决于LAYERS参数是否出现在request里。如果没有，那么在SLD文件里的所有被指明的layers被赋予所有定义的styles，相当于XML-POST的用法。如果出现了，那么只有被那个参数指明的layer被赋予，SLD被作为“style图书馆”来使用。
当一个SLD被作为style图书馆来使用，STYLES CGI参数在GetMap request里被按通常的方法来翻译，除了对于style名字的处理被规范化了，为的是要使在SLD里被定义的styles优先于那些储存于地图服务器里的被命名的styles。用户自定义的SLD styles可以被赋予名字，并且它们可以被标注为一个layer预设的style。更具体地来说，如果一个叫做“CenterLine”的style被指定给一个layer并且一个有着同样名字的style在SLD里被定义给了相应的layer，那么这个SLD style定义被使用了。否则标准的建立在地图服务器内部的被命名的style流程被使用。如果一个预设style的使用被指定了并且一个style 被指定成SLD中相对应的layer 的预设选项，那么SLD中的预设layer 被使用了；否则地图服务器里标准的预设style被使用。
6．5 WMS和WFS/WCS
如果一个WMS是用用户自定义的符号使特征符号化，确认特征数据的来源是必要的。设计这个规则的目的是要允许各种各样的支持用户自定义符号表达的WMS的执行。例如WMS会使特征或保存在远程WFS/WCS里的coverage数据符号化，或者它只能符号化来自某个预设特征/coverage 仓库里的数据。
为了支持这个观点，叫做REMOTE_OWS_TYPE 和REMOTE_OWS_URL的选项参数被引入到HTTP-GET GetMap requests,用来指引WMS到一个远程的WFS,WCS或者其他的作为特征/coverage数据预设来源的OWS服务器。目前REMOTE_OWS_TYPE参数允许的数值是“WFS” 和 “WCS”,未来可能会有更多的被允许。REMOTE_OWS_URL参数交出服务器基础的URL来用。（以前，单一的一个WFS参数被提供给这个程序，但是那样局限性很大）。例如，一个WFS的URL是http://anothersite.com/WFS?那么前面部分里的地图request将被转换成：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD=http%3A%2F%2Fmyclientsite.com%2FmySLD.xml&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG&
REMOTE_OWS_TYPE=WFS&
REMOTE_OWS_URL=http%3A%2F%2Fanothersite.com%2FWFS%3
这个例子代表了WMS和WFS/WCS之间最简单的关系。但是还有很多其他有可能出现的关系。为了使讨论便于理解，这篇文章里引入了2个概念：‘component servers’和 ‘integrated servers’
Component servers: 这些服务器松散的连接在一起并且可以在任何组合下工作。例如，一个component WMS 可以将来自任何一个它被指引去的WFS/WCS的特征/coverage数据符号化。
Integrated servers: 这些服务器紧密地联合在一起并且只能在特定的配置下工作。例如，一个integrated WMS可能只能将来自和它联系在一起的WFS/WCS的特征/coverage数据符号化。一个服务器是component还是integrated告诉我们它是怎样被执行的。例如一个WMS是一个有效的OGC WMS使得它正确地支持WMS接口。这并没有告诉我们任何消息关于WMS是怎样被执行的。但是，一个可以将特征/coverage数据符号化的 ‘component’ WMS只能通过WFS/WCS接口和数据接触,这里确实说了关于执行的事。当然一个component WMS被指向什么类型的WFS/WCS(component 或integrated)是不重要的。值得注意的是将会有其他的WMS出现，他们可以用不是来自特征数据的资源制作地图。
有一批可以支持用户自定义符号的WMS。更加详细地说明这一系列的2端是怎样的是最好的解释，一个‘component’ WMS代表着一端，‘integrated’ WMS代表着另一端。
•• Component WMS
主要地它是一个可以把从一个或多个远程WFS/WCS收集来的特征数据符号化的绘图机器。 它主要有以下这些特征：
o 没有事先定义的‘被命名的 ’layers 或styles。
o 只是支持WMS 接口。
o 可以符号化来自任何WFS/WCS的特征数据。
o 支持用户自定义的layers 和styles。
基于XSLT技术的WMS是属于这个类型的。
• Integrated WMS
这个服务器代表了一个紧密联系的特征仓库和一个绘图机器。它主要有以下这些特征：
o 有事先定义的‘被命名的’layers和styles。
o 支持WMS接口，WFS接口的DescribeFeatureType request，WCS接口的GetCapabilities或者 可供选择的 DescribeCoverageLayer requests。
o 只能符号化来自它自身内部的特征仓库的数据。
o 只能支持用户自定义的styles用于事先定义的‘被命名的’layers。
不管是用component 还是integrated WMS，它必须可以讯问潜在的特征仓库（虽然只是在相对表面的水平）。这是因为用户自定义的符号化用到的概念在以前是不被WMS所需要的。例如，WMS1.1使得可以使用[Named]Layer和[Named]Style 这样的概念来接触WMS，而用不到特征类型这样的概念。相反地用户自定义符号化需要能够利用特征类型和特征类型属性来定义新的layers和styles。例如，一个新的layer可能会被定义成某一个特征类型的全部特征。这份规则就是要试着确保建立支持用户自定义符号化WMS的障碍越低越好。
通过WFS/WCS接口，潜在的特征/coverage仓库被询问了。对于一个component WMS来说这不是什么问题，因为特征/coverage仓库本身就是一个远程的WFS/WCS。对于一个integrated WMS来说，服务器必须既支持WMS接口也支持最小范围的WFS/WCS操作。它必须支持WFS的DescribeFeatureType request 或者WCS的GetCapabilities和可供选择的DescribeCoverageLayer。这体现了一个在request里被用名字来指明的特征/coverage 类型的属性。并且如果WMS支持用户自定义layers，那么它必须支持WFS GetCapabilities request。对于一个WFS 的返回，WFS支持所有特征类型的名字。合起来这2个WFS requests允许clients 收集所有建立用户自定义符号化所需要的信息。单独地WCS GetCapabilities request 对于一个WCS已经足够了。
指出在哪里WMS可以找到要被符号化的特征数据也是很重要的.下面是所用到的规则：
1． 如果SLD在UserLayer元素的RemoteOWS元素中指明一个WFS或者WCS,那么它将被使用（见Section 7）; 否则
2． 如果GetMap request包括CGI REMOTE_OWS_TYPE和REMOTE_OWS_URL参数那么那个远程服务器将被使用；否则
3． WMS将使用一个预设的WFS或者WCS。
这种方法不允许来自不同WFS/WCS的特征/coverage被包含在相同的styled layer里;然而，它却允许不同的styled layers建立在来自不同的WFS/WCS的特征数据上。前2个规则只能被用于那些可以被引导到远程WFS/WCS的WMS。在响应一个GetCapabilities request时，WMS将显示出这种能力（见6.7）。对于一个integrated WMS来说，预设的WFC/WCS就是那个和它结合在一起的。然而，没有人知道为什么一个component WMS不能够使一个预设的WFS/WCS被定义。
6．6 DescribeLayer Request
定义一个用户自定义的style 需要被符号化的特征的信息，或者至少知道它们的特征类型。因为用户自定义的styles可以被用于一个被命名的layer， 所以我们需要一个程序，通过它client可以得到一个被命名的layer的特征/coverage 类型信息。这是另一个将WMS概念下的layers/styles和WFS/WCS概念下的特征类型/coverage layer连接起来的例子。为了做到这点，WMS会选择性地支持DescribeLayer request。它适用于多个layers。体现在下面的例子中：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=DescribeLayer&
LAYERS=Rivers,Roads,Houses
例子中的DescribeLayer 是REQUEST 参数的一个新的选项。LAYERS 是一个参数，它允许被命名的layers被用名字来指出。它被认为是一个比使WMS Capabilities 文件更加超负荷的更好的方法。
它的返回将是一个描述被指出的命名的layers的XML文件。如果任何一个被命名的layer都没有出现，那么返回将是一个报告例外的XML文件。
对于每个被命名的layer,描述里应该指出它是否确实建立在特征数据上，如果是，它将显示WFS/WCS（通过一个URL前缀）和特征类型。值得注意的是它对那些不能以这种方式被描述的命名layer是完全有效地。我们可以再利用WFS程序来显示怎样在一个WFS里指出特征类型，那就是使用Query 元素。附件B给出了返回的DTD。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE WMS_DescribeLayerResponse
SYSTEM "http://some.site.com/sld/DSR.dtd" >
<WMS_DescribeLayerResponse version="1.1.0" >
<!-- 'Layer_A' comes from the wfs specified by
the prefix "http://www.mywfs.com/WFS?" and has features
of types 'Road_FT' and 'Route_FT' -->
<LayerDescription name="Layer_A"
wfs="http://www.mywfs.com/WFS?">
<Query typeName="Road_FT" />
<Query typeName="Route_FT" />
</LayerDescription>
<!-- 'Layer_B' cannot be described in terms of
a WFS and so has no wfs attribute and no contents -->
<LayerDescription name="Layer_B">
</LayerDescription>
</WMS_DescribeLayerResponse>
即使是一个integrated WMS也要给出一个WFS/WCS前缀，因为这样可以允许DescribeFeatureType requests 的运行。但是常见的是，也许一个WMS不支持UserLayers 却允许UserStyles 被用于命名的layers。在这种情况下，支持DescribeLayer request 是唯一的可相互操作的方法使得一个client能够指定用户自定义的符号化。
6．7 对于WMS GetCapabilities的加强
被WMS支持的GetCapabilities request 必须返回足够的信息，使client可以继续建立有效的requests。例如，一个WMS的capabilities包括哪个被命名的layers是WMS知道的。GetMap request 不是有效的如果它指向一个WMS不知道的被命名的layer。为了保证和不同的WMS有效地联系，包括上面所说的integrated/component WMS，capabilities 返回已经被加强了。具体地说，它可以描述下面这些信息：
1 WMS提供SLD支持么？
2 Client可以用HTTP POST(有一个嵌入的SLD)和/或HTTP GET(有一个SLD或SLD_BODY参数)去发表一个request么？
3 WMS支持用户自定义的layers么？
4 WMS支持用户自定义的styles么？
5 WMS可以被‘引导’到远程的OWS服务器么？（WMS支持在HTTP-GET requests里的REMOTE_OWS_SERVICE 和 REMOTE_OWS_URL参数么？支持在SLD里的RemoteOWS 么？）
6 WMS支持DescribeLayer request么？
一个WMS可能不支持被命名的layers/styles，体现在当描述它的capabilities时不会返回任何Layer元素。这个方法使得它能支持用户自定义的styles而不用支持用户自定义的layers。这种情况对于那些只描述远程特征的component WMS最为普遍。然而，这个对于WMS capabilities的描述没有明确地提到‘integrated’和 ‘component’类型。
前四条都代表了驾驭用户自定义符号化的能力的不同方面。1.1.0 WMS-Capabilities DTD引入了包含在Capability元素里面的UserDefinedSymbolization元素。这个新的元素包含了WMS支持用户自定义符号化能力的信息：
<!-- Elements indicating the level of support the WMS provides
for user-defined symbolization. By default there is no support.
-->
<!ELEMENT UserDefinedSymbolization (SupportedSLDVersion*)>
<!ATTLIST UserDefinedSymbolization
<!-- If the WMS supports a
StyledLayerDescriptor (SLD) then the
SLD parameter can be used in place of LAYERS and STYLES
parameters in a GetMap request. -->
SupportSLD (0 | 1) "0"
<!-- If the WMS supports UserLayers then users can define their
own layers in the SLD in addition to NamedLayers already known to
the WMS. -->
UserLayer (0 | 1) "0"
<!-- If the WMS supports UserStyles then users can define their
own styles in the SLD to be applied to previously specified
layers. -->
UserStyle (0 | 1) "0"
<!-- If the WMS supports remote WFS or WCS then a remote service
can be specified as the source of features to be symbolized. -->
RemoteWFS (0 | 1) "0"
RemoteWCS (0 | 1) "0">
<!-- Indication of what SLD version(s) are supported by a WMS -->
<!ELEMENT SupportedSLDVersion (#PCDATA)>
最后2条需要是可以被capabilities描绘地，用WMS capabilities的元素来处理，另外加上一个由DescribeLayer元素表现的新request 类型。这个Request元素可以被用来描述是否一个request可以被HTTP操作（作为一个DCP特定的instance）,如果是，这个request是否可以使用HTTP GET 和/或POST。
<!-- DescribeLayer interface: Presence of theDescribeLayer
element means this server can return a description of a specified
layer -->
<!ELEMENT DescribeLayer (Format+, DCPType+)>
现在被DescribeLayer request支持的唯一的格式是XML译码（在附件B里有解释）。对于WMS1.0.0到1.0.7，这种格式被叫做“WMS_XML”。对于WMS1.0.8以上，它是MIME 格式“application/vnd.ogc.wms_xml”.
Layers
7.1 SLD Root Element
一个SLD文件被定义为一个styled layers的序列。Root StyledLayerDescriptor被下面的XML-方案片断所定义：
<xs:element name="StyledLayerDescriptor">
<xs:complexType>
<xs:choice minOccurs="0"
maxOccurs="unbounded">
<xs:element ref="sld:NamedLayer"/>
<xs:element ref="sld:UserLayer"/>
</xs:choice>
<xs:attribute name="version" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
分享到：
评论
1 楼
gzasor
2009-09-18
不知道楼主有没有关于geoserver解析SLD样式的资料呢!
有的话可否麻烦发一份到我的邮箱好吗?这方面的资料实在是少
gzasor@foxmail.com
有的话可否麻烦发一份到我的邮箱好吗?这方面的资料实在是少
gzasor@foxmail.com
发表评论
相关推荐
这份手册的版本更新至2019年9月30日，英文版本为主，中文翻译版仅供参考。由于可能存在翻译未及时更新至最新版本的问题，建议读者在出现差异时以英文版为准，如需最新信息可参考英文版本。手册的在线版本ID为683819...
汉化版的GeoServer 2.1.3意味着所有的菜单、选项、帮助文档都已经翻译成中文，这对于中国的GIS开发者和使用者来说是一个巨大的福音。用户无需因为语言问题而困扰，能够更专注于地理信息系统的开发和应用。在安装和...
"fgis"可能指的是"Geographic Information System"的缩写，中文翻译为“地理信息系统”。在IT行业中，尤其是GIS领域，这是一个重要的概念。它是一种集成了计算机硬件、软件和地理数据的系统，用于获取、存储、管理、...
内容概要：本文详细介绍了如何利用MATLAB进行价格型需求响应的研究，特别是电价弹性矩阵的构建与优化。文章首先解释了电价弹性矩阵的概念及其重要性，接着展示了如何通过MATLAB代码实现弹性矩阵的初始化、负荷变化量的计算以及优化方法。文中还讨论了如何通过非线性约束和目标函数最小化峰谷差，确保用户用电舒适度的同时实现负荷的有效调节。此外，文章提供了具体的代码实例，包括原始负荷曲线与优化后负荷曲线的对比图，以及基于历史数据的参数优化方法。 适合人群：从事电力系统优化、能源管理及相关领域的研究人员和技术人员。 使用场景及目标：适用于希望深入了解并掌握价格型需求响应机制的专业人士，旨在帮助他们更好地理解和应用电价弹性矩阵，优化电力系统的负荷分布，提高能源利用效率。 其他说明：文章强调了实际应用中的注意事项，如弹性矩阵的动态校准和用户价格敏感度的滞后效应，提供了实用的技术细节和实践经验。
一级医院医疗信息管理系统安装调试技术服务合同20240801.pdf
表5 文献综述.doc
36W低压输入正激电源 变压器电感设计
基于YOLOv8的深度学习课堂行为检测系统源码，软件开发环境python3.9，系统界面开发pyqt5。在使用前安装python3.9，并安装软件所需的依赖库，直接运行MainProgram.py文件即可打开程序。模型训练时，将train,val数据集的绝对路径改为自己项目数据集的绝对路径，运行train.py文件即可开始进行模型训练，内含项目文件说明，以及检测图片和视频。
odbc_oracle zabbix模版原版
内容概要：本文探讨了利用纳什谈判理论来优化风光氢多主体能源系统的合作运行方法。通过MATLAB代码实现了一个复杂的优化模型，解决了风电、光伏和氢能之间的合作问题。文中详细介绍了ADMM（交替方向乘子法）框架的应用，包括联盟效益最大化和收益分配谈判两个子任务。此外，还涉及了加权残差计算、目标函数构造、可视化工具以及多种博弈模式的对比等功能模块。实验结果显示，合作模式下系统总成本显著降低，氢能利用率大幅提升。 适合人群：从事能源系统研究的专业人士、对博弈论及其应用感兴趣的学者和技术人员。 使用场景及目标：适用于需要优化多主体能源系统合作运行的场合，如工业园区、电网公司等。主要目标是提高能源利用效率，降低成本，增强系统的灵活性和稳定性。 其他说明：代码中包含了丰富的可视化工具，能够帮助研究人员更好地理解和展示谈判过程及结果。同时，提供了多种博弈模式的对比功能，便于进行性能评估和方案选择。
内容概要：本文详细介绍了如何利用C#与Halcon联合编程构建高效的视觉几何定位与测量框架。主要内容涵盖模板创建与匹配、圆测量、数据持久化以及图像采集等方面的技术细节。首先，通过创建形状模板并进行匹配，实现了工件的精确定位。接着，针对圆形物体的测量，提出了动态ROI绘制、亚像素边缘提取和稳健圆拟合的方法。此外，还讨论了模板管理和图像采集的最佳实践，确保系统的稳定性和高效性。最后，强调了Halcon对象的内存管理和错误处理机制，提供了实用的优化建议。 适合人群：具备一定编程基础，尤其是对C#和Halcon有一定了解的研发人员和技术爱好者。 使用场景及目标：适用于工业生产线上的自动化检测设备开发，旨在提高工件定位和尺寸测量的精度与效率。主要目标是帮助开发者掌握C#与Halcon联合编程的具体实现方法，从而构建稳定可靠的视觉检测系统。 其他说明：文中提供了大量实战代码片段和调试技巧，有助于读者快速理解和应用相关技术。同时，作者分享了许多实际项目中的经验和教训，使读者能够避开常见陷阱，提升开发效率。
QT视频播放器实现（基于QGraphicsView）
评估管线钢环焊缝质量及其对氢脆的敏感性.pptx
该是一个在 Kaggle 上发布的数据集，专注于 2024 年出现的漏洞（CVE）信息。以下是关于该数据集的详细介绍：该数据集收集了 2024 年记录在案的各类漏洞信息，涵盖了漏洞的利用方式（Exploits）、通用漏洞评分系统（CVSS）评分以及受影响的操作系统（OS）。通过整合这些信息，研究人员和安全专家可以全面了解每个漏洞的潜在威胁、影响范围以及可能的攻击途径。数据主要来源于权威的漏洞信息平台，如美国国家漏洞数据库（NVD）等。这些数据经过整理和筛选后被纳入数据集，确保了信息的准确性和可靠性。数据集特点：全面性：涵盖了多种操作系统（如 Windows、Linux、Android 等）的漏洞信息，反映了不同平台的安全状况。实用性：CVSS 评分提供了漏洞严重程度的量化指标，帮助用户快速评估漏洞的优先级。同时，漏洞利用信息（Exploits）为安全研究人员提供了攻击者可能的攻击手段，有助于提前制定防御策略。时效性：专注于 2024 年的漏洞数据，反映了当前网络安全领域面临的新挑战和新趋势。该数据集可用于多种研究和实践场景： 安全研究：研究人员可以利用该数据集分析漏洞的分布规律、攻击趋势以及不同操作系统之间的安全差异，为网络安全防护提供理论支持。 机器学习与数据分析：数据集中的结构化信息适合用于机器学习模型的训练，例如预测漏洞的 CVSS 评分、识别潜在的高危漏洞等。 企业安全评估：企业安全团队可以参考该数据集中的漏洞信息，结合自身系统的实际情况，进行安全评估和漏洞修复计划的制定。
博客主页：https://blog.csdn.net/luoyayun361 QML ComboBox控件，输入关键字后自动过滤包含关键字的列表，方便快速查找列表项
内容概要：本文全面介绍了人工智能技术的发展历程、核心技术原理、应用方法及其未来趋势。首先阐述了人工智能的定义和核心目标，随后按时间顺序回顾了其从萌芽到爆发的五个发展阶段。接着详细讲解了机器学习、深度学习、自然语言处理和计算机视觉等核心技术原理，并介绍了使用现成AI服务和开发自定义AI模型的应用方法。此外，还展示了智能客服系统、图像分类应用和智能推荐系统的具体实现案例。针对普通用户，提供了使用大模型的指南和提问技巧，强调了隐私保护、信息验证等注意事项。最后展望了多模态AI、可解释AI等未来发展方向，并推荐了相关学习资源。; 适合人群：对人工智能感兴趣的初学者、技术人员以及希望了解AI技术应用的普通大众。; 使用场景及目标：①帮助初学者快速了解AI的基本概念和发展脉络；②为技术人员提供核心技术原理和应用方法的参考；③指导普通用户如何有效地使用大模型进行日常查询和任务处理。; 其他说明：本文不仅涵盖了AI技术的基础知识，还提供了丰富的实际应用案例和实用技巧，旨在帮助读者全面理解人工智能技术，并能在实际工作中加以应用。同时提醒读者关注AI伦理和版权问题，确保安全合法地使用AI工具。
本学习由 Matrix 工作室制作并开发，包括算法与数据结构的学习路线和各种题解。
本项目致力于构建基于微服务架构的智慧图书馆管理平台，重点突破多校区图书馆异构系统间的数据壁垒。通过建立统一数据治理规范、部署智能分析模块、重构业务流程引擎，系统性实现以下建设目标：构建跨馆业务数据的标准化整合通道，实施容器化部署的弹性资源管理体系，开发具备机器学习能力的业务辅助决策系统，打造可量化评估的管理效能提升模型，最终形成支持PB级数据处理的分布式存储体系与全维度数据资产图谱。
根据processlist查询出慢sql 1.修改配置文件中的mysql链接 2.目前是15秒执行一次获取执行时间在5秒上的sql，可以在配置中修改 3.执行后查出的慢sql会记录到log文件夹中以日期命名的txt文件中，可自行查验
全域通航 低空经济服务平台建设实施方案.pptx