Live KML Generation
Loren M. Lang
but after some thought it occurs to me that what's really needed is just
to be able to create a KML file at will. Switching to a database now
may offer some speed increase and make it easier to manipulate the data,
but will still leave us with the same basic problem, a single KML file
that can't be regenerated with different parameters. What we really
need next is to dynamically create the KML file when needed and this
won't require us to switch to a database yet.
Most of the information that goes into a KML file like Tweets,
Check-ins, Photos, and Status Updates are stored only in the KML file
and can't easily be regenerated. For example, the only connection
between a photo's URL and it's description is that it's included in the
same chunk of HTML that's embedded in a KML description element. I
can't just scan all the photos and regenerate this since I don't record
the title or description anywhere else. Which FourSquare, Twitter, and
RSS, I store a unique identifier in the KML as extra data and I scan the
KML file for these on each update to see if I've already retrieved the
corresponding Tweet/Check-in. Also, FourSquare check-ins use a stylized
icon pulled from the check-in instead of a generic icon like used for
other updates. I would need a way to store this information and
recreate the KML styles for those icons.
Once part of the KML file where I do store nearly everything is path
data. It's used in three areas of the KML, the last location icon,
location placemarks (used to record speed/heading/time along the path),
and the path itself (which is just longitude/latitude/altitude). Most
of this is already stored in the CSV file. The only missing piece of
information is which location placemarks to include. My current
solution is to only create a single placemark each time
updatelocation.pl is run without the -n option (-n means no placemark).
The default crontab does this once every 15 minutes.
I think the simplest approach is to focus first on just recreating the
KML file from a template with new path data, but leave the other scripts
unchanged and will directly modify the template. Opening up the
template will reveal all Photos, Tweets, Check-ins, etc. but have an
empty path and last location. A new script, live.pl, will read in the
template and fill in the path and location data and can output that KML
file directly as a CGI script. This way, that part of the KML file is
only generated when users request it. This is good as it's the most
voluminous part of the file. It will also let me easily create the file
with different parameters like reducing the resolution of GPS data.
Currently, PhotoCatalog for Android generates too much data for Google
Maps to handle in a KML file very quickly. InstaMapper has much tighter
rate limiting.
One feature that a database would add is automatic sorting of the
location data. It would be simple for me to sort locations.csv manually
as a separate script, but the problem with the current system is that
the KML file is created at the same time as importing location data.
Once I have live.pl ready, it will be less critical to have location
data sorted at the time of import. I can then create sort.pl and on the
next run of live.pl, your path data will be correct without requiring a
big rewrite for database support.
--
Loren M. Lang
lor...@north-winds.org
http://www.north-winds.org/
Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc
Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B