On Tue, Mar 6, 2012 at 2:10 PM, Michael Daines <mich...@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 connections. 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 _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev