tile cacheing

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

tile cacheing

Simon Hewison
Here's a thought:

if, as Steve said, the tiles are cached on the tile server for 48 hours,
then that means that even parts of the world that haven't changed still
end up with their cached tiles invalidated, and all the processing
required to re-generate them (and harassing the landsat server) happens
again.

It's clear within the database what parts of the planet have had new
line segments or nodes on them since they were generated, so rather than
just having a simple http cache expiry, when it does expire, it could go
off to the database and look to see if there's any alteration to the
bounding box covered by the tile since it was last generated. If so, it
would keep the same image cached for a futher 48 hours, or whatever. In
fact, if the database check is lightweight enough, the expiry time could
be a several minutes, rather than hours/days.

I'm not sure that the current API supports this (has anything in this
bounding box changed since time T) query, but it could be of huge benefit.

--
Simon Hewison

_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
Reply | Threaded
Open this post in threaded view
|

Re: tile cacheing

Steve Coast
I was thinking of the opposite. We use squid for caching and there are
some fairly powerful tools for removing things from the cache, so a cron
job could wake up every ten minutes and look for whats changed in the
database and kill the tiles in the cache that contain those changes.

First I want to replace mapserver and speed up tile generation and only
render streets if the zoom level is sufficient...

* @ 20/10/05 10:10:34 AM [hidden email] wrote:

> Here's a thought:
>
> if, as Steve said, the tiles are cached on the tile server for 48 hours,
> then that means that even parts of the world that haven't changed still
> end up with their cached tiles invalidated, and all the processing
> required to re-generate them (and harassing the landsat server) happens
> again.
>
> It's clear within the database what parts of the planet have had new
> line segments or nodes on them since they were generated, so rather than
> just having a simple http cache expiry, when it does expire, it could go
> off to the database and look to see if there's any alteration to the
> bounding box covered by the tile since it was last generated. If so, it
> would keep the same image cached for a futher 48 hours, or whatever. In
> fact, if the database check is lightweight enough, the expiry time could
> be a several minutes, rather than hours/days.
>
> I'm not sure that the current API supports this (has anything in this
> bounding box changed since time T) query, but it could be of huge benefit.
>
> --
> Simon Hewison
>
> _______________________________________________
> Openstreetmap mailing list
> [hidden email]
> http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap

have fun,

SteveC [hidden email] http://www.asklater.com/steve/

_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
Reply | Threaded
Open this post in threaded view
|

Re: tile cacheing

Simon Hewison
SteveC wrote:
> I was thinking of the opposite. We use squid for caching and there are
> some fairly powerful tools for removing things from the cache, so a cron
> job could wake up every ten minutes and look for whats changed in the
> database and kill the tiles in the cache that contain those changes.

That would work too. However, you wouldn't want to set the HTTP expiry
time too far in advance, else client side caching (which you have no
control over cache invalidation) would take over, and clients wouldn't
see updated tiles without flushing their cache.

> First I want to replace mapserver and speed up tile generation and only
> render streets if the zoom level is sufficient...

"Sufficient".. I think we really need the tag/value stuff to determine
how "important" a given street is at a given zoom level.

eg. Display motorways when zoomed out to approximately country level,
then dual carriageways, then main roads, residential streets, country
lanes, paths etc.

--
Simon Hewison

_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap