[OSM-dev] Possible GSoC project: tag/area monitoring service

Serge Wroclawski emacsen at gmail.com
Tue Mar 6 21:02:14 GMT 2012

On Tue, Mar 6, 2012 at 2:10 PM, Michael Daines <michael at mdaines.com> wrote:

> I'm curious to hear which of these approaches would be useful to people interested in this sort of thing. It seems like being able to ask for RSS feeds would be more immediately useful, but having data "pushed" to clients would allow for more flexible applications.

If you want to make this really generally useful, then here's the
approach *I'd* personally take (and will if ever I get the time to get
back to it).

First, a longstanding wishlist item for OSM has been "data tiles",
that is the API data, split into preset sized areas (eg z14), which a
client could call. This may not seem reelvant to your project but
you'll see why it is soon.

Secondly, I've wanted to add comet-like functionality for an API call.
This is similar to your suggestion of a streaming API. Whether it's
comet, or websockets or a pure streaming API is detail, but the idea
is that when you ask for an area, you'd get the current area, plus any
updates to the area as you stay connected.

While you could use Changepipe to make arbitrary polygons and then
stream the changes, IMHO this is not as generally useful as one might
imagine. Network hiccups alone can mean that it's possible to miss an
event. And arbitrary polygons become "complicated" as the number of
queues can be large.

By splitting the areas up, you can now take a changeset and know which
areas (tile) it effects. And then each client can simply subscribe to
an area (tile). You've greatly simplified the problem, whether you
allow for arbitrary shapes (one shape -> many tiles) or 1:1 tiles to

Now, to your original question... Another advantage of "tiling" the
data is you can easily do both. Each tile can have a list of changes
associated with it. If you tried to do this on arbitrary polygons,
it'd get difficult very quickly.

- Serge

More information about the dev mailing list