[OSM-dev] Possible GSoC project: tag/area monitoring service
michael at mdaines.com
Thu Mar 8 01:34:21 GMT 2012
> Write some code to query jaxpi for bounding boxes in Python based on tile name.
> Use this and write "Data tile" support in TileStache. I'd store cached
> tiles in Redis (for reasons that become apparent in a few sentences).
> I'd use the parsing/storing bits of Changepipe to tell me which tiles
> are effected by a changeset (even though I believe it uses the
> changeset's bbox, which is oftentimes wrong).
> Since Changepipe is already using Redis, using Redis for the tiles makes sense.
> And then the issue would be how to hack in some code for the
> websocket/stream/whatever. This seems like it'd be relatively simple
> using Redis pubsub and something like gevent, but I haven't looked
> into it.
Do I have this right: the server in this implementation would act as sort of a fast, tile-addressed cache for data available through XAPI or similar?
> The right answer would be to keep a local copy of the database and
> then update it as necessary. I believe Ian Dees has a copy of some
> MongoDB code that uses quadtile to index OSM objects (I'm very fuzzy
> on the details). (Update, Ian sent me this url, but I haven't taken a
> look: https://github.com/iandees/mongosm/commit/c46c2081edde0b3b2b0446dd06d5ef02b292631c
> Then as objects would change, you'd be able to update the tiles.
It looks like mongosm includes an implementation of a data tile server? The quadtile indexing is interesting in that you use only a single parameter to refer to tiles, rather than the z/x/y triple commonly used with image tiles.
Keeping a local copy seems simpler and more reliable, but you have to store all the data... This is where I see some kind of customization as being useful -- if you were running your own server, and were only interested in a single city, or only interested in roads and building shapes, you could store just that data.
>> Perhaps some kind of quadtree-type approach could be used, where tiles are split if they have high density?
> That'd certainly work. I'd started with a naive approach of "If I only
> have one zoom level, things are easy", and then you just accept that
> some areas are dense, and others not. At the same time, there won't be
> as much demand for low density areas.
> There's certainly value in cleverness and not transmitting too much
> data, but there's also value in simplicity for clients.
Particularly for GSoC I think I'd want to err on the side of simplicity. The zoom level could always be adjusted?
More information about the dev