|
Planning
HKT - for happy kml files
IntroductionBasic ConceptThis 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 DetailsAssumptionsWill be implemented in pythonThe 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 taskI 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 valueAll 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:
Rasters and Superoverlays are well handled by other toolsWe should integrate tools like TileCache and Mapnik/Cascadenik into this workflow. The Case for CSS
Problems it would solve
Placemark {
display: none;
}
Placemark[type=highway], Placemark[type=interstate] {
display: true;
} Placemark {
label: none;
icon-scale: 1.0;
}
Placemark:hover {
label: #fff attr('title');
icon-scale: 1.2;
}Parsing CSS
Tasks
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>
|