[OSM-dev] Possible GSoC project: tag/area monitoring service
josh at joshdoe.com
Tue Mar 6 11:17:30 GMT 2012
On Mon, Mar 5, 2012 at 10:58 PM, Michael Daines <michael at mdaines.com> wrote:
> Hi everyone,
> I'm writing to seek opinions about a possible Google Summer of Code project. I did GSoC in 2010, and I'd like to apply again this year. My project in 2010 was a simplified, web-based map editor.
> Since the wiki page for project ideas mentions that proposals for the development of existing OSM infrastructure would be preferred, I was having a look at the API v0.7 page, and noticed some interest in a monitoring feature.
> My proposal is to build a monitoring service to augment the existing API, similar to the Twitter streaming API . Users would request to receive map updates matching tags or which involve elements in some area, and updates would be sent either over a persistent connection (as Twitter does) or possibly by making requests to an endpoint specified by the user. My general idea for the architecture is basically to grab diffs and then send the relevant parts to clients depending on what they've asked to receive.
> Clients of such a monitoring service could do things like send daily email updates on map activity to users interested in a specific area or tag, invalidate tiles in custom-rendered maps, or assemble a subset of available OSM data for fast, up-to-date querying within that subset (a single city, for example) without worrying about making lots of requests to the OSM API. That third application would be useful for solving one of the problems I ran into with my 2010 project -- I was optimistically loading map data with bbox queries as the user panned the map, which was too slow on the production API to be practical (and probably isn't what that part of the API is really meant for).
> Another project idea might be to work directly on a service which would provide fast querying on tag or area subsets. However, the project as I've proposed it above seems to me to be sort of a generalization of that, and also seems like it would require less bandwidth and disk space.
I wouldn't worry about monitoring area changes, as we have OWL
(supposedly being integrated with the "Rails port"), Changepipe,
and possibly others that do this already. I'd suggest you consider
focusing on the idea of monitoring for changes based on tags and
object IDs. I've been interested in changes to some large relations,
and other widely dispersed objects, which isn't addressed by any of
the current tools. Integration with Rails would be great, so we can
"Watch" any object directly from the website. Of course performance
would have to be considered before implementing such a service went
live, but I don't think that's terribly important for a GSoC project.
More information about the dev