My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
Planning  
HKT - for happy kml files
Updated Dec 13, 2010 by underbluewaters

Introduction

Basic Concept

This wiki is a companion piece to KMLRenderingStrategies. Here I'm mostly avoiding the thorny topic of advanced regionation of vectors in favor of defining a stylesheet-based strategy for rendering simple kml files. Regionation is important, but the focus here is on the syntax of the stylesheet and the implementation of the rendering. It should be something that could incorporate those advanced regionating strategies later.

Technical Details

Assumptions

Will be implemented in python

The only two options with the mature library support needed to handle spatial data are Python and Java, and our shop isn't very experienced with Java. Also, it would be nice to add support for this workflow into geodjango to support MarineMap.

Existing tools aren't up to the task

I feel pretty strongly about this assumption. New tools need to be built to spur adoption of kml, because current tools produce pretty poor results. I believe this is largely because they try to tack KML support onto existing workflows and tools. 2d styling technology like SLD isn't up to the task of describing how to break a dataset into Folders and NetworkLinks, or techniques to control user interaction that depend on features unique to KML.

One good example is behavior where the map changes to the data extent, both spatially and temporally when the user activates the layer. Such behavior can be described in KML, but it involves using Camera or LookAt tags in combination with NetworkLinks with special attributes. There is no analog to this in 2d cartography. I believe there is a desperate need to make techniques like this easy to implement.

I don't believe that there is a good argument to be made for shared cartography between tiled online or printed maps. While such a solution would be ideal, attempting to support both will lead to a lowest-common-denominator approach to styling. And practically all data in KML format will be viewed in Google Earth, leading to a unique choice in colors due to the single basemap available. I'd rather focus on making good KML generation extremely easy than abstracting it away as part of an existing workflow.

GUIs should be built later on, and only if they add significant value

All good web designers use text editors and raw CSS & HTML to develop their web pages. Dreamweaver and similar tools are only used by amateurs, despite it being a very mature profession and a visual medium. I'm not sure cartography needs graphical tools. Adoption of KML will be better if there are good ones, but if we are to develop them they should provide more value than simply a point and click interface, and should build on a good stylesheet api rather than replace it.

Here are some ideas for how a GUI could add value:

  • Real-time feedback on changes in colors, line widths, etc in situ (the Earth Plugin, otherwise it's not useful)
  • Reports out on attributes and properties of source data, as well as the unique values of those attributes so that they can be used in developing styles. (a command-line tool could do the same, but maybe not as efficiently)

Rasters and Superoverlays are well handled by other tools

We should integrate tools like TileCache and Mapnik/Cascadenik into this workflow.

The Case for CSS

  • It's by far the most familiar styling syntax
  • Has been tried and tested for cartography, and has examples to learn from (Cascadenik, GeoServer CSS module)
  • Hopefully some good examples for how to parse it in python?
  • terse, readable sytax
  • cascading nature is pretty damn useful

Problems it would solve

  • Define colors using 8-bit hex values. Gahh I hate the color/opacity format in KML!!!
  • Selectors syntax that allows you to add style to features based on the contents of their attributes. These style should be compiled down behind the scenes to a limited set and referenced via styleUrls
  •     Placemark {
            display: none;
        }
    
        Placemark[type=highway], Placemark[type=interstate] {
            display: true;
        }
  • Hover behavior should be defined simply, rather than the the StyleMap shenanigans required to scale an icon on hover. Psuedocode:
  •     Placemark {
            label: none;
            icon-scale: 1.0;
        }
    
        Placemark:hover {
            label: #fff attr('title');
            icon-scale: 1.2;
        }
  • Some intelligent way of handling proportional symbols and basic data visualization.
  • Some way to define folders, sometimes based on attributes, and a way to make them networklinks conditionally based on the number of features in the folder for performance.
  • Output as KML or KMZ
  • Output statistics like file size, number of features.
  • Same stylesheet should be usable on multiple types of data sources (shapefile, csv, postgis table, etc)
  • Styles could be defined via selectors, then the renderer could determine how to create Style tags and manage styleUrl tags behind the scenes.

Parsing CSS

Tasks

  • Need to learn how cascadenik (implemented in python) parses css files and generally works
  • Develop syntax
    • Review cascadenik and geoserver css stylesheet support and map their properties to kml
    • Develop scheme for supporting folders and networklinks
    • strategy for acheiving more advanced techniques, like clustering
    • legend support

Example Syntax (work in progress)

The advantage with this approach is that more control can be had over the contents of the kml document, including the addition of custom tags from a different namespace:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2" 
    xmlns:gx="http://www.google.com/kml/ext/2.2"
    xmlns:hkt="http://code.google.com/p/happy-kml-tool/wiki/Reference">
    <hkt:Style><![CDATA[
        
        Folder, NetworkLink {
            flyToView: auto;
            camera-rotation: south;
            camera-extent-exaggeration: 1.2;
        }
        
        Folder[name='Mammals'] Layer[NUM_FEATURES >= 200] {
            networklink: true;
            list-item-type: checkHideChildren;
        }
        
        Folder[name='Mammals'] Placemark {
            icon-opacity: 0.5;
        }
        
        Folder[name='Mammals'] Placemark:hover {
            label: '@type';
            icon-scale: 1.2;
            icon-opacity: 1.0;
            label-color: orange;
            label-opacity: 0.8;
        }

        Layer[name='Stellar Sea Lion'] Placemark {
            icon: url('http://marinemap.org/stlr-icon.png');
        }
        
        Layer[name='Stellar Sea Lion'] Placemark:hover {
            icon: url('http://marinemap.org/stlr-icon-hover.png');
        }
        
        Document > Folder > Folder {
            list-style: radioFolder;
        }
        
        Document > Folder[NUM_FEATURES >= 200] {
            networklink: true;
        }
        
    ]]></hkt:Style>
    <Document>
        <name>Pinnipeds</name>
        <hkt:Placemarks connection="connection string to pinnipeds.shp" filter="type != ''" split="type, year">
            <hkt:AttributeMappings>
                <hkt:mapping attribute="type" match="\(stlr)\" value="Stellar Sea Lion (\1)" />
                <hkt:mapping attribute="type" match="cal" value="California Sea Lion" />
                <hkt:mapping attribute="type" match="harb" value="Harbor Seal" />
            </hkt:AttributeMappings>
            <atom:link href="@href_link" title="@name" />
            <description><![CDATA[
                <table>
                    <tr>
                        <td>Common Name:</td>
                        <td>$[name]</td>
                    </tr>
                    <tr>
                        <td>Scientific Name:</td>
                        <td>$[sci_name]</td>
                    </tr>
                    <!-- ...etc -->
                </table>
            ]]></description>
        </hkt:Placemarks>
    </Document>
</kml>
Powered by Google Project Hosting