Introduction : What is KML
What aspects of KML are relevant for two-dimensional maps?
KML was originally developed for three-dimensional Earth viewers, therefore only a subset of KML is strictly relevant to two-dimensional maps. Fortunately this also covers a high percentage of 2d-mapping use cases.
KML is able to:
- Specify icons and labels to identify locations.
- Specify additional information (e.g. address, phone number) to associate with a specific location.
- Define other elements such as polygons and polylines and attach them to the map.
- Define styles to specify feature appearance.
- Write HTML descriptions of features, including hyperlinks and embedded images
- Use folders for hierarchical grouping of features
Comparison between Nokia Map elements and the KML syntax
A MapMarker is a KML <Placemark> with a <Point> geometry and an <IconStyle>
|Nokia Map||KML Syntax|
marker = new nokia.maps.map.Marker(
As can be seen, there is a one-to-one correspondence between the Marker attributes and the KML <Point> attributes. The coordinates of the marker are specified in the <coordinates> tag, although longitude and latitude are reversed, and altitude is added. Since altitude is irrelevant for a two-dimensional map, a placeholder of zero can be used. The icon of the marker is defined by the <href> tag. The anchor of the marker is specified in the <hotSpot> tag, with the Point offsets held in the x and y attributes. Note that <hotSpot> can be defined in three different ways, correspond directly,the xunit atttibute and the yunit attribute must be set to "pixels"
Map Standard Marker
A Map StandardMarker can be defined as KML <Placemark> with a <Point> geometry and a <styleUrl>
|Nokia Map||KML Syntax|
KML does not have the concept of a StandardMarker. If a <Point> is defined without styling, it is up to the rendering library to decide what icon to use on the marker. Obviously if HERE Maps is used, the <Point> will default to the Nokia StandardMarker. Nokia's StandardMarker has a brush attribute which changes the color of the marker. This cannot be replicated directly in KML. However, it is possible to approximate this using a KML <Style>.
Firstly we need to create custom icons for the various default RGB colors:
Thereafter, we can use the <styleURL> element of the <PlaceMark> to render the <Point> using the icon defined in the <Style> Marker.
An Infobubble can be defined as KML <Placemark> with a <description> tag
The <description> tag is defined as being "User-supplied content that appears in the description balloon". As such it is analogous to the Nokia Map Infobubble. The usual way to create an InfoBubble is to associate additional data with the marker (in this case by adding an .html attribute) and then displaying the info bubble by adding an onclick event.
Many KML feeds make the assumption that the consumer of the KML file will render HTML, and therefore place HTML tags directly in the description - this could be avoided by using KML placeholders and creating a <BalloonStyle>, but this is beyond the scope of this article.
A Polyline can be defined as KML <Placemark> with a <LineString> geometry and a <LineStyle>
Again there is a one-to-one correspondence between the Polyline attributes and the KML <LineString> attributes. The coordinates of the route are specified in the <coordinates> tag, although longitude and latitude are reversed, and altitude is added - this can be left as a placeholder of zero if desired. The lineWidth of the route is defined by the <width> tag. Similarly the the strokeColor of the route corresponds to the <color> tag. There is however a difference in the encoding here, as HERE Maps uses RGB encoding, and the KML standard uses ABGR encoding, so the first two bytes define the opacity (which can be defaulted to FF) and the red and blue ordering is reversed.
Nokia Map data is stored in map.objects - it is a relatively simple matter to traverse the markers and obtain the necessary data to create KML <Point>s. Note that since the additional data element for the pop-up description is arbitrary, the .html attribute in this example may need to be altered to cope with other maps.
var markerData = new Object();
var lineData = new Object();
The collected data may then be written out as KML <Placemark>s using the method below:
var kmlOutput = "<?xml version='1.0' encoding='UTF-8'?><kml xmlns='http://www.opengis.net/kml/2.2'><Document>\n";
Working Example : Premiership Teams
The attached coded example - Media:Premiership.zip - contains three versions of the same map:
Each file also contains standard timing code, to display the length of time taken to load the map. Obviously the rate at which map data is generated on screen will depend upon a variety of factors such as the performance of the browser and the load of the Internet at the time of test. For the attached coded example, the following metric was generated for three runs of the maps using the same browser. In all cases, the cache was not cleared for each run.
The obvious conclusion to be drawn, is that using a KML file should increase the performance of the rendering of the map.
Since KML is a de facto standard, the same data file can be used by multiple applications. Most major search engines, such as Google, Bing and Ask are able to crawl KML files if the website contains an appropriate sitemap.xml file. For full details of the protocol, please read the definitions on: http://www.sitemaps.org/
Example Sitemap.xml File
Additionally since KML is merely a subset of XML, Java ME mobile phone applications can read the same data using JSR-172. The screen shot below shows the same KML file embedded in a KML Reader running in the Java ME emulator:
Converting to KML format is relatively simple, and the process can be automated. The benefits of using KML format include faster rendering and the separation of mapping data from the code. Use of a standard format promotes cross-application use of the same data, and allows faster development of mapping applications across multiple platforms.