====== Part II : discovering Symbology Encoging 1.1 further with UserStyles ====== In part I we've 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 with your custom style because there are interesting underlying data you want to visualize? 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 [[https://addons.mozilla.org/fr/firefox/addon/restclient|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 * we discover the underlying model of each feature type, for instance, the "meteocities" content description is : * 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" NAME METEO_AM TEMP_AM * we receive some feature members with their values like this for Lausanne and Geneve: Lausanne 19.00 26.00 Geneve 13.00 11.00 * notice that by adding ''geometry'' in your request, you will also get some geometry details * like below the point coordinates of Lausanne shown in EPSG:4326 projection 46.525710 6.601897 ===== 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 subsection: application/xml * 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{{:ogo:25.gif|25.gif}}6.gif{{:ogo:6.gif|6.gif}}9.gif{{:ogo:9.gif|9.gif}} | **The purpose is now to build a rich symbol like below for each city of our map:** | {{:ogo:weatherexample.png|}} | * 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 file describing the link of a layer with our style * we create and store the file step0-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 with a * the has a name which belongs to an underlying layer the WMS is able to offer (here it is our swiss lakes) * the 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 g4see98 #4563F9 CIRCLE #B8DCEA #B8DCEA 8 * 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/step0-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 [[http://www.meteosuisse.admin.ch/web/fr/meteo/previsions_en_detail.html|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. We have previously discovered a first reason to use SLD (how to link with a custom style), here is a second by a way to filter features of a layer: * we create and store a file named "step1-filterRapperswil.sld.xml" so as to be available through the web * our is identified by its name "meteocities" * but also we use the functional element to formulate a filter so as to exclude Rapperswil (ID=0) from the rendering process * the filter language is the same than the one we used in Part I to create a filtered cartographic rule meteocities ID 0 pointCities * **notice the element:** in this example we do not use an sld:Style, but rather a NamedStyle : the obvious fact is that with SLD it is still possible to refer to an internal NamedStyle according to its usual name "pointCities" (the same name we used in Part I) === Step 2 : style the left symbol === === Step 3 : style the right symbol === === Step 4 : style for labels and separators === === The complete style === meteocities ID 0 METEO_AM 1 image/gif -22 0 METEO_AM 28 image/gif -22 0 METEO_PM 1 image/gif 22 0 METEO_PM 28 image/gif 22 0 NAME Arial 12 0 -20 TEMP_AM # ° Arial 12 -15 -35 TEMP_PM # ° Arial 12 15 -35 image/gif image/gif 0 -35 * **below is what we finally get ...** {{:ogo:meteographicfinal.sld.png|}} ==== Misc ==== * categorize, interpolate, ...