[OSM-dev] Possible GSoC project: tag/area monitoring service

Peter Körner osm-lists at mazdermind.de
Wed Mar 7 09:57:11 GMT 2012

Am 07.03.2012 05:11, schrieb Michael Daines:
>> 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 queries.
> 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.

A Service that is able to provide
1. fast and scalable
2. tiled access to
3. updated data
4. around the world with a constant tile size (eg z12 or z14)
5. together with formulars to calculate the tile coordinate from
    lat/lon and
6. complete documentation

would be project of reasonable complexity and usefulness.
The most complex part here is 3.
If you have further questions on possible implementations or use-cases 
don't hesitate to contact me directly: peter at mazdermind.de

> 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?
This could be a Project for the next GSoC, but calculating the tile 
sizes is in itsself so complex, that it would fill a complete 
GSoC-Project, leaving no room for the project outlined above. But a 
Tiling-Algorithm without a service implementing it would not be of great 
use for the community, would it?

Despite that there are already tools that are dedicated to this kind of 
computation: http://www.mkgmap.org.uk/page/tile-splitter

> The ideas you suggest for streaming-type updates on data tiles are very interesting. If you were writing an editor, you could be more certain that you were displaying the most recent data without having to reload all of it.
But you would not want the editor to display those changes without user 
interaction. Imagine you are drawing a road and around your cursor 
everything changes shapes the whole time. You would not call this a good 
user experience, would you?

Also a streaming editor is nothing the community is requesting, editing 
works good (enough) the way it is.


More information about the dev mailing list