Matt Croydon::Postneo

Over the weekend I’ve been working on a Python for Series 60 project that I thought up a few days ago while exchanging information with Gustaf between Google Earth instances. It really should have hit me when Google Sightseeing packed its sights in to a KML file, but what can I say, I’m a little slow.

After sending a .kml file via email to Gustaf, I decided to take a look at what exactly made up a .kml file. I started to drool a little bit when I read the KML documentation. The first example is extremely simple yet there’s a lot of power behind it. A few lines of XML can tell Google Earth exactly where to look and what to look at.

Proof of Concept

With this simple example in mind, I started to prototype out a proof of concept style Python app for my phone. Right now everything is handled in a popup dialog, and for the time being I’m just going to save a .kml file and let you do with it as you please, but over the next few days I plan to re-implement the app with an appuifw.Form, get latitude and longitude information from Bluetooth GPS (if you’re so lucky), and work on smtplib integration so that the app can go from location -> write KML -> send via smtplib.

Rapid Mobile Development

When I say that I’ve been working on this app over the weekend, that’s not strictly accurate. I prototyped the proof of concept over about 20-30 minutes on Friday night using the Python for Series 60 compatability library from the wonderful folks at PDIS. I then spent the rest of some free time over the weekend abstracting out the KML bits and reverting my lofty smtplib goals to saving to a local file on the phone. I’m not sure if the problem is due to my limited T-Mobile access or if I need to patch smtplib in order to use it on my phone.

There’s also one big downside to trying to use smtplib on the phone, and that’s the fact that smtplib (and gobs of dependent modules) aren’t distributed with the official Nokia PyS60 distribution, so if I’m going to distribute this app with smtplib functionality, I’ll have to package up a dozen or two library modules to go with it. I’m going to mull it over for a few days and see if I can get past my smtplib bug or investigate alternatives.

from kml import Placemark

I’ve started a rudimentary Python kml library designed with the Series 60 target in mind. It’s rather simplistic, and so far I’ve only implemented the simplest of Placemarks, but I plan to add to it as the need arises. It should be quite usable to generate your own KML Placemark. Here’s a quick usage example:

>>> from kml import Placemark
>>> p=Placemark(39.28419, -76.62169, 
"The O's Play Here!", "Oriole Park at Camden Yards")
>>> print p.to_string()
<kml xmlns="http://earth.google.com/kml/2.0">
<Placemark>
  <description>The O's Play Here!</description>
  <LookAt>
    <longitude>-76.62169</longitude>
    <latitude>39.28419</latitude>
    <range>600</range>
    <tilt>0</tilt>
    <heading>0</heading>
  </LookAt>
  <Point>
    <coordinates>-76.62169,39.28419</coordinates>
  </Point>
</Placemark>
</kml>

Once I have my Placemark object, saving to disk is cake:

>>> f=open("camdenyards.kml", "w")
>>> f.write(p.to_string())
>>> f.close()

If you have Google Earth installed, a simple double click should bring you to Camden Yards in Baltimore. The simplicity of it and the “just works” factor intrigue me, not the fact that this can be accomplished in a few dozen lines of python but the fact that KML seems so well suited for geographic data interchange.

It’s About Interchange

If you are really in to geographic data, and I mean so at an academic or scientific level, KML probably isn’t the format for you. You might be more interested in the Open Geospatial Consortium’s GML (Geography Markup Language). It looks like it does a great job at what it does, but I’m thinking that the killer format is aimed more at the casual user. KML is just that. From a simple Placemark describing a dot on a map to complicated imagery overlays, KML has your back covered. I find the documentation satisfying and straighforward, though I’m no expert on standards.

In the very near future conveying where you are or what you are talking about in a standard way is going to be extremely important. Right now there’s only one major consumer of .kml files and that’s Google Earth. Expect that to change rapidly as people realize how easy it is to produce and consume geodata using KML and .kmz files (which are compressed .kml files that may also include custom imagery).

I would love to see “proper” KML generators and consumers, written with XML toolkits instead of throwing numbers and strings around in Python. I would love to have a GPS-enabled phone spitting out KML using JSR-179, the Location API for J2ME. I hope to use Python for Series 60 to further prototype an application that uses a Bluetooth GPS receiver for location information and allow easy sharing of geodata using KML.

The Code

If you’d like, take a look at the current state my kml Python library, which is extremely simple and naive, but it allows me to generate markup on either my laptop or N-Gage that Google Earth is happy to properly parse. A proof of concept wrapper around this library can be found here. I hope to expand both in the coming days, and I hope to soon have the smtplib-based code working properly on my phone with my carrier.

Update: Oops, forgot to add the <name/> tag. Fixed. The name should now replace the (ugly) filename for your Placemark.