Styling GML to KML - XSLT
This note provides a simple example of styling GML data (obtained from a Web Feature Service) to KML. KML is used in this case as a graphics output language like SVG and the Google Earth Browser can be thought of as somewhat the equivalent of the Adobe SVG plug-in.
GML provides a powerful language for describing geography. In this example we combine GML with XSLT (stylling rules) to generate KML the latter being regarded as a graphics output language for the Goopgle Earth browser.
The instance shown here is for a static GML file, however, this can easily be done in a dynamic fashion with the data (GML) being pulled in real time from a WFS (Web Feature Service) and styled and then pushed to the Google Earth client. We will talk more about the dynamic side in a subsequent article.
Let us start by looking at the GML.
The GML data is a collection of GML dynamic features. Each dynamic feature is a link in a real time traffic model for the city of Toronto. Just to refresh your memory a dynamic feature in GML is one that has a history property. Each history consists of a set of TimeSlices, with the TiemSlices containing the time varying properties of the feature.
The general structure of the GML file is then:
FeatureCollection
featureMember
Link
.. time invariant properties
history
Time Slice (time varying properties)
Time Slice (time varying properties)
Note that in this case the time invariant properties include the geometry of the link (expressed as a GML LineString), along with the name, length and associated sensor cluster (where we get the real time data from) link reference.
The time varying properties include:
<!-- IF THE SPEED IS BETWEEN 50 and 25, USE A HIGH MID CONGESTION STYLE -->
<xsl:when test="$speed<=50 and $speed>25">
#highMidLinkStyle
</xsl:when>
The Style itself then creates some KML as in :
<Style id="highMidLinkStyle">
<LineStyle>
<color>7c00a5ff</color>
<geomScale>2</geomScale>
</LineStyle>
</Style>
The instance shown here is for a static GML file, however, this can easily be done in a dynamic fashion with the data (GML) being pulled in real time from a WFS (Web Feature Service) and styled and then pushed to the Google Earth client. We will talk more about the dynamic side in a subsequent article.
Let us start by looking at the GML.
The GML data is a collection of GML dynamic features. Each dynamic feature is a link in a real time traffic model for the city of Toronto. Just to refresh your memory a dynamic feature in GML is one that has a history property. Each history consists of a set of TimeSlices, with the TiemSlices containing the time varying properties of the feature.
The general structure of the GML file is then:
FeatureCollection
featureMember
Link
.. time invariant properties
history
Time Slice (time varying properties)
Time Slice (time varying properties)
Note that in this case the time invariant properties include the geometry of the link (expressed as a GML LineString), along with the name, length and associated sensor cluster (where we get the real time data from) link reference.
The time varying properties include:
- the average vehicle speed in the Link (a segment of highway)
- occupancy (estimate of the number of vehicles)
- link transit time
<!-- IF THE SPEED IS BETWEEN 50 and 25, USE A HIGH MID CONGESTION STYLE -->
<xsl:when test="$speed<=50 and $speed>25">
#highMidLinkStyle
</xsl:when>
The Style itself then creates some KML as in :
<Style id="highMidLinkStyle">
<LineStyle>
<color>7c00a5ff</color>
<geomScale>2</geomScale>
</LineStyle>
</Style>
