[OSM-dev] rendering: mad ideas

Erik Johansson erjohan at gmail.com
Fri Mar 24 13:10:14 GMT 2006


On 3/24/06, Tom Carden <tom at tom-carden.co.uk> wrote:
> Selectively rendering only the tiles which have changed should be top
> priority if we wish to scale.  I thought Mikel was nearly there with
> this, is there a sticking point that anyone can help with?

 I would like to say that the best option would be to have a well
defined tiling scheme where I can download tile=100,200 (or something
in the same geist) which corresponds to the bbx 17.98,59.0,18.25,59.3.
of course the same kind of scheme should be used for the images from
gpx traces, streets and landsat). This would make this alot easier to
handle cacheing issues. I think this is were effort should be
expended, not on solving the current problem.



Solving the current problem?

Well we are using Squid so efforts should be concentrated on how to
keep the images in the cache. You can do this by storing the tiles
forever until purged, or let them invalidate aftersome time and make
squid check if the have been updated.

The latter option is a matter of getting all images generated by OSM
servers know how to handle if-not-modified-since.  I'm not sure
mapserver can handle this, if it can then great.

Back to the first option, it can be done if you at every edit convert
that edit to a list of tiles it affects and remove them from the
cache. A problem is that it has to catch all different types of tiles
that can be affected e.g. traces/streets and all the zoom levels of
that, so at the moment that's at least 10 urls per edit.

To create the list of urls we can use the applet code and the
slippymap code to create a url from all lat/long pair, this is non
trivial and can easily break if code changes. It's also possible to
match the edit against a list of existent tiles (tiles we have already
rendered) that list can be extracted from Squid.

If we have a list of all the tiles that are currently cached, we can
create a large list of those bbx:es and match edits against these and
the invalidate those


I have done
* RSS -> lat long
* squid cache to URL list
* match lat/long to bbx

I haven't tested it yet though...

--
/Erik




More information about the dev mailing list