On Mon, Mar 5, 2012 at 10:58 PM, Michael Daines <[email protected]> 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 [1]. 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[0] (supposedly being integrated with the "Rails port"), Changepipe[1], 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. -Josh [0]: http://wiki.openstreetmap.org/wiki/OWL_%28OpenStreetMap_Watch_List%29 [1]: https://github.com/migurski/Changepipe _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
