Geodaki

­I think there is a new project that we could take on that would require very little effort to get going. It would build directly on a lot of our preexisting work and integrate the technology and talents distributed throughout all of TOPP. In the short term, it would galvanize political change. In the medium term, it would be a steady revenue stream for TOPP. In the long term, it would be a crucial first step to the Open Geo Web.

Got your attention?

Why I am writing this

Recently, new TOPP hire and OpenLayers hacker Andreas Hocevar has been asking around about how we can pitch the technologies Livable Streets is using to Graz, a city in Austria that has recently come under the control of the Green Party. One thing Andreas wanted was to back up his pitch with a success story–an example of where our technology has produced real change in an urban community.

Nick responded that we didn’t have a lot of good stories on this yet. But he brought up Uncivil Servants as “by far our most successful effort to date.” It took a single important issue–”city officials abusing their city-issued parking permits”–and provided a simple but powerful solution: “On the website, concerned citizens can post photos and details of illegally parked cars using fraudulent or improper city-issued permits. These violations are mapped and tracked by city agency on the site.”

Andreas’ reaction was telling:

Well _this_ is perfect! Although this “negative” approach is kind of rude, it is something that attracts attention. A similar initiative was launched in Austria a year ago to achieve more severe punishments for not using dog poop bags, but with a less sophisticated frontend: http://www.hundsdreck.at/. This is an interactive map where users can report sightings of dog poop. Also, the small flags shown on the pictures can be ordered via the site, and those flags should be attached before taking a picture :-). This initiative was very successful.

You should go to this website, now. It will not disappoint.

Later that day, I was invited along by Nick to a meeting with Transportation Alternatives about the future of Uncivil Servants as the token “mapping guy.” On the way back, I had a fruitful conversation with Nick, and he asked me to write a blog post about it. Here it is.

A common thread

What do Uncivil Servants and Hundsdreck (and MyBikeLane (http://nyc.mybikelane.com/), on which Uncivil Servants is based) have in common?

The model is simple. There is a category of events in the world that bothers some people. When they see that event, they submit a form that contains information about the event, a photo, important related data, and the location where they saw it. That data is then pooled together and displayed to users to show that they are not alone and prove that the problem is pervasive. The data can viewed either as a “blog” or on a map, filtered in interesting ways.

Here are the two main insights I want to focus on. First, the content being produced by these sites are not documents or conversations (pace k0s), but data. In particular, it is geospatial data–meaning, it is data that has a geometry (latitude/longitude, or more complicated shapes like lines and polygons) associated with it.

Second, it has a very technologically light-weight front-end. Data is submitted with a full page web form. The front page of Uncivil Servants is just a feed with some sidebars. The map view, with the filters on the data, is what Nick described to me yesterday as “Web Application 101.” Or maybe it was 1.0.

Apparently, these sorts of sites are wildly effective. Wouldn’t it be great if we could roll these out really, really easily? In just the past couple of days, I’ve had conversations that brought up these other possible uses of virtually identical technology:

• At the Grassroots 2.0 meetup last night, I spoke with the communications director of the NYCLU–the New York chapter of the ACLU. She has seen Uncivil Servants and is excited about using “mapping stuff” to make the NYCLU website more interesting and promote their causes. One idea she has pitched to me is a site, much like Uncivil Servants, where people could post photos of security cameras they find throughout New York City. This would let people know how much they are under surveillance every day, and turn the panopticon back on itself.
• I talked today with a friend who works for FireRescue, a website for firefighters about firefighting news. She was complaining about how their website was still very Old Media, and was curious about ways to make their website more interactive. She thought that even something as simple as a place where people could post where there had been fires and who had been involved in putting them out, with the ability to see a map of it all, would get a lot of interest.

But think about all the technical hurdles we would have to overcome. I mean, to do this right we would need an intelligent server for geospatial data for one. Building on would be a substantial open source project in itself, requiring years of work. And what if people want to be to publish feeds, or authenticate users, or–God forbid–versioning? What a headache. And then, we would need to build a dynamic website that could talk to it. Sheesh–to do that, we’d probably have to find somebody who knows one of these web application frameworks. I heard Uncivil Servants was written in Ruby on Rails–nobody here knows Ruby, right? Do any of us know anything that’s close? But maybe, just maybe, the things we need are hiding somewhere, right under our noses.

Jump starting the Open Geo Web

My impression is that many of you are unfamiliar with the Grand Vision Cholmes has laid out for OpenGeo. I’d recommend checking out his slides from Trinidad if you haven’t already.

As I understand it, the culminating point of this vision is the Open Geo Web–a space of user-contributed, legally open and technologically available geospatial data, used by an active community using graceful web tools.

The technology for this very ideal is on the pipeline–check out the requirements for the Community Almanac Tim Schaub will be building soon for the Orton Foundation, and the GeoServer configuration roadmap Cholmes recently blogged about.

But there appear to be bottlenecks. One significant bottleneck is that we’ve been thinking of doing the front end for this sort of thing through a mapping application, which means doing a lot of JavaScript work extending OpenLayers (e.g. Vespucci).

There’s no reason why we couldn’t move away from the visualized map on this, though. For highly structured data with a lot of fields–such as that used by Uncivil Servants–adding features to a map through a popup doesn’t actually make as much sense as doing it through a spatious, full-page web form. When that aspect and most of the dynamic parts of the site get pushed out of the map and into the normal HTML, my understanding is that the JavaScript needs here become much easier, and a lot of the work can be done by a strong web app framework, like Pylons. And right now I am sitting in a room full of people who have a lot of Pylons experience. (Admittedly, I know hardly anything about web development in Pylons, but after seeing a lot of demos and hearing a lot of discussion, it sounds like the requirements for this sort of application would be provided for almost out of the box, assuming the backend were being handled by GeoServer and communication between the two was in one of the many open standards GeoServer supports). Somebody please correct me if I’m wrong on that.)

So this is a paradigm for a technically easy solution to some important problems that results in the collaborative, participatory creation of structured GeoSpatial data. The mapping needs per se are rather light–OpenLayers trunk can handle it all–and there is only a single layer of data (at least in the simplest implementation of this idea). If anything, it under uses the power of the OpenGeo tools we have at our fingertips. But with GeoServer as a backend, all that data can be republished to a “real GIS,” or richer Open Geo Web technologies that we develop again down the line. And in the meantime, the experience of real lightweight applications built along these lines proves that this sort of technology can produce real change fast.

Moola and more

It’s one thing to be able to build a software stack that we could custom fit to various organization’s needs–something which it seems to me would take very little work. And it could be that having this sort of technology at our finger tips could quickly become a source of revenue for TOPP–we could contract out setting up a site along the ones of those described above, giving each site a custom skin and some extra features (sidebars, news feeds) as appropriate. Already at this point it has potential as a sustainable open source project. But there’s much, much more we could do with this.

First, some background. Something Cholmes has mentioned to me several times before is his dream of having a hosted GeoServer service underpinning the Open Geo Web. Fully consistent and in parallel with the hippy ideal of the geospatial commons is a business model that has proven lucrative in the case of Wordpress.com, according to which a large offering of services are provided for free, but users have the option of paying for extras if they want to, for example, restyle their site or have more space to store files.

A natural medium term step for the project I’m suggesting would be a hosted web service with precisely this business model.

There are significant things we could gain from trying this out:

• Because the actual application is so constrained–a single layer of geospatial data to start, and just a few different lightweight ways of viewing that data, maybe with a few more features–the range of options that each individual user would need would be much sparser than we exposed the full power of GeoServer right off the bat. So it would be much easier to get this out the door quickly.
• It would be a good test of the business model in the geospatial data domain, where I don’t believe it’s been applied before.
• It could pull in revenue sooner rather than later, which we could reinvest in OpenGeo, OpenPlans, and other TOPP projects.
• It could do a lot of real good in the world.
• It would be natural to grow this sort of service out into the more powerful sort of service envisioned by Cholmes.
• It would allow us to provide this power for organizations that are more willing to take heat than we are as an organization. Nick told me yesterday that the reason why TOPP doesn’t have its name on Uncivil Servants, despite our involvement in it, is that it was deemed too controversial for us to handle. But then it got a lot done. As Andreas said, “Although this “negative” approach is kind of rude, it is something that attracts attention.” Providing a general web service which others can use can help us distribute the PR liability to people who have more experience handling media relations (like Transportation Alternatives), and will let people with less to lose take bigger risks if they think it will make an impact.

The more I think about this, the more I convince myself that this is a good enough idea to warrant writing this long a blog post about it. We are always looking for low-hanging fruit around here. And lo! I see before us a strong and powerful bull, with its testes hanging low in a very fruit-like way. I humbly propose we consider grabbing them and seeing what happens.

What’s in a name?

I have already spent way too long writing this blog post, but I wanted to end on the note of branding, since if there’s one thing I learned from Vespucci it’s that picking a good name matters.

In our conversation yesterday, Nick and I were perplexed by this problem: what would we call this sort of service? What is it that distinguishes it from other services out there? It seems to be different, to touch a virgin niche, but why?

Here is one answer, which I brought up towards the beginning of this post: there are a lot of services out there that support this sort of thing for documents, like blogs and wikis. But the key difference between these services and the one I’m proposing is that a blog post is, conceptually, a document, whereas the content generated by this sort of service is real data–entries in a table that have a number of fields that mean something about the real world.

Put aside the quibble that blog posts are technically just a kind of data, because I think this distinction may really exist in the minds of users and people at work in the world.

If you grant me this, then roughly speaking this service provides what you could call a data wiki. People can contribute content, maybe people can also change it with certain permissions.

Following the W3C standard of Web 2.0 neologism, the tools at our disposal are concatenation and elision. This goes back to the great “web log” to “blog” shift of days of yore.

So, what are our options? “Data wiki” becomes… “datki”? History tells us that that’s not a consonant cluster that can withstand the test of time. “Dwiki” is ok, but sounds juvenile. Personally, I like “daki,” because it stakes out a currently unused four letter word and reminds me of daiquiris.

Of course, this is no ordinary daki. This is a geodaki.

That’s funny. www.geodaki.org is currently unregistered….

­­