Washington, DC
Subscribe to GeoRSS Subscribe to KML

KML 3 Kick-off, Module: Styling

Published in KML  |  7 Comments

There are many questions out there about how KML, GML, GeoRSS, and others differ from one another and how they work together. The primary strength of KML is the ability to simply style, or visualize, geographic information. By comparison GeoRSS doesn’t support any styling, and GML uses SLD to add styling to the feature markup.

Sidebar: W[F,M]S

This also leads to interesting discussions about how KML fits into the OGC services. Two of the prevalent OGC OWS, WFS (Web Feature Service) and WMS (Web Mapping Service) differ in that WFS is supposed to supply just features, and WMS supplies visualizations. Typically, this has meant WMS supplies raster images – though at least one format, SVG, is still just ‘text’. Therefore, one may assume KML should be part of WFS – but instead it is being made part of WMS.

Personally, I think this distinction is tedious, and serves to confuse users. I understand that separating the two services makes it easier for developers, but this is an inverted approach and demonstrates that OGC standards are derived by developers and not many users.

Back to styling

Anyways, it is still apparent that styling is a key element of KML, and one that is desired to be solidified and strengthened in the future. There have been comments that while styling is useful, KML currently mingles features and style too closely. For example, to style a line in KML, you first define the style in your KML document head, but then have to explicitly reference that style from within the Placemark element.

KML does allow you to refer to another KML document for the style – so you could have a mapstyles.kml that you reference from your KML Placemarks. However you are fairly limited in what you can do with this styling and have to explicitly define it. Additionally, you can’t give cascading styling to your KML entities that might be grouped into Folders.

Therefore, the committee discussed looking at existing styling formats for ideas and possible use in KML. SLD (Styled Layer Descriptor) is the OGC standard for specifying the visualization and styling of features from OGC web services.

However, the thread is “Agile Geography”, and SLD+GML is not really consumable by the types of developers that are interested in KML. Another option that was discussed is adopting CSS3.

CSS offers a lot of very intriguing features that would benefit KML. The simple effect would be separating styling from the geometry. In KML 2.1, any Feature (abstract element for other KML elements) can have an id. Subsequently, KML3 could add a class attribute, like in HTML, that could loosely be used to give some categorization of the Feature (road, highway, animal, newt). Then, the CSS could reference these id, class, or even use selectors to apply styling to elements.

By way of example. Note, this is completely rough and is only an example of what might be possible with some sort of cascading-styling


    Placemark {
      font-size: 8px;
    #roads {
      color: black;
      width: 2px;
    .primary {
        color: blue;
        width: 4px;
    .secondary {
      width: 1px;
    Placemark[num_lanes=2] {
      width: 2px;


  <Folder id="roads">
    <Placemark class="primary" id="I66">
        <gml:pos>42, -83, 100</gml:pos>

With my “web developer” hat, this seems really attractive. Using a language and markup I already know and have tools for. It also provides some really powerful capabilities for applying hierarchical styling, both through selectors, and also the ability to apply multiple stylesheets to a KML document. So there could be a stylesheet that is linked to by the document for roads, another for POI’s, and then I could apply my own default in my KML client application.

You may notice the Placemark[num_lanes=2]. CSS3 supports applying styles based on evaluating attributes of elements. So a CSS like this may allow you to easily create thematic maps based on the value of the metadata. However, we still need to figure out exactly how that would mesh with the Metadata module concept (coming up in future blog post).

There is still work to do evaluating the existing KML as well as SLD and some sort of CSS. Now would be a good time to speak up with your thoughts and use cases for how you would to style your data.

Similar Posts


  1. Carl says:

    August 3rd, 2007 at 3:36 pm (#)

    Having KML being related to WMS is news to me. I am the one who put KML 2.1 into the OGC document template. Other than OWS-5, I have also been in on most of the discussions related to KML and the OGC. In none of these discussions has there ever been any reference to working KML with WMS. There has been considerable discussion about how a WFS could provide KML instead of just GML. Even the OGC Architecture Board has been in on these discussions.

    Maybe I am off base, but I believe that KML should eventually be a standalone OGC standard that can be referenced and used by other OGC standards (much as SLD is used by WMS). Further, KML 3.0 – again from my understanding – will be aligned and harmonized as appropriate with existing OGC/ISO standards, specifically CRS and GML 3.2.1 geometry.

    Just had to jump in!


  2. Jason Birch says:

    August 3rd, 2007 at 10:42 pm (#)


    I’m wondering about the use of tags inside the .kss document. I can see that these would need to be used inside the KML document

    <kstyle src=”” />


    Placemark {
    font-size: 8px;

    but in the .kss file itself I’d prefer not to see tags.

    Let’s see if those tags make it…


  3. Jason Birch says:

    August 3rd, 2007 at 10:50 pm (#)

    I’m not sure about the value of CRS support in KML. It should definitely be just an optional module, or at least an optional element with a default value of 4326, as many traditional KML users have no understanding of anything other than lat/lon.

    Whatever you do, make sure that KML doesn’t get as open-ended as GML. The minute you require users to do something other than simple markup like HTML, you lose a large chunk of your audience.


  4. Brian Flood says:

    August 4th, 2007 at 9:45 am (#)

    good stuff, different but intersting none the less.

    i have to agree with Jason on the CRS support, not only will it confuse a great deal of user creating content, ti will also make it that much harder for those integrating KML into their applications.

    CSS in KML might be a very natural replacement for the existing styling, a “class” attribute seems right. The CSS3 attribute evaluator would also eliminate the need to use Update tags to change styling of placemarks at runtime.

    Was there any talk about how the attributes will be stored? KML Schema? Microformat? somethign else?


  5. Andrew says:

    August 4th, 2007 at 9:50 am (#)

    @Jason Birch & @Brian Flood – KML 3 will probably only support 4326, and so would not require (or support) specifying it anywhere in the actual markup. So you’re safe. 🙂

    I’m writing up the Metadata module post this weekend and will post it on Monday.

  6. High Earth Orbit » Blog Archive » EPA KML a great step, but both forward and backward says:

    December 2nd, 2007 at 10:55 am (#)

    […] tell once you’ve exported. Unfortunately KML doesn’t currently support the ability to style based on ExtendedData, other than for the Balloon text. But it would still be useful to put this data […]

  7. GeoCommons Maker! launches :: High Earth Orbit says:

    October 1st, 2008 at 7:33 am (#)

    […] GoogleEarth or WorldWind and retain the styling. This was a goal of the OGC OWS-5 testbed that I wrote about quite extensively. The styling is actually sort of difficult due to the design of KML itself. In […]