deegree Web Map Service v2.3

Change log

1. Introduction

deegree is a Java Framework offering the main building blocks for Spatial Data Infrastructures (SDIs). Its entire architecture is developed using standards of the Open Geospatial Consortium (OGC) and ISO Technical Committee 211 – Geographic information / Geoinformatics (ISO/TC 211). deegree encompasses OGC Web Services as well as clients. deegree is Free Software protected by the GNU Lesser General Public License (GNU LGPL) and is accessible at http://www.deegree.org.

deegree2 is the new release of deegree supporting a number of features deegree1 was not able to handle. This documentation describes setup and configuration of deegree Web Map Service (WMS), an implementation of OGC's Web Map Service Implementation Specification 1.1.1. deegree WMS is the official Reference Implementation of the OGC for the mentioned standard.

deegree's WMS is able to render vector data as well as raster data from different storage formats and deliver it to any client that is able to perform a HTTP GET or POST request. The currently supported storage formats are:

• PostgreSQL / PostGIS

• Oracle (Spatial / Locator)

• databases allowing JDBC-connections

• ESRI Shapefiles

• (all provided by the deegree WFS)

• GML2 and GML3 provided by a OGC WFS

• JPEG, GIF, PNG, BMP, TIFF and GeoTIFF images (provided by the deegree WCS)

• Images provided by any OGC compliant WCS

• Cascaded OGC WMS 1.0.0/1.1.0/1.1.1

Besides a WMS, deegree comprises a number of additional services and clients. A complete list of deegree components can be found at:

http://www.lat-lon.de  Products

Downloads of packaged deegree components can be found at:

http://www.deegree.org  Download

deegree's Web Map Service offers great flexibility regarding its configuration and adaption to different data sources, formats and server environments. The configuration of WMS is similar to the configuration of other deegree web services and requires editing of different XML files which control the functionality of the server.

The web services of deegree are realized as Java modules controlled by one central servlet (a “dispatcher”). This servlet has to be integrated into the respective web server/servlet engine. Most of the common web servers support servlet technology, thus making deegree a universal product. The Apache-Tomcat 5.5 Servlet-Engine is recommended due to its widespread use and its status as an open-source product.

2. Download / Installation

   1. Prerequisites

For deegree2 Web Map Service to run you need:

• Java (JRE or JSDK) version 1.5.x

• Tomcat 5.5.x

For installation of these components refer to the corresponding documentation at java.sun.com and tomcat.apache.org.

2. deegree Web Map Service release

deegree Web Map Service can be downloaded from http://www.deegree.org. The release is packed as a WAR-archive. Simply put this file into your $TOMCAT_HOME$/webapps directory and (re-)start Tomcat. The installation of deegree WMS is already done with this.

Note: It is also possible to extract the WAR archive into another place of your computer and direct Tomcat to this place. Because of this possibility, in the remainder of this document, the directory you extracted the files to is referred to as $wms_home$ (=$TOMCAT_HOME$/webapps/deegree-wms in the standard case).

Your $wms_home$ will contain the following structure:

Table 1: Directory structure of the WMS release

3. Testing the installation

deegree WMS comes with three sample data sets:

• The ‘blue lake’ dataset that is used by OGC for testing WMS compliance

• the 'UTAH' dataset comprising spatial data of the state Utah (sources: Shape, Hsqldb, WCS)

• The 'OpenStreetMap' dataset including spatial data from the free wiki world map www.openstreetmap.org (sources: postgreSQL database, external data access class)

All of this data is automatically extracted and installed when unpacking the deegree WMS demo.

If installation succeeded, deegree WMS should be running by now with the sample data sets. Try the following request in your web browser:

http://127.0.0.1:8080/deegree-wms/services?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities

This should provide a valid XML Capabilities file (if your browser asks for an application to open the file, try your browser again or any text editor). If this worked fine try a map request:

blue lake

http://127.0.0.1:8080/deegree-wms/services?REQUEST=GetMap&SERVICE=WMS&VERSION=1.1.1&WIDTH=467&HEIGHT=321&LAYERS=Buildings,DividedRoutes,Forests,Lakes,MapNeatline&TRANSPARENT=TRUE&FORMAT=image/png&BBOX=-0.004398,-0.003327182608695652,0.004531852173913042,0.0028108956521739124&SRS=EPSG:4326&STYLES

This request should deliver the following picture:

UTAH

http://127.0.0.1:8080/deegree-wms/services?REQUEST=GetMap&SERVICE=WMS&VERSION=1.1.1&WIDTH=467&HEIGHT=321&LAYERS=Counties&TRANSPARENT=TRUE&FORMAT=image/png&BBOX=-27471.97559929872,4039616.6884999997,928973.8818492987,4697045.211499999&SRS=EPSG:26912&STYLES

If all of this worked fine, your deegree WMS is running and you can now add your own data. But let’s first have a brief look at the architecture of deegree WMS.

3. Architecture

deegree2 WMS does not implement direct data access. All data that is used to create a map will be accessed via a WFS, WCS or another WMS. WFS and WCS can be realized locally – i.e. in the same Virtual Machine (VM) as the deegree WMS – or remotely as a web service (Figure 3). Different WMS layers can be delivered by different WFS, WCS, or WMS servers.

For configuration purposes this means that if setting up a deegree WMS you also have to configure at least a LOCALWFS or LOCALWCS. Therefore it is recommended to consult these documentations as well if interested in advanced configuration options.

Since deegree WMS version 2.3, there is the possibility to use direct data access.

4. Basic configuration

   1. Structure of the configuration files

The following figure shows the relationships between the different configuration files that have to be adapted:

Figure 4: Files affecting the deegree WMS configuration

Besides the files shown in the diagram above, two additional files are part of the WMS configuration, the LOCALWFS_configuration.xml and the LOCALWCS_configuration.xml. (The default names are LOCALW*S_capabilities.xml) These two files are responsible for configuring the local WFS and WCS; please have a look at the deegree WFS- and WCS-documentation for details on how to do that.

2. The deegree WMS configuration document

The basic configuration allows use of the full set of parameters that can be used for controlling the deegree WMS using the deegree WMS configuration document. This includes the parameters mentioned in the OGC WMS 1.1.1 specification for the Capabilities document, but also additional specific technical parameters as for example descriptions of data sources for each layer or the maximum cache size. You can find the wms_configuration.xml file under $wms-home$/WEB-INF/conf/wms.

In the following, the elements of the configuration file will be described in detail. Appendix A includes the complete configuration document.

<?xml version="1.0" encoding="UTF-8"?>

<WMT_MS_Capabilities

xmlns:deegree="http://www.deegree.org/wms"

xmlns:sld="http://www.opengis.net/sld"

xmlns:gml="http://www.opengis.net/gml"

xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1.1"
updateSequence="1.1.0">

In this code fragment, the namespace bindings are defined. It is usually preferable to just copy this fragment and use the prefixes defined here elsewhere in the document.

1. The DeegreeParam Element

After the root element, some deegree-WMS-specific parameters are defined. The <DefaultOnlineResource> is the URL by which the WMS operations can be invoked. This parameter can be overwritten by the URLs defined in the request-definitions. You have to adjust the <DefaultOnlineResource> to your system.

<deegree:DeegreeParam>

<!-- The default online resource will be used for the following: If no LegendURL is provided, a GetLegendGraphic request with this URL will be deprecated automatically. If no OnlineResource element is specified within the Service element, this one will be inserted automatically. The operation specific online resources will NOT be filled automatically, since they also specify the HTTP methhod to be used. -->

<deegree:DefaultOnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://localhost:8080/deegree-wms/services"/>

<!-- default = 100 (MB) -->

<deegree:CacheSize>100</deegree:CacheSize>

<!-- maximum lifetime of the processes in the WMS; default = 3600 (sec)-->

<deegree:MaxLifeTime>3600</deegree:MaxLifeTime>

<!-- maximum time for the execution of a request until an exception of time-exceed is thrown default 15 seconds -->

<deegree:RequestTimeLimit>45</deegree:RequestTimeLimit>

<!-- determines the quality of the map/image generated from a GetMap request.

the parameter will only be evaluated if the desired format is able to handle it. The range of values is 0 ... 1, where 1 is best and 0 is worst. default is 0.95 -->

<deegree:MapQuality>0.95</deegree:MapQuality>

<!-- maximum map width that can be requested. default = 1000 -->

<deegree:MaxMapWidth>1000</deegree:MaxMapWidth>

<!-- maximum map height that can be requested. default = 1000 -->

<deegree:MaxMapHeight>1000</deegree:MaxMapHeight>

<deegree:AntiAliased>true</deegree:AntiAliased>

<!-- copyright note that will be drawn to the left bottom side of the maps ; you can also reference a graphic file using absolute path to file e.g. c:/images/mylogo.jpg -->

<deegree:Copyright>deegree-WMS V.2.2 2008</deegree:Copyright>

<!-- radius of the circle around the point a user has clicked to that will

be considered for creating a search area for a GetFeatureInfo request;

default = 5 -->

<deegree:FeatureInfoRadius>10</deegree:FeatureInfoRadius>

<!-- returns the URl where the DTD for OGC WMS capabilities DOCTYPE definition is located. default = http://schemas.opengis.net/wms/1.1.1/WMS_MS_Capabilities.dtd You can also reference this document locally if you run this service without internet connection -->

<deegree:DTDLocation>

<deegree:OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://schemas.opengis.net/wms/1.1.1/WMS_MS_Capabilities.dtd"/>

</deegree:DTDLocation>

<!-- define a proxy server if the WMS is separated by a firewall from the DTD-location or the locations of connected REMOTEWFS, REMOTEWCS and REMOTEWMS as an alternative you can set command line parameters at the call of the java interpreter like this: java -DproxyHost=131.220.106.104 -DproxyPort=1234 -classpath ... -->

<!--Proxy proxyHost="131.220.106.104" proxyPort="1234"/-->

</deegree:DeegreeParam>

The <CacheSize> parameter defines the size of the cache available to deegree-WMS in megabyte (this does not affect the cache for data sources). This parameter is optional, its default value is 100 MB. With the <MaxLifeTime> the user defines the time interval after which the internal processes of the WMS will be stopped if there are no active requests. If this parameter is not supplied, its default is 3600 seconds. By <RequestTimeLimit> the maximum time span is defined after which a request has to be processed. If this value is exceeded the processing is canceled and an exception will be thrown. Its default value is 15 seconds.

Afterwards a <MapQuality> parameter is defined, by which the quality of the created maps can be controlled. Values for this parameter are between 0 (lowest quality) and 1 (best quality) with the default value being 0.95. This parameter is only used for image formats supporting different quality values (e.g. jpeg).

The following two parameters limit the maximum size of a map that can be requested via WMS. It has to be considered that requesting large maps is very taxing on a server as the processing cost increases with the square of the border length of a map. For example, the creation a map having 1000x1000 pixel takes four times the memory than creating a map with size 500x500 pixel. Default is 1000 pixel for width and height.

The AntiAliased parameter defines whether deegree should use an anti aliasing filter while rendering the map. This usually improves the output for vector data. It is advisable to try both “true” and “false” with your data and see which looks better.

With the <Copyright> parameter it is possible to write a copyright mark in the lower left corner of each map. A copyright note can be either a text fragment or a reference to an image (e.g. c:/images/copyright.gif). In case this parameter is not supplied no output is produced.

The FeatureInfoRadius parameter defines a tolerance for the GetFeatureInfo request. If the user tries to click on a point and just misses it, he normally does not get back any data. Increasing this parameter to a value greater than 1 improves this behavior by expanding the search area around a point by the specified radius.

The DTDLocation parameter can be used to override the DTDLocation that is sent back in response to a GetCapabilities request. Since deegree nowadays does not try to load the DTD any more when encountering such a document, you'll usually drop this optional parameter, but if you wish to control the URL that is used in the DOCTYPE header of the Capabilities-document, here is where you set it.

If the WMS runs behind a firewall/proxy it is necessary to publish the proxy server address and port to the WMS (Java runtime environment) if data from remote data sources outside the firewall are included in the WMS. Because in this case the WMS has to access servers from outside the firewall the network connection have to be passed through the proxy. Alternatively the proxy parameters can be passed to the Java runtime environment by command line parameters when starting the servlet engine (see java documentation).

2. Service Parameters

The following definition of service meta data is adopted from the WMS 1.1.1 specification.

<Service>

<Name>WMS</Name>

<Title>deegree2.2 demowms</Title>

<!-- abstract and keywords are optional -->

<Abstract>WMS reference implementation</Abstract>

<KeywordList>

<Keyword>deegree</Keyword>

<Keyword>wms</Keyword>

</KeywordList>

<!-- The default online resource above will fill this one in for us, as well as in capabilities section. -->

<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple"

xlink:href="http://localhost:8080/deegree-wms/services?" />

<!-- the following service information is optional -->

<ContactInformation>

<ContactPersonPrimary>

<ContactPerson>Andreas Poth</ContactPerson>

<ContactOrganization>lat/lon</ContactOrganization>

</ContactPersonPrimary>

<ContactPosition>Technical Director</ContactPosition>

<ContactAddress>

<AddressType>Postal</AddressType>

<Address>Aennchenstr. 19</Address>

<City>Bonn</City>

<StateOrProvince>NRW</StateOrProvince>

<PostCode>53177</PostCode>

<Country>Germany</Country>

</ContactAddress>

<ContactVoiceTelephone>0049228184960</ContactVoiceTelephone>

<ContactFacsimileTelephone>00492281849629</ContactFacsimileTelephone>

<ContactElectronicMailAddress>info@lat-lon.de

</ContactElectronicMailAddress>

</ContactInformation>

<Fees>none</Fees>

<AccessConstraints>none</AccessConstraints>

</Service>

3. Capability/Request-Parameter

The request-definition (GetCapabilities, GetMap and GetFeatureInfo) is in its form very similar to the definitions in OGC WMS 1.1.1 specification. However, some of the mandatory elements are declared optional. In case they are not supplied, deegree uses the corresponding default values. It is for example possible to not reference any of the requests explicitly. By default, GetCapabilities, GetMap and GetFeatureInfo will be initialized.

The following example is used to explain this by means of a GetMap request.

<GetMap>

<!-- default = image/gif; image/png; image/jpg -->

<!-- mandatory = image/png -->

<Format>image/gif</Format>

<Format>image/png</Format>

<Format>image/png; mode 8bit</Format>

<Format>image/png; mode 24bit</Format>

<Format>image/jpeg</Format>

<Format>image/jpg</Format>

<!--Format>image/tif</Format-->

<!--Format>image/tiff</Format-->

<!--Format>image/bmp</Format-->

<DCPType>

<HTTP>

<Get>

<!--

<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple">

<xlink:href="http://localhost:8080/deegree-wms/services?" />

-->

</Get>

<Post>

<!--

<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"xlink:type="simple"

xlink:href="http://localhost:8080/deegree-wms/services?" />

-->

</Post>

</HTTP>

</DCPType>

</GetMap>

You have to adjust the "xlink:href" attribute of the <OnlineResource> element to your system or leave the element commented out.

In case no <GetMap> element is defined, a GetMap with the formats image/gif, image/png and image/jpg will be initialized using the <DefaultOnlineResource> as web address for http-POST and GET. If a <GetMap> element is defined supplying information regarding Online-Resources but not the format, the above mentioned formats will be supported and initialized.

If only http-GET is defined, only this protocol is supported. Otherwise, if only http-POST is defined, http-GET is complemented as it is mandatory. The behaviour of the server regarding the image formats is likewise, all mandatory image formats will be initialized even if not defined by the user. An exception to this behaviour is the format image/png that is initialized anyway, as the OGC WMS 1.1.1 specification suggests the support of one format able to define an alpha-channel.

The behavior of the initialization for GetCapabilities is similar to GetMap. Configuration of the operations DescribeLayer, GetLegendGraphic, GetStyles and PutStyles is also optional, but they will not be filled in by default (if missing, the WMS will not support these operations).

The format definition of GetFeatureInfo-Requests is distinctly different to the other format definitions. Its default format is application/vnd.ogc.gml. However, further user-defined formats are possible. You can use XSLT scripts to support other formats. The XSLT scripts should take the standard GML3-Format as input and produce the desired format as output. You can specify the XSLT script by annotating the <Format> element with a “filter” attribute as in the following (commented) example:

<GetFeatureInfo>

<!-- default & mandatory = application/vnd.ogc.gml -->

<Format>application/vnd.ogc.gml</Format>

<Format>text/plain</Format>

<Format>text/html</Format>

<!-- <Format filter="file:///c:/deegreewms/wms/toXML.xsl">application/vnd.ogc.wms_xml</Format> -->

<DCPType>

<HTTP>

<Get>

<!-- <OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://localhost:8080/deegree-wms/services?" /> -->

</Get>

</HTTP>

</DCPType>

</GetFeatureInfo>

In this example the XSLT-script file:///c:/deegreewms/wms/toXML.xsl is used as filter for the output format 'application/vnd.ogc.wms_xml', but there is no filter definition for 'text/html'. In this special case deegree is using a default filter defined by $wms-home$/WEB-INF/conf/wms/featureinfo2html.xsl.

The <OnlineResource> element can be dropped, and will be filled in with the value of the “DefaultOnlineResource” as described above.

4. Exceptions / UserDefinedSymbolization

You can also define which exception formats are to be used in case a service exception occurs. The three possible values are shown below:

<Exception>

<!-- default & mandatory= application/vnd.ogc.se_xml -->

<Format>application/vnd.ogc.se_xml</Format>

<Format>application/vnd.ogc.se_inimage</Format>

<Format>application/vnd.ogc.se_blank</Format>

</Exception>

If this information is not supplied, the XML format will be used as default.

The next element defines whether the WMS is capable of supporting SLDs.

<UserDefinedSymbolization SupportSLD="1" UserLayer="1" UserStyle="1" RemoteWFS="1"/>

A value of '1' means “true”, a value of '0' false.

This element as well as its attributes are optional. Its lacking indicates that the WMS will not support SLD.

SLD allows three alternatives to access remote servers (using GetMap Parameters, <remoteOWS> element or some default WFS); deegree WMS only supports the second option: a <remoteOWS-element that is part of a <UserLayer>.

5. Layer

In the following, the layers known to the WMS are defined. Some elements here are not defined by the WMS 1.1.1 specification, especially those creating the association between layer and its data source.

It is possible, that a WMS supplies no layer definitions, indicating it serves no data of its own (a ‘component’ WMS as defined in the SLD specification). Such a server is nonetheless capable of serving maps by obtaining data directly or indirectly from the SLD documents sent to it.

The additional elements of the deegree-WMS configuration define the association of a layer with a data source (i.e. from a WFS or WCS). If a <Layer> has a <Name> but does not define a data source, using this layer with a GetMap or a GetFeatureInfo request causes that all <Layer>s nested within this layer will be affected by a request. For GetLegendGraphic requests only the top level layer will be used since GetLegendGraphic only allows the specification of one layer. If a REMOTEWMS (cascaded WMS) is used as datasource for a layer deegree is able to cascade GetLegendGraphic requests too if just one layer is requested from cascaded WMS within a datasource.

Simple reduced overview of example configuration:

<Layer>

<Layer>nested Cite layers

<Layer>Cite layer 1</Layer>

<Layer>Cite layer 2</Layer>

<Layer>Cite layer X</Layer>

</Layer>

<Layer>nested Utah layer

<Layer>nested Utah administration

<Layer>Utah county</Layer>

<Layer>Utah Municipalities</Layer>

</Layer>

<Layer>Cite layer2</Layer>

<Layer>Cite layerX</Layer>

</Layer>

</Layer>

Full example for one nested layer:

...

<Layer queryable="1" noSubsets="0" fixedWidth="0" fixedHeight="0">

<Name>citelayers</Name>

<Title>Cite Layers</Title>

<Abstract>deegree demo WMS</Abstract>

<KeywordList>

<Keyword>deegree</Keyword>

<Keyword>layer</Keyword>

</KeywordList>

<MetadataURL type="ISO19115:2003">

<Format>text/html</Format>

<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://www.deegree.org" />

</MetadataURL>

<!-- queryable="1" sets GetFeatureInfo to enabled. If set to "1" at least one datasource must be set to "1" too -->

<Layer queryable="1" noSubsets="0" fixedWidth="0" fixedHeight="0">

<!-- please choose a unique <name> without spaces and a title which can contain more details -->

<Name>BasicPolygons</Name>

<Title>BasicPolygons</Title>

<Abstract>deegree demo WMS</Abstract>

<KeywordList>

<Keyword>deegree</Keyword>

<Keyword>layer</Keyword>

</KeywordList>

<MetadataURL type="ISO19115:2003">

<Format>text/html</Format>

<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://www.deegree.org" />

</MetadataURL>

<MinScaleDenominator>0</MinScaleDenominator>

<MaxScaleDenominator>10000000</MaxScaleDenominator>

<!-- queryable="1" sets GetFeatureInfo to enabled for this datasource -->

<deegree:DataSource failOnException="0" queryable="1">

<deegree:Name>app:BasicPolygons</deegree:Name>

<deegree:Type>LOCALWFS</deegree:Type>

<deegree:OWSCapabilities>

<deegree:OnlineResource xlink:type="simple"
xlink:href="LOCALWFS_configuration.xml" />

</deegree:OWSCapabilities>

<!--name of the property that contains the geometries for this layer this element will only be resolved if the data source is a LOCALWFS or a REMOTEWFS -->

<deegree:GeometryProperty>app:geom</deegree:GeometryProperty>

</deegree:DataSource>

<Style>

<Name>default:BasicPolygons</Name>

<Title>default:BasicPolygons</Title>

<deegree:StyleResource>cite.xml</deegree:StyleResource>

</Style>

<!-- In case you do not wish to use the automatic legend generation you need to set the <sld:GetLegendGraphic> here. Refer to the documentation for details -->

</Layer>

<!-- The following Layer definition could be used as default for your own layers -->

<Layer queryable="1" noSubsets="0" fixedWidth="0" fixedHeight="0">

<Name>Bridges</Name>

<Title>Bridges</Title>

<Abstract>deegree demo WMS</Abstract>

<KeywordList>

<Keyword>deegree</Keyword>

<Keyword>layer</Keyword>

</KeywordList>

<MetadataURL type="ISO19115:2003">

<Format>text/html</Format>

<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://www.deegree.org" />

</MetadataURL>

<deegree:DataSource failOnException="0" queryable="1">

<deegree:Name>app:Bridges</deegree:Name>

<deegree:Type>LOCALWFS</deegree:Type>

<deegree:OWSCapabilities>

<deegree:OnlineResource xlink:type="simple"
xlink:href="LOCALWFS_configuration.xml" />

</deegree:OWSCapabilities>

<deegree:GeometryProperty>app:geom</deegree:GeometryProperty>

</deegree:DataSource>

<Style>

<Name>default:Bridges</Name>

<Title>default:Bridges</Title>

<deegree:StyleResource>cite.xml</deegree:StyleResource>

</Style>

</Layer>

</Layer>

...

The configuration given in the example above will enable to perform a GetMap or GetFeatureInfo request on layer 'citelayers'. Because 'citelayers' itself does not define its own data source but nests two layers its resulting map/info result will be the same as performing a GetMap or GetFeatureInfo request against 'BasicPolygons' and 'Bridges'.

The following configuration snipped shows how to define a cascading WMS layer, i.e., a layer which gets its data from a remote WMS layer. This is done by specifying a DataSource element as shown. Note that this layer also has two data sources. Requesting this layer will paint the two results one after another.

<Layer xmlns:app="http://www.deegree.org/app" queryable="1" cascaded="0" opaque="1" noSubsets="1">

<Name>Europe</Name>

<Title>Datenlayer 1</Title>

<Abstract>first testing layer</Abstract>

<deegree:DataSource xmlns:deegree="http://www.deegree.org/wms"

failOnException="1" queryable="1">

<!-- default = equals the layer name and must be equal to the feature type

or the layer name of the connected OWS -->

<deegree:Name>app:Europe</deegree:Name>

<!-- name of the property that contains the geometries for this layer .

this element will only be resolved if the data source is a LOCALWFS or a

REMOTEWFS, the value is case sensitive -->

<deegree:GeometryProperty>app:geom</deegree:GeometryProperty>

<!--possible values: LOCALWFS, LOCALWCS, REMOTEWFS, REMOTEWCS,

REMOTEWMS -->

<!-- default = LOCALWFS -->

<deegree:Type>LOCALWFS</deegree:Type>

<!-- default value for OnlineResource@href is %Type%_capabilities.xml in
the directory $wms-home$/WEB-INF/xml;

default can only be used if data source type is LOCALXXX otherwise

reference to the capabilities of the remote service must be set -->

<deegree:OWSCapabilities>

<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"

type="simple"

xlink:href="http://www.lat-lon.de/documents/capabilities.xml"/>

</deegree:OWSCapabilities>

<deegree:ScaleHint min="0" max="1000"/>

<!-- optional; the filter expression will be completed with the requested

bounding box -->

<deegree:FilterCondition>

<wfs:Query typeName="app:Europe" xmlns:gml="http://www.opengis.net/gml"

xmlns:ogc="http://www.opengis.net/ogc"

xmlns:wfs="http://www.opengis.net/wfs">

<wfs:PropertyName>app:Name</wfs:PropertyName>

<wfs:PropertyName>app:Area</wfs:PropertyName>

<wfs:PropertyName>app:Border</wfs:PropertyName>

<ogc:Filter>

<ogc:And>

<ogc:PropertyIsLessThan>

<ogc:PropertyName>app:Area</ogc:PropertyName>

<ogc:Literal>50000</ogc:Literal>

</ogc:PropertyIsLessThan>

<ogc:PropertyIsLike wildCard="*" singleChar="?"

escape="\">

<ogc:PropertyName>

app:Administrator/app:City</ogc:PropertyName>

<ogc:Literal>53115 Bonn</ogc:Literal>

</ogc:PropertyIsLike>

</ogc:And>

</ogc:Filter>

</wfs:Query>

</deegree:FilterCondition>

</deegree:DataSource>

<deegree:DataSource failOnException="1" queryable="0">

<!-- default = equals the layer name and must be equal to the feature type

or the layer name of the conected OWS -->

<deegree:Name>app:EuropeanRivers</deegree:Name>

<!--name of the property that contains the geometries for this layer .

this element will only be solved if the data source is a LOCALWFS or a

REMOTEWFS

default = 'app:GEOM' -->

<deegree:GeometryProperty>app:the_geom</deegree:GeometryProperty>

<!-- default is %Type%_capabilities.xml at the directory

$wms-home$/WEB-INF/xml;

default can only be used if data source type is LOCALXXX otherwise

reference to the capabilities of the remote service must be set -->

<deegree:OWSCapabilities>

<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"

type="simple"

xlink:href="http://www.lat-lon.de/documents/another_capabilities_file.xml"/>

</deegree:OWSCapabilities>

<deegree:ScaleHint min="0" max="1000"/>

</deegree:DataSource>

<deegree:DataSource failOnException="0" queryable="0">

<deegree:Name>TK500</deegree:Name>

<deegree:Type>REMOTEWMS</deegree:Type>

<deegree:OWSCapabilities>

<deegree:OnlineResource xlink:href="http://www.geoserver.nrw.de/GeoOgcWms1.3/

servlet/NRW500?SERVICE=WMS&amp;VERSION=1.1.0&amp;REQUEST=GetCapabilities"

xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"/>

</deegree:OWSCapabilities>

<deegree:FilterCondition>

<deegree:WMSRequest><![CDATA[Version=1.1.0&FORMAT=image/jpeg&

TRANSPARENT=false&EXCEPTIONS=application/vnd.ogc.se_inimage&BGCOLOR=

0xffffff&LAYERS=Raster:UEK500:UEK500&STYLES=]]></deegree:WMSRequest>

<deegree:VendorspecificParameterDefinition>

<deegree:PassedVendorspecificParameter>

<deegree:Name>sessionid</deegree:Name>

<deegree:Name>another</deegree:Name>

</deegree:PassedVendorspecificParameter>

<deegree:AddedVendorspecificParameter>

<deegree:VendorspecificParameter>

<deegree:Name>user</deegree:Name>

<deegree:Value>aUser</deegree:Value>

</deegree:VendorspecificParameter>

<deegree:VendorspecificParameter>

<deegree:Name>password</deegree:Name>

<deegree:Value>aPassword</deegree:Value>

</deegree:VendorspecificParameter>

</deegree:AddedVendorspecificParameter>

</deegree:VendorspecificParameterDefinition>

</deegree:FilterCondition>

<deegree:FeatureInfoTransformation>

<deegree:OnlineResource

xlink:href="file:///C:/deegree/wms/transformRemoteWMS.xsl"

xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"/>

</deegree:FeatureInfoTransformation>

<deegree:ValidArea>

<gml:Polygon srsName="EPSG:4326">

<gml:outerBoundaryIs>

<gml:LinearRing>

<gml:coordinates>0,0 100,0 100,100 0,100 0,0</gml:coordinates>

</gml:LinearRing>

</gml:outerBoundaryIs>

</gml:Polygon>

</deegree:ValidArea>

<deegree:TransparentColors>

<deegree:Color>#000000</deegree:Color>

<deegree:Color>#FF0000</deegree:Color>

</deegree:TransparentColors>

</deegree:DataSource>

</Layer>

6. DataSource (within Layer)

After the optional element <Abstract>, zero, one or more <deegree:DataSource> elements are defined. <deegree:DataSource> can be provided multiple times in case a scale-dependent definition or an overlay is needed that uses different feature types and/or layers. A <deegree:DataSource> may have two attributes:

• failOnException is of type boolean and defines if the processing of a GetMap request shall fail if accessing this data source fails. This is useful if a layer accesses more than one data source where at least one of these sources is not very stable (e.g. a REMOTEWMS) and one likes to avoid permanent failure of request processing. You can use '0' for “false” and '1' as “true”, as above.

• queryable is also of type boolean and defines if a data source will be used for GetFeatureInfo requests. If the layer itself is queryable at least one of its data sources must be queryable.

The <deegree:Name> element of the DataSource supplies the name of the FeatureType, Coverage or Layer of the data that is supplied by the afterwards described OWS. The <Name> must be defined.

After the FeatureType/Coverage/Layer name the properties of the data source are defined. If a WFS will be used as data source <deegree:GeometryProperty> may be defined. As a WFS or a DATABASE can use arbitrarily defined properties to store geometries, this element is only needed if the data store is a LOCALWFS, DATABASE or a REMOTEWFS. Its default value is ‘app:GEOM’.

The third subelement of <deegree:DataSource> declares the type of the data source. Seven different values are possible for this:

• LOCALWFS  deegree WFS running in the same Virtual Machine

• REMOTEWFS  any other WFS

• LOCALWCS  deegree WCS running in the same VM

• REMOTEWCS  any other WCS

• REMOTEWMS  other WMS which is used for cascading

• DATABASE  direct database access

• EXTERNALDATAACCESS  direct data access with a java class.

To be able to use the full set of opportunities the deegree WMS offers you should read the deegree WFS and WCS documentation. There will be explained how to configure access to a database and file-based raster and vector data sources. If you use a remote OWS as data source you may have to study its configuration documentation.

<deegree:Type> is also optional, its default value is LOCALWFS.

The optional element <deegree:ScaleHint> indicates the span of scales for which the respective data source is valid, it corresponds to the element defined by OGC WMS 1.1.1. If multiple data sources are defined for one layer, the spans supplied by <deegree:ScaleHint> must not overlap. If none is given, the ScaleHint of the layer itself is used (which may in turn inherit it from a parent layer).

The element <deegree:ValidArea> defines the area for which the data source is valid. Any polygon can be used for defining a valid area. This can be useful if a layer integrates more than one data source where each data source is responsible for a different area because it may be served by different vendors.

<deegree:ValidArea>

<gml:Polygon srsName="EPSG:4326">

<gml:outerBoundaryIs>

<gml:LinearRing>

<gml:coordinates>0,0 100,0 100,100 0,100 0,0</gml:coordinates>

</gml:LinearRing>

</gml:outerBoundaryIs>

</gml:Polygon>

</deegree:ValidArea>

Each datasource can have its own timeout. For this the Element <deegree:RequestTimeLimit> must be included into a <deegree:DataSource> Element. The time imit will be given in seconds; if no reques time limit is defined 30 seconds will be the default.

1. Service-based datasources

<deegree:OWSCapabilities> specifies access to the capabilities of a remote or local data source. If for example a REMOTEWFS is defined as data source, the <deegree:OWSCapabilities> - respectively the <OnlineResource> - has to point to the Capabilities-document of the WFS.

If no <deegree:OWSCapabilities> is supplied, only the values LOCALWFS and LOCALWCS are valid, since the other types depend on the information supplied in this element.

In case neither <deegree:Type> nor <deegree:OWSCapabilities> are supplied it is assumed that the data source is a LOCALWFS whose Capabilities are in a document named 'LOCALWFS_capabilities.xml' in the directory $wms-home$/WEB-INF/conf/wms/. If LOCALWCS is defined as <Type> and no <OWSCapabilities> element is supplied it is assumed that the Capabilities of the WCS are in a document named 'LOCALWCS_capabilities.xml' in the directory $wms-home$/WEB-INF/conf/wms/.

In case a WCS or a REMOTEWMS is defined as data source, it is necessary to assure that they can deliver their data as image/gif, image/png, image/tif, image/jpeg or as image/bmp, in order to ensure that deegree can actually read the image data.

<deegree:OWSCapabilities>

<OnlineResource xlink="http://www.w3.org/1999/xlink" type="simple"

xlink:href="http://www.lat-lon.de/documents/capabilities.xml"/>

</deegree:OWSCapabilities>

or

<deegree:OWSCapabilities>

<OnlineResource xlink="http://www.w3.org/1999/xlink" type="simple"

xlink:href="http://remote-wfs-server.de/servicename?SERVICE=WFS&amp;
VERSION=1.1.0&amp;REQUEST=GetCapabilities"/>

</deegree:OWSCapabilities>

In case you use a local WFS but do not use the default capabilities (LOCALWFS_capabilities.xml) a file URL will be used to reference the capabilities document of the WFS.

<deegree:OWSCapabilities>

<OnlineResource xlink="http://www.w3.org/1999/xlink" type="simple"

xlink:href="file:///c:/documents/capabilities.xml"/>

</deegree:OWSCapabilities>

or, if the file is in the same folder as the wms_configuration.xml:

<deegree:OWSCapabilities>

<deegree:OnlineResource xlink:type="simple"
xlink:href="LOCALWFS_configuration.xml" />

</deegree:OWSCapabilities>

As next sub-element of <deegree:DataSource> a <deegree:FilterCondition> can be defined, that constrains the data delivered by a data source. For example a layer might be associated only with those features of the feature type ‘app:Europe’ (Type = REMOTEWFS or LOCALWFS), whose areas are smaller than 50000 m² and whose data administrator is working in Bonn. Please refer wms_configuration.xml to find a different example.

<!-- optional; the filter expression will be enhanced by the bounding box of the current request -->

<deegree:FilterCondition>

<wfs:Query typeName="app:Europe" xmlns:gml="http://www.opengis.net/gml"

xmlns:ogc="http://www.opengis.net/ogc"

xmlns:wfs="http://www.opengis.net/wfs">

<wfs:PropertyName>app:Name</wfs:PropertyName>

<wfs:PropertyName>app:Area</wfs:PropertyName>

<wfs:PropertyName>app:Border</wfs:PropertyName>

<ogc:Filter>

<ogc:And>

<ogc:PropertyIsLessThan>

<ogc:PropertyName>app:Area</ogc:PropertyName>

<ogc:Literal>50000</ogc:Literal>

</ogc:PropertyIsLessThan>

<ogc:PropertyIsLike wildCard="*" singleChar="?"

escape="\">

<ogc:PropertyName>

app:Administrator/app:City</ogc:PropertyName>

<ogc:Literal>53115 Bonn</ogc:Literal>

</ogc:PropertyIsLike>

</ogc:And>

</ogc:Filter>

</wfs:Query>

</deegree:FilterCondition>

The filter expression must be applicable to the defined type of the data source, meaning that for example the filter defined above can only be used in conjunction with a WFS, that stores features belonging to the feature type app:Europe. The typeName of the query in this case overwrites the value of the element <deegree:Name> defined above in the DataSource tag.

The following example shows the <FilterCondition> for a REMOTEWMS:

<FilterCondition>

<WMSRequest><![CDATA[VERSION=1.1.1&LAYERS=Ortsteile,Bezirke&

STYLES=style1,default&FORMAT=jpg&BGCOLOR=0xFFFFFF&

TRANSPARENT=true]]></WMSRequest>

<deegree:VendorspecificParameterDefinition>

<deegree:PassedVendorspecificParameter>

<deegree:Name>sessionid</deegree:Name>

<deegree:Name>another</deegree:Name>

</deegree:PassedVendorspecificParameter>

<deegree:AddedVendorspecificParameter>

<deegree:VendorspecificParameter>

<deegree:Name>user</deegree:Name>

<deegree:Value>aUser</deegree:Value>

</deegree:VendorspecificParameter>

<deegree:VendorspecificParameter>

<deegree:Name>password</deegree:Name>

<deegree:Value>aPassword</deegree:Value>

</deegree:VendorspecificParameter>

</deegree:AddedVendorspecificParameter>

</deegree:VendorspecificParameterDefinition>

</FilterCondition>

In this case the filter expression is overwriting several parameters of the layers (Name of the data store, styles) and of an incoming request (VERSION, FORMAT, BGCOLOR, TRANSPARENT). Other parameters (SRS, WIDTH, HEIGHT, BBOX, EXCEPTION, REQUEST) must not be overwritten, as this might lead to inconsistencies when processing GetMap and GetFeatureInfo-Requests. If a REMOTEWMS does not support SRS used by a GetMap request against deegree WMS deegree will ensure that a REMOTEWMS will be requested with a SRS it supports and that the map returned by it will be transformed into desired SRS.

It is also possible to tell deegree which vendor specific parameters of an incoming request will be passed on to the remote server (the rest will be ignored) and which ones shall be automatically added to each request. This may be useful if the remote WMS does not know about a session ID, but requires extra login information, for example.

In the above example, the parameters “sessionid” and “another” would be passed along with their values, as well as the additional “user” and “password” parameters with their values “aUser” and “aPassword”.

To clarify, an “added” parameter is a parameter which will be added to each cascading request with its value. In the example, the remote WMS will receive GetMap requests like “...&request=GetMap&user=aUser&password=aPassword”.

A “passed” parameter will cause the deegree WMS to make from a GetMap request like “...&request=GetMap&sessionid=abc123abc&another=andmore” a request to the remote WMS like “...TRANSPARENT=true&sessionid=abc123abc&another=andmore”.

The VendorspecificParameterDefinition element is optional.

A filter for a WCS is similar to one for WMS:

<FilterCondition>

<WCSRequest>

<![CDATA[version=1.0.0&Coverage=world&Format=jpg]]>

</WCSRequest>

</FilterCondition>

To all filters the bounding box of the GetMap request will be added dynamically for each request.

When assigning a RemoteWMS as a data source you may not just perform GetMap requests against it but also GetFeatureInfo requests. Because OGC WMS specification does not define a clear format for GetFeatureInfo responses deegree WMS may not be able to process results returned by a cascaded WMS. If a cascaded server returns an XML format you have the option to register an XSLT-script to the corresponding data source that transforms incoming XML documents into flat GML2 compliant feature collections. Registration of such an XSL script is done by adding the following element:

<deegree:FeatureInfoTransformation>

<deegree:OnlineResource

xlink:href="file:///C:/deegree/wms/sanitize.xsl"

xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"/>

</deegree:FeatureInfoTransformation>

The XSLT script sanitize.xsl can be found in deegree SVN at base/trunk/scripts/xslt/wms; but you are free to use any other script that may do some special changes.

At last the element <deegree:TransparentColors> can be used with raster data sources (WMS, WCS). It defines a list of colours that shall be turned to be transparent. For each colour of a raster that shall be transformed to be transparent one <deegree:Color> element is added to <deegree:TransparentColors>. Colors are defined as hexadecimal RGB code with a leading '#'. The transparency will be a complete transparency with no opacity left.

<deegree:TransparentColors>

<deegree:Color>#000000</deegree:Color>

<deegree:Color>#FF0000</deegree:Color>

</deegree:TransparentColors>

2. Database-based data sources

Besides the service based data sources, there is the possibility to use a database as data source directly. In the <deegree:Name> element, the name for the FeatureType is specified. The <deegree:type> element declares the data source type as DATABASE. The following jdbc-namespace elements define the database which is used as data source. In the example, the data source is a postgreSQL database. The associated entries can be found in the <jdbc:Driver> element and at the beginning of the url in the <jdbc:Url> entry. The <jdbc:Url> element specifies the database url. The <jdbc:User> and <jdbc:Password> elements contain the login information for the used database.

After defining the database connection the GeometryField of the used database relation must be named. Thereupon the database-based data source uses the SQLTemplate to determine the database relation which the layer should use. For that, it is important, that the SQL statement ends with where, like in the example. The NativeCRS element mentions the CRS used by the database relation. With the CustomSQLAllowed element it is possible to decide if custom SQL access is allowed. Possible values for that are “true” or “false”. At least there is to mention, that it is necessary to change the style file. Without changing the deegree name space there from app to DATABASE, styles will not work.

<Layer queryable="1" noSubsets="0" fixedWidth="0" fixedHeight="0">

<Name>placeofworship</Name>

<Title>PlacesOfWorshipBonn</Title>

<Abstract>deegree demo WMS</Abstract>

<KeywordList>

<Keyword>deegree</Keyword>

<Keyword>layer</Keyword>

</KeywordList>

<ScaleHint min="0" max="120" />

<deegree:DataSource failOnException="0"

queryable="1">

<deegree:Name>app:placeofworship</deegree:Name>

<deegree:Type>DATABASE</deegree:Type>

<jdbc:JDBCConnection xmlns:jdbc="http://www.deegree.org/jdbc">

<jdbc:Driver>org.postgresql.Driver</jdbc:Driver>

<jdbc:Url>jdbc:postgresql://localhost:5432/osm</jdbc:Url>

<jdbc:User>postgres</jdbc:User>

<jdbc:Password></jdbc:Password>

</jdbc:JDBCConnection>

<deegree:GeometryField>location</deegree:GeometryField>

<deegree:SQLTemplate>select * from wms_bonn_religion where
</deegree:SQLTemplate>

<deegree:NativeCRS>EPSG:4326</deegree:NativeCRS>

<deegree:CustomSQLAllowed>false</deegree:CustomSQLAllowed>

</deegree:DataSource>

<Style>

<Name>default:placeofworship</Name>

<Title>PlacesOfWorshipBonn</Title>

<deegree:StyleResource>styles/osm_placeofworship.xml</deegree:StyleResource>

</Style>

</Layer>

<Layer queryable="1" noSubsets="0" fixedWidth="0" fixedHeight="0">

<Name>MyData</Name>

<Title>My database layer</Title>

<ScaleHint min="0.001" max="1000000000" />

<deegree:DataSource failOnException="0" queryable="1">

<deegree:Name>MyData</deegree:Name>

<deegree:Type>DATABASE</deegree:Type>

<jdbc:JDBCConnection xmlns:jdbc="http://www.deegree.org/jdbc">

<jdbc:Driver>com.mysql.jdbc.Driver</jdbc:Driver>

<jdbc:Url>jdbc:mysql://localhost:3306/db</jdbc:Url>

<jdbc:User>admin</jdbc:User>

<jdbc:Password></jdbc:Password>

</jdbc:JDBCConnection>

<deegree:GeometryField>GEOM</deegree:GeometryField>

<deegree:SQLTemplate>

select LOCALITY_CODE, LOCALITY_NAME, value_h, AsBinary(GEOM) AS GEOM from

locality where end_measure ="2008-12-14 00:00:00"

</deegree:SQLTemplate>

<deegree:NativeCRS>EPSG:4326</deegree:NativeCRS>

<deegree:CustomSQLAllowed>true</deegree:CustomSQLAllowed>

</deegree:DataSource>

<Style>

<Name>default:MyData</Name>

<Title>Standard Legende für Mydata</Title>

<deegree:StyleResource>./styles/mydatastyles.xml</deegree:StyleResource>

</Style>

</Layer>

3. External Data Access

A third possibility for a data source is the external data access. This needs classes which specify the data source. Some classes are installed by default in deegree v.2.3. These ones are explained in this chapter.

1. OpenStreetMap Slippy Map Reader

The OpenStreetMap Slippy Map Reader is able to run tiles from the OpenStreetMap-Project (→ http://www.openstreetmap.org).

After defining a data source name with the <deegree:name> element. The type of the data source is specified as EXTERNALDATAACCESS. The name of the class is org.deegree.ogcwebservices.wms.dataaccess.OSMSlippyMapReader. At least a Configurationfile is mentioned, in which the properties of this data source are stated.

<Layer queryable="0" noSubsets="0" fixedWidth="0" fixedHeight="0">

<Name>OSMSlippyMapMN</Name>

<Title>OSM Slippy Map Mapnik</Title>

<Abstract>deegree demo WMS</Abstract>

<KeywordList>

<Keyword>deegree</Keyword>

<Keyword>layer</Keyword>

</KeywordList>

<ScaleHint min="0" max="1400" />

<deegree:DataSource failOnException="0"

queryable="1">

<deegree:Name>OSMMapnik</deegree:Name>

<deegree:Type>EXTERNALDATAACCESS</deegree:Type>

<deegree:ClassName>org.deegree.ogcwebservices.wms.dataaccess.OSMSlippyMapReader</deegree:ClassName>

<deegree:ConfigurationFile>dataaccess/osm/osmmapnik.properties</deegree:ConfigurationFile>

</deegree:DataSource>

</Layer>

2. WKT

A further possibility to make use of an external data source, is to use WKT. Using WKT makes it possible to add points, lines and polygons to a request and show them on the map.

The configuration of the layer is similar to the one of the OSM Slippy Map Reader. The class name and the ConfigurationFile differ from it as you can see in the example below.

<Layer fixedHeight="0" fixedWidth="0" noSubsets="0" queryable="0">

<Name>position</Name>

<Title>Position</Title>

<Abstract>deegree demo WMS</Abstract>

<KeywordList>

<Keyword>deegree</Keyword>

<Keyword>layer</Keyword>

</KeywordList>

<ScaleHint min="0" max="2800" />

<deegree:DataSource failOnException="0"

queryable="1">

<deegree:Name>TestExternalDataAccess</deegree:Name>

<deegree:Type>EXTERNALDATAACCESS</deegree:Type>

<deegree:ClassName>

org.deegree.ogcwebservices.wms.dataaccess.WKTMarker

</deegree:ClassName>

<deegree:ConfigurationFile>

./dataaccess/wkt/wkt2.properties

</deegree:ConfigurationFile>

</deegree:DataSource>

<Style>

<Name>default:position</Name>

<Title>default:position</Title>

<Abstract>Position</Abstract>

<deegree:StyleResource>styles/wkt_position.xml</deegree:StyleResource>

</Style>

</Layer>

The properties file used for configuration looks like this:

# name of the feature type that will be created (important for style definition)
FeatureType={http://www.deegree.org/app}:PositionType

# name of the vendor specific GetMap parameter that shall be evaluated
WKT=WKT2

The configuration given above makes a deegree WMS handling a vendorspecific parameter named WKT2. A valid WKT geometry must be assigned to this parameter as part of a GetMap request. deegree WMS will create a feature instance from the WKT with feature type 'PositionType' in namespace 'http://www.deegree.org/app'. For rendering engine of deegree there is no difference to features read from a WFS or a database, so style definition for a layer using WKT from vendorspecific parameters is the same as for any other layer based on vector data.

Example GetMap request:

http://$URL of a WMS$?

REQUEST=GetMap&SERVICE=WMS&VERSION=1.1.1&WIDTH=300&HEIGHT=238&LAYERS=Vegetation,position&TRANSPARENT=TRUE&FORMAT=image/png&BBOX=372233.9342431239,4460438,489069,4552689&SRS=EPSG:26912&STYLES=&WKT2=LINESTRING(373000 4470000, 480000 4550000)

7. SRS / BoundingBox / Style (within Layer)

The following elements are optional elements defined by WMS 1.1.1. They are not modified by the deegree-configuration and not initialized with default values, save the SRS where a value of EPSG:4326 will be used if no other SRS is specified.

For bounding boxes care should be taken to use the correct SRS attribute, else clients won't be able to make use of it and the WMS may decide for (correct) requests to be outside and render the empty image instead of your data.

The LatLonBoundingBox should be specified at least once in the root layer, since the WMS specification says it's mandatory.

<!-- Just add the <SRS> you wish to support with your WMS -->

<!-- default = EPSG:4326 -->

<SRS>EPSG:4326</SRS>

<SRS>EPSG:26912</SRS>

<!-- It is strongly recommended that you set a LatLonBoundingBox; further <BoundingBox>es are optional. Each layer inherits the BBoxes of the parent layer as long as no explicit on is set. -->

<LatLonBoundingBox miny="-90" maxy="90" minx="-180" maxx="180" />

<!-- Setting <BoundingBox>es ist optional but if set be sure to set the correct SRS="EPSG:" -->

<BoundingBox SRS="EPSG:26912" miny="3581352" maxy="5432672" minx="0" maxx="1504379" />

Note that the deegree WMS supports automatic coordinate reference system (CRS) for vector data (In WMS Specification the notion SRS instead of CRS is used). This means each layer based on a vector data set coming from a shape file or an Oracle Spatial database is available in nearly 300 CRS; you just have to define the ones you like for each layer or group of layers through <SRS> elements as in the code fragment above. A list of supported CRS is given in appendix B. There, you also find a java request to extract the latest list of supported CRS.

Next are the optional styles definitions for a layer. A <deegree:StyleResource> element was added here, giving information about the resource where the style is defined. The resource where a style is defined must be a valid Styled Layer Descriptor document (see below)

<Style>

<Name>teststyle</Name>

<Title>ein teststype</Title>

<!-- here you set the name of the style and the location <deegree: StyleResource> where the WMS will find a style definition with the same <UserStyle> name-->

<deegree:StyleResource>styles.xml</deegree:StyleResource>

<Abstract>dies ist nur ein test</Abstract>

<LegendURL width="50" height="50">

<Format>image/jpg</Format>

<OnlineResource xlink="http://www.w3.org/1999/xlink" type="simple"

xlink:href="http://www.deegree.org/legend/teststyle.jpg"/>

</LegendURL>

<StyleSheetURL>

<Format>/xsl</Format>

<OnlineResource xlink="http://www.w3.org/1999/xlink" type="simple"

xlink:href="http://www.deegree.org/legend/teststyle.xsl"/>

</StyleSheetURL>

<StyleURL>