Part II : discovering Symbology Encoging 1.1 further with UserStyles

In part I we configured internal definition of styles, each called a NamedStyle and this is by using SE 1.1 because deegree3 is based on it internally. But what if you are interesting as a client to get a map from a WMS because there are interesting underlying data you want to visualize with your custom style ?

The interesting is that when a WMS service is combined with the SLD profile, then it comes with the UserStyle mechanism to allow external client to portray internal geodata in a custom way.

How to get more description of the geodata ?

Now the situation is you as a client which means you have no more access to the WMS console (as we had in part I). How can you get more information on what geodata the WMS service (you know available at http://localhost:8080/services/mywms) is able to offer ?

You know the service is able to answer to the mandatory WMS GetCapabilities operation :

let's request http://localhost:8080/services/mywms?service=WMS&request=GetCapabilities

To get more, we need the service WFS to be activated to access to new interesting operations, the first being the mandatory WFS GetCapabilities operation :

let's request http://localhost:8080/services/mywfs?service=WFS&request=GetCapabilities

we discover DescribeFeatureType and GetFeature operations are available

WFS DescribeFeatureType operation

To invoke it, we need to submit a POST HTTP request. By hand we use the REST Client firefox extension.

we set the request being POST (and not GET)

we set the url of the WFS service to http://localhost:8080/services/mywfs

we set the body with the below XML DescribeFeatureType request

we send the request

<DescribeFeatureType version="1.1.0" service="WFS"
xmlns="http://www.opengis.net/wfs"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd">
</DescribeFeatureType>

we discover the underlying model of each feature type, for instance, the “meteocities” content description is :

<complexContent>
<extension base="gml:AbstractFeatureType">
<sequence>
<element name="ID" minOccurs="0" type="decimal"/>
<element name="NAME" minOccurs="0" type="string"/>
<element name="METEO_AM" minOccurs="0" type="decimal"/>
<element name="TEMP_AM" minOccurs="0" type="decimal"/>
<element name="METEO_PM" minOccurs="0" type="decimal"/>
<element name="TEMP_PM" minOccurs="0" type="decimal"/>
<element name="geometry" minOccurs="0" type="gml:PointPropertyType"/>
</sequence>
</extension>
</complexContent>

we discover the geometry property which of type Point and the ID and NAME properties we have already used before

we discover also other decimal attributes we will use in the following: METEO_AM, METEO_PM, TEMP_AM, TEMP_PM

WFS GetFeature operation

Let's request some values for the NAME, METEO_AM and TEMP_AM properties:

we set now the body of our POST request like below

we formulate a query on the layer “meteocities”

<?xml version="1.0" encoding="UTF-8"?>
<GetFeature version="1.1.0" service="WFS"
xmlns="http://www.opengis.net/wfs"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd">
<Query typeName="meteocities">
<PropertyName>NAME</PropertyName>
<PropertyName>METEO_AM</PropertyName>
<PropertyName>TEMP_AM</PropertyName>
</Query>
</GetFeature>

we receive some feature members with their values like this for Lausanne and Geneve:

<gml:featureMember>
<app:meteocities xmlns:app="http://www.deegree.org/app" gml:id="METEOCITIES_0">
<app:NAME>Lausanne</app:NAME>
<app:METEO_AM>19.00</app:METEO_AM>
<app:TEMP_AM>26.00</app:TEMP_AM>
</app:meteocities>
</gml:featureMember>
<gml:featureMember>
<app:meteocities xmlns:app="http://www.deegree.org/app" gml:id="METEOCITIES_1">
<app:NAME>Geneve</app:NAME>
<app:METEO_AM>13.00</app:METEO_AM>
<app:TEMP_AM>11.00</app:TEMP_AM>
</app:meteocities>
</gml:featureMember>

notice that by adding <PropertyName>geometry</PropertyName> in your request, you will also get some geometry details

like below the point coordinates of Lausanne shown in EPSG:4326 projection

<app:geometry>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>46.525710 6.601897</gml:pos>
</gml:Point>
</app:geometry>

Get some more metadata description

But what do these values represents. We would need a kind of metadata catalog that is able to give more descriptive information. Did you notice that the result of a WMS GetCapabilities provide a metadata URL ? Have a look:

we request the WMS GetCapabilities: http://localhost:8080/services/mywms?service=WMS&request=GetCapabilities

we go to the meteocities section and discover the below <MetadataURL> subsection:

<MetadataURL type="ISO19115:2003">
<Format>application/xml</Format>
<OnlineResource xlink:type="simple"
xlink:href="http://localhost/webmaptuto/catalog-service/ogctuto-description.html#md_meteocities"/>
</MetadataURL>

this is where we could take benefits of a link with a catalog, usually compliant with OGC CSW standard and ISO19115

for this tutorial we do not use a real catalog, but by way of an example we show how the link would be done

in our simplified case we use a shortcut with a static HTML page which provides some useful information to go further (the kind of description a catalog system would provide)

let's follow this MetadataURL and we get this:

meteocities weather and temperature data:
- METEO_AM (morning) / METEO_PM (afternoon) codes :
(1) ...
(2) assez ensoleillé, passages nuageux
(...) ...
(6) éclaircies, averses isolées
(...)
(9) nuageux, quelques averses
- TEMP_AM (morning) / TEMP_PM (afternoon) : temperatures in ° celsius

Our custom meteo sld:UserStyle

All meta information we were able to get is useful because we are now able to build a custom style with our nice weather symbols:

have a look to our collection of weather symbols available online from here http://localhost/ogctuto/meteo-symbols/cloud like:

25.gif 25.gif 6.gif 6.gif 9.gif 9.gif

The purpose is now to build a rich symbol like below for each city of our map:

the left symbol is controled by the METEO_AM property

the right symbol is controled by the METEO_PM property

the left label is controled by the TEMP_AM property

the right label is controled by the TEMP_PM property

the city label is controled by the NAME property

Introducing the creation of a custom sld:UserStyle

All these internaly-defined NamedStyle that the WMS service offers are nice, but as an external client (versus the WMS manager), I would like to represent these lakes with my own style (without asking the WMS manager to add it as an internal NamedStyle). Indeed, until now, when requesting a WMS GetMap, we were able to link a NamedLayer only with a NamedStyle through the usual LAYERS and STYLES parameters.

To link with a custom style, we need to create a sld:UserStyle !

A sld:UserStyle is a standardized way to link a server-side layer (e.g. NamedLayer) with a client-side custom style defined with SE language. This WMS capability is enabled thanks to its SLD profile.

In other words, SLD does the link between WMS and SE. Let's see an example of a WMS request with SLD:

first, we need to create a <StyledLayerDescriptor> file describing the link of a layer with our style

we create and store the file step1-mylakes.sld.xml so as to be available through the web

we see how SLD and SE are combined with the nesting of two namespaces, the default for SLD, the se prefix for SE

the SLD logic is to interlink a <NamedLayer> with a <UserStyle>

the <NamedLayer> has a name which belongs to an underlying layer the WMS is able to offer (here it is our swiss lakes)

the <UserStyle> encapsultes the complete style using SE language, just like we've done all along Part I (the only new thing is to prefix all SE elements so as to separate SLD specific elements from SE elements

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<StyledLayerDescriptor version="1.1.0"
xmlns="http://www.opengis.net/sld"
xmlns:se="http://www.opengis.net/se"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1/StyledLayerDescriptor.xsd">
<NamedLayer>
<se:Name>g4see98</se:Name>
<UserStyle>
<se:FeatureTypeStyle version="1.1.0">
<se:Rule>
<se:PolygonSymbolizer>
<se:Fill>
<se:SvgParameter name="fill">#4563F9</se:SvgParameter>
</se:Fill>
</se:PolygonSymbolizer>
<se:PolygonSymbolizer>
<se:Fill>
<se:GraphicFill>
<se:Graphic>
<se:Mark>
<se:WellKnownName>CIRCLE</se:WellKnownName>
<se:Fill>
<se:SvgParameter name="fill">#B8DCEA</se:SvgParameter>
</se:Fill>
<se:Stroke>
<se:SvgParameter name="stroke">#B8DCEA</se:SvgParameter>
</se:Stroke>
</se:Mark>
<se:Size>8</se:Size>
</se:Graphic>
</se:GraphicFill>
</se:Fill>
</se:PolygonSymbolizer>
</se:Rule>
</se:FeatureTypeStyle>
</UserStyle>
</NamedLayer>
</StyledLayerDescriptor>

secondly, the SLD document is used as a WMS input parameter, replacing the usual LAYERS and STYLES

we come back to our GetMapper to ask for a WMS/SLD request

we enable the SLD parameter (just click on the [-] button)

we set the SLD parameter to point to our custom style file: http://localhost/ogctuto/step1-mylakes.sld.xml

we run the GetMap request to see our lakes styled according to what we have described above

Towards a meteo style

Now that we know everything about the “meteocities” layer, we are be able to create a custom style so as to transform the precious meteo properties into meteo symbols and labels.

Step 1 : all cities except Rappelswil

Have a look to the meteosuisse map and you will notice there is no meteo information for Rapperswil. So we will have to ignore that specific feature before starting our meteo style.

Step 2 : style the left symbol

Step 3 : style the right symbol

Misc

a bunch of filtered rules for meteo symbols ...

categorize, interpolate, ...