News > View Services
News' image preview

In our daily work to publish and maintain INSPIRE-compliant view and download services for our customers, the importance of supporting the portrayal rules outlined in data specifications is ever present. We have thus been working for a long time to provide as complete as possible portrayal rules, which we provide as presets for any INSPIRE services published on our cloud platform, haleconnect.

What is an SLD, and why might I need it in INSPIRE?

The technical guidelines for each of the 34 INSPIRE themes contain a list of required or recommended layers which define the cartographic representation of data sets provided as view services. The chosen model for feature display in INSPIRE is the Styled Layer Descriptor (SLD) and Symbology Encoding (SE) standards, developed and published by the OGC.

The OGC standard SLD is an XML document that uses the OGC standards Symbology Encoding (SE) and Filter Encoding (FE) to define the cartographic rules by which to display features. The SLD standard extends the OGC Web Map Service (WMS). A basic WMS supports named layers and styles which do not enable end-users to define custom symbology. The SLD standard extends the WMS standard to allow users to provide styling rules in a Styled Layer Descriptor file. Web map services that support SLDs retrieve features from web feature services and apply the styling rules contained in the SLD.

What systems can I use to implement SLDs?

At wetransform, we use the open source framework deegree to provide OGC- and INSPIRE-compliant view and download services. deegree view services (Web Map Services) support the use of SLDs. Like most web map servers, deegree supports several deegree-specific functions which extend the SLD, SE and FE standards to enhance styling. Our development process for each SLD was to first check the examples and requirements in the INSPIRE data specification, and then to use an XML editor to iteratively implement the SLD. We directly tested is on our cloud platform haleconnect, with data sets specifically developed for this purpose. When a dataset is published on the haleconnect platform, the feature type is identified and our INSPIRE SLD library is searched for a matching style layer. INSPIRE SLDs are then applied if available.

What are the positives?

SLDs can display features with simple symbology requirements, and for many INSPIRE themes, the SLD standard is adequate. Filter encoding (FE) can be used to make selections and apply symbology to different geometries, or attributes. Many INSPIRE SLDs are based on INSPIRE codelist values. Datasets are filtered based on codelist values to obtain the desired feature sets, and symbology is applied to only those features matching the filter criteria. In other cases, SLDs are based on geometry type. At wetransform, we apply deegree-specific filter functions to filter datasets by geometry type in order to apply the correct symbology.

In our daily work to publish and maintain INSPIRE-compliant view and download services for our customers, the importance of supporting the portrayal rules outlined in data specifications is ever present. We have thus been working for a long time to provide as complete as possible portrayal rules, which we provide as presets for any INSPIRE services published on our cloud platform, haleconnect.

What is an SLD, and why might I need it in INSPIRE?

The technical guidelines for each of the 34 INSPIRE themes contain a list of required or recommended layers which define the cartographic representation of data sets provided as view services. The chosen model for feature display in INSPIRE is the Styled Layer Descriptor (SLD) and Symbology Encoding (SE) standards, developed and published by the OGC.

The OGC standard SLD is an XML document that uses the OGC standards Symbology Encoding (SE) and Filter Encoding (FE) to define the cartographic rules by which to display features. The SLD standard extends the OGC Web Map Service (WMS). A basic WMS supports named layers and styles which do not enable end-users to define custom symbology. The SLD standard extends the WMS standard to allow users to provide styling rules in a Styled Layer Descriptor file. Web map services that support SLDs retrieve features from web feature services and apply the styling rules contained in the SLD.

What systems can I use to implement SLDs?

At wetransform, we use the open source framework deegree to provide OGC- and INSPIRE-compliant view and download services. deegree view services (Web Map Services) support the use of SLDs. Like most web map servers, deegree supports several deegree-specific functions which extend the SLD, SE and FE standards to enhance styling. Our development process for each SLD was to first check the examples and requirements in the INSPIRE data specification, and then to use an XML editor to iteratively implement the SLD. We directly tested is on our cloud platform haleconnect, with data sets specifically developed for this purpose. When a dataset is published on the haleconnect platform, the feature type is identified and our INSPIRE SLD library is searched for a matching style layer. INSPIRE SLDs are then applied if available.

What are the positives?

SLDs can display features with simple symbology requirements, and for many INSPIRE themes, the SLD standard is adequate. Filter encoding (FE) can be used to make selections and apply symbology to different geometries, or attributes. Many INSPIRE SLDs are based on INSPIRE codelist values. Datasets are filtered based on codelist values to obtain the desired feature sets, and symbology is applied to only those features matching the filter criteria. In other cases, SLDs are based on geometry type. At wetransform, we apply deegree-specific filter functions to filter datasets by geometry type in order to apply the correct symbology.

Symbology encoding is used to apply scale ranges and symbology choices in SLD layers. The MaxScaleDenominator and MinScaleDenominator elements can be used to control display ranges for your datasets. We use scale ranges to control the display of Administrative Units layers, so that each administrative hierarchical level displays at only one scale range.

Map 1 - Administrative Units, Catalonia. Filter and scale range applied to Administrative Hierarchical Level 3rd order
Map 1 Administrative Units, Catalonia. Filter and scale range applied to Administrative Hierarchical Level 3rd order.
Map 2 - Administrative Units, Catalonia. Filter and scale range applied to Administrative Hierarchical Level 5th order
Map 2 Administrative Units, Catalonia. Filter and scale range applied to Administrative Hierarchical Level 5th order.

Symbology encoding also offers standard cartographic styling options. Surface features can be styled using color or graphic fill options, and opacity. Line features can be styled in various ways by applying color and opacity, line casing, dashed lines and line join options which control how line features are symbolized where they join. Point features can be symbolized using graphic symbols, such as icons, or the WellKnownName element that includes the values square, circle, triangle, star, cross, and x.

The Symbology Encoding standard (SE) also supports the styling of text labels. Font family, style and size selection are all supported. Label placement rules enable the user to control how labels are displayed in relation to the geometry they describe, including offsets, rotation and splining.

What are the challenges?

In some cases, the SLD standard cannot handle the complexity of INSPIRE data models. Feature types with properties which contain links to geometries, and indirect geometries, commonly found in the Transport Network theme, cannot be symbolized.

There are also challenges associated with the display of INSPIRE compliant, complex GML which contains multiple features with the same geometry type, which are overlapping. The Administrative Units layer displays with all administrative hierarchical levels at once, and from the perspective of the viewer, the information displayed is indiscernible. The Administrative Units theme also contains feature types with linked features, which makes partitioning by feature type problematic. As mentioned, wetransform applies scale ranges to control display in this case (See Map 1., Map 2.).

In many themes, a further challenge is the requirement to provide one SLD layer per codelist value - That’s a lot of SLD layers! Some codelists, such as those found in the Habitats and Biotopes theme, have hundreds of values. To complicate matters, codelists which exist in externally referenced documents, such as Natura200, make symbolization based on their values difficult.

In our work with the Utility and Governmental Services theme, we discovered a need for a standardized icon library for the symbolization of point geometries found in the Administrative and Social Governmental Services codelist. Objects defined in this codelist include hospitals, schools, police and fire stations, and other institutions which offer essential services, and should be symbolized using standardized iconography.

A further challenge of the SLD standard is the need to rely on web map server-specific functionality to apply advanced cartographic styling such as hatching, patterned fills, marker lines and the display of continuous data using interpolation over color ramps, and more.

What is wetransform working towards?

Portrayal recommendations vary widely across the data specification documents of all themes, and often contain unusable SLD code examples, however many of the descriptions contain adequate information to create working SLDs. Many SLDs are based on required attributes, such as geometry, and lend themselves to generic implementation. We are currently building an extensive library of INSPIRE compliant SLDs across all 34 Annex themes. In the future, we hope to develop functionality which will provide end-users with more fine-grained control of the attributes symbolized.

(more)