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.
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
42, -83, 100
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.