[OSM-dev] Possible GSoC project: tag/area monitoring service
penorman at mac.com
Wed Mar 7 05:29:05 GMT 2012
> From: Michael Daines [mailto:michael at mdaines.com]
> Sent: Tuesday, March 06, 2012 8:12 PM
> To: Serge Wroclawski
> Cc: dev at openstreetmap.org
> Subject: Re: [OSM-dev] Possible GSoC project: tag/area monitoring
> > 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.
> This was actually part of my original motivation for proposing this
> project -- in my 2010 GSoC project, I used bbox queries to load data in
> tile-like sections, but as I mentioned this turned out to be very slow.
> Data tiles seem like they could speed things up for that sort of use.
> Ideally, the work involved in accessing a data tile would be comparable
> to accessing an image tile. Also, it seems easier to cache data
> addressed by tile than it is to cache the results of arbitrary bbox
> I'd also be interested in working on data tiles -- is that in itself a
> reasonable project idea? My hope is that if either of these ideas are
> things people have been wanting for a while, they'll want to use them,
> and that if a project has people using it, it would be more likely to be
> around after the summer.
> One thing I was wondering about -- how do you choose a tile size to
> minimize both the number of accesses (larger tiles) and the byte size of
> tiles (smaller tiles)? Some areas have a much higher density of data
> than others. Perhaps some kind of quadtree-type approach could be used,
> where tiles are split if they have high density?
CanVec uses this approach. There are large tiles, which when they exceed a
certain size get split into four smaller ones, and this is repeated until
each tile is below the maximum.
For example, 092G07 is an area near me. Being in a city, it's fairly dense
so it is broken into 092G07.0, .1, .2 and .3 which are lower left and go
clockwise. .1 is a particularly dense area so it is broken down into .1.0,
.1.1, .1.2 and .1.3. .1.3 is then further broken down into .1.3.0, .1.3.1,
.1.3.2, .1.3.3. (the actual details of that area differ, it was just an
If I were implementing a data tile API I'd make it deliver tiles broken down
into 1 degree x 1 degree tiles, and then broken down further as necessary.
I'm not sure what the optimum size is, but this could be changed without
impacting clients. I'd then have another query that can tell me what tiles
intersect a bbox, so the client can request the list of tiles they need,
request the tiles, and join them client side.
Each tile would be equivalent to the results of a map? Query and include
parts of ways that extend outside the bbox. This differs from CanVec where
ways end at the edges.
More information about the dev