Though it can be hard enthusing colleagues about open government data, and though I have but a week left in my current gig, I have often found that I can expose data, just sort of incidentally, going about the pretty stuff I'm meant to be producing. I think that's because my little web apps tend to be data-centric, and that opens possibilities.
Dated implementation
I've done a few of these hard-to-configure calendars in the last few years. The calendar's data admin was never properly completed because of time, technical infrastructure (reducing the pool of solutions), and the existence of a manual workaround for it. Even so, both the front end and the system architecture are sound. The calendar uses an atom feed as its primary data source, transformed XForms for its registration and search, and SKOS for the simplistic tagging which drives much of its exploration.
Geography … for a piece of pie
I've never been fussed on using "regions" to describe locations. Whose regions? Where are the borders? What if I'm nearer to events in the neighbouring region than my own? (Geographic note: Queensland has 1,730,648 km2 of land [1] with very little well-socialised subdivision below that.) I like to show where adding metadata can pay dividends for users. I decided to add GeoRSS to the feeds and show where that could take me.
Actually I haven't found an app that directly utilises GeoRSS. Not that I actively looked for one, but it might have been nifty. There probably is a Firefox extension or something. I asked a colleague to check if Google Reader does anything interesting. Surprisingly not.
I realised there were two possibilities that would be visible to web users and therefore not too complicated to explain conceptually. For the first, I can simply generate a Google Maps pin permalink by transforming the co-ordinates. It's a link I can simply anchor to the address field display on individual events. Then, since I was interested in a usable geographic download, I realised Google Maps can overlay a KML file passed in a GET method form, and therefore a URL. And of course KML is just a transform away from my geoRSS-infused events feed, right?
String theory and nodality
Well, curb your enthusiasm right there. It was an easy transform made infinitely harder by outarageously poor XML content modelling. Lat and long – two different nodes, right? Except that the spec favours easy human serialisation, not parsing. Yep, for points, lat and long are space separated in a text node. You, dear consumer, write the parser. It gets worse for lines and areas, but let's not go there. (And imagine the validation opportunities lost!) So yes, a lot of unnecessary parsing later and I have my KML.
The cookie crumbles
I used Mapki's adequate lat/long tool in combination with the Google Maps text search box. Google's pretty weak on things like park names, so I soon felt the need to provide vague pointers to areas or street lines. Lines had highlighting of sorts, but I couldn't attach pins to make them more noticeable. Areas didn't render. So, let's score that as partial support of KML in Google Maps. The solution I came up with was to mark points as approximated. GeoRSS gave me nothing here, so I used a special (gulp) string in xs:documentation/xs:appInfo. I probably could have borrowed one of the metadata qualitaty elements from ISO19115, I guess. The transform simply added an emphasised warning to the description balloon of the marker ‒so rendering on selection ‒ that the location is approximate.
Something the Google Maps KML rendering doesn't seem to allow in its API is opening a specific marker's description balloon, which might have been nice for pointing to a specific highlighted event while also showing the context of surrounding event pins.
Creating a custom icon for the pin was fun, but we discovered the "highlight" pins didn't work as documented. Our hope was to make the pin dance on hover for the kidz. Oh well.
It's the data, stupid
The KML is of course available for download in to consumer devices. I'd like to have looked at alternate waypoint formats like GPX, and also some binary formats of popular sat-nav devices, but time was against me.
And why, oh why, didn't I use Openstreetmap, my passion, and/or an embedded an OpenLayers rendering? While OSM data is generally more current and comprehensive in areas where mappers have applied their loving hands, it's spread is unfortunately limited. Most noticably, rural towns are generally not mapped at all. OpenLayers is a lovely powerful map navigation widget that supports any number of map sources. However, a Google Maps API key is still required to render their data, and those are not free to government websites. A sinister benefit of linking to external maps, too, is that we neatly absolve ourselves of accusations of inaccessibility. Not something I feel great about, but at least the data is available in a raw format. I don't know anything more accessible for maps.
I know that had I been able to use OSM and OpenLayers, my catalogue of limitations could become bug reports and it would be completely within my power to progress their solution. Isn't that a better way of working?