overview

The Locator project takes location input from the FindMeSpot system, updates your blog, adds a record to your GIS database, creates an XML dump of your recent locations and updates your website accordingly.

There are many parts that work together to provide this end-to-end solution and I'll elaborate on all of them here. I put this project together for my personal use. I don't really care if it doesn't fit your particular needs.

Enjoy.

postgres

import.pl, cities.txt, locator.sql, launchd.plist

PostgreSQL is an excellent database. When combined with PostGIS, it becomes particularly useful. Presently, the latest version of Postgres is 8.4, however the pre-compiled Postgis binaries for Mac OS X only support 8.3, and I haven't gotten around to compiling it myself. So, if you're new to Postgres, make sure you get the latest version of the 8.3.x series (unless you intend to compile PostGIS yourself).

The database schema, user role, custom data types and stored procedures are all defined in locator.sql which can be run with psql. Alternatively, can connect to the database with pgAdmin3 and run it it in the SQL window. Hopefully it'll all work. I haven't actually tested its combined-into-one-file form that is linked above.

A significant appeal to this system is that of defining interesting points. If I am planning a trip I will enter in relevant cities, airports, mountain peaks, etc., such that meaningful names can be associated with each location event instead of just a longitude/latitude. Using the cities.txt and import.pl files above, you can pre-load your database with a bunch of cities. Beyond that you're on your own. I don't know the longitude/latitude of your mom's house, so you're going to have to enter that yourself.

After you have some location event data in your database, you can retrieve the last 10 (for instance) location events using the stored procedure by doing: SELECT * FROM tracklog_get(10);. This doesn't actually help you at all. It's just an FYI.

Finally, you're going to want Postgres to automatically start when your computer boots, and to accomplish that, plase the launchd plist file into /Library/LaunchDaemons/.

apache

htaccess.txt

I wanted to be able to go to http://whereiscurtis.com; not /tracklog.xml, and to that end I placed a .htaccess file in the root html directory for the web site which sets the directory index such that index-implicit requests receive the aforementioned XML file instead of the typical index.html.

cron

agent.plist

In Mac OS X the a cron job can be scheduled by placing a plist file in /Library/LaunchAgents/. The file linked to above specifies the full path to the shell script which starts the Perl script and directs various bits of debugging information to a log file. It is scheduled to run every sixty seconds.

Run launchctl load /Library/LaunchAgents/com.yourdomain.Locator.agent.plist in Terminal.app when you're ready to start everything.

scripts

locator.pl, locator.sh

The cron system starts locator.sh which starts locator.pl ... which is where all the magic lies.

First, we look at our history directory to find the most recent email that we processed. We want any location-related emails that arrived after that point. Then we connect to the IMAP mail server and look in the specified mailboxes for any email with subjects and dates that match our criteria. Each such email is retrieved, stored and processed.

To process a new location email, we first parse it to get all of the location information that we're interested in (longitude, latitude, date/time, etc.) and we add it to the tracklog table in the database.

Next we retrieve the ten most recent location events from the tracklog table and dump them out as XML. This XML file is then SFTP'ed to the webserver for the world to see. Or whomever.

Finally, we authenticate with and then post to a blogger.com blog (if you have one).

xml and xslt

tracklog.xml, tracklog.xsl

Viewing an XML file of tracklog events in your web browser is something less than exciting. And that's where XSL comes in. The XML file specifies the path to the XSL file which transforms the XML into the beautiful (yet simple) web page you see here: whereiscurtis.com, including the code necessary to feed location information to the emebedded Google Maps layer.

XSL is horrible and ugly, but it does come in handy from time to time. You have my sympathy if your employment requires regular use of it. The alternative is to programmatically generate the entire HTML page, and that's even uglier.

google maps

The XSL file uses the new v3 of the Google Maps API, which apparently is different from v2, although I don't really understand the effective difference since I've spent in total about ten minutes using each them. One difference I am aware of is that the use of a key is no longer necessary. If you've never worked with Google Maps, however, that statement probably doesn't mean anything to you.

The XSL creates a link for each location event that calls a JavaScript function which re-centers the map on the location corresponding to the event. This is cool.

To make the page look just the way you want it to, dig through the XSL file and change it accordingly.

epilogue

The only supported location event input method is FindMeSpot notification emails. That's useful for me when it comes to mountain climbing trips, but its of limited usefulness (even for me) the rest of the time. So, I'll eventually get around to writing an iPhone app, which would also support adding new points-of-interest, attaching photos and providing text comments. One day.

More likely is that I'll be inspired to write an app for an Apple Tablet (if it ever comes into being).