> 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? _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
