GIS and Media fusion
"The explosive growth of the GeoWeb and geographic information has made GIS powerful media for the general public to communicate, but perhaps more importantly, GIS have also become media for constructive dialogs and interactions about social issues." - Sui & Goodchild
User Tools
ogo:sld_se_part2
Differences
This shows you the differences between two versions of the page.
|
ogo:sld_se_part2 [2013/06/23 16:19] oertz |
ogo:sld_se_part2 [2018/05/16 10:05] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 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 [[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 | ||
| - | |||
| - | <code> | ||
| - | <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> | ||
| - | </code> | ||
| - | |||
| - | * we discover the underlying model of each feature type, for instance, the "meteocities" content description is : | ||
| - | <code> | ||
| - | <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> | ||
| - | </code> | ||
| - | * 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" | ||
| - | <code> | ||
| - | <?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> | ||
| - | </code> | ||
| - | * we receive some feature members with their values like this for Lausanne and Geneve: | ||
| - | <code> | ||
| - | <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> | ||
| - | </code> | ||
| - | * 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 | ||
| - | <code> | ||
| - | <app:geometry> | ||
| - | <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> | ||
| - | <gml:pos>46.525710 6.601897</gml:pos> | ||
| - | </gml:Point> | ||
| - | </app:geometry> | ||
| - | </code> | ||
| - | |||
| - | ===== 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: | ||
| - | <code> | ||
| - | <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> | ||
| - | </code> | ||
| - | * 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: | ||
| - | <code> | ||
| - | 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 | ||
| - | </code> | ||
| - | |||
| - | ===== 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 <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 | ||
| - | |||
| - | <code> | ||
| - | <?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> | ||
| - | </code> | ||
| - | |||
| - | * 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 about the "meteocities" layer, we will 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. | ||
| - | |||
| - | |||
| - | |||
| - | === Step 2 : style the left symbol === | ||
| - | |||
| - | === Step 3 : style the right symbol === | ||
| - | |||
| - | ==== Misc ==== | ||
| - | * a bunch of filtered rules for meteo symbols ... | ||
| - | * categorize, interpolate, ... | ||
ogo/sld_se_part2.txt · Last modified: 2018/05/16 10:05 (external edit)
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
