This is a static archive of our old OpenStreetMap Help Site. Please post any new questions and answers at community.osm.org.

Tirex: Prefetching of next zoom level

0

Consider a low-loaded tile server.

The actions of the users might be to:

  • pan around
  • zoom in at the current map position

One idea might be to put the tiles in the queue that are next to the current meta tile (8 pieces - but this case might be already covered by the meta-tile technique) and the meta tile in the next zoom level at the current map position.

What is the starting point to implement such kind of pre-rendering in Tirex?

asked 04 Nov '12, 20:38

AddisMap_Alexander's gravatar image

AddisMap_Ale...
1.1k314062
accept rate: 0%

edited 04 Nov '12, 20:38


One Answer:

1

You can not implement this in Tirex alone, because requests to existing tiles are handled by mod-tile and never reach Tirex. So you would have to change mod_tile. You could probably change mod-tile to send low priority rendering requests for the next zoom level in addition to the high priority request for the current zoom level.

But I think this is a bad idea. Chances are you'll do more harm than good. A typical scenario is this: User looks at zoom level n, your setup will calculate tiles for same position at n+1. User pans over a bit and zooms in. All renderers are now blocked with rendering what was requested before and can't render what the user actually wants to look at. Tirex promotes low-priority jobs if a high-priority job for the same tile comes in and it can reserve renderers for high-priority jobs, so maybe it can actually work. But there would still be contention for CPU, database access etc. so I don't believe it would be worth it.

answered 05 Nov '12, 07:57

Jochen%20Topf's gravatar image

Jochen Topf
5.2k55074
accept rate: 31%

edited 05 Nov '12, 13:25

Concerning the scenario: When the user zooms in, I was hoping that this new high-prio renderings are rendered before the queued low-prior renderings.

(05 Nov '12, 08:24) Alex_AddisMap

Yes, if they are only queued. But if they have already started rendering, they keep rendering till they are finished. And your scenario only makes sense if they often start rendering immediately. If they end up sitting in the queue for a long time anyway, why bother with your scheme?

(05 Nov '12, 08:55) Jochen Topf

It could work, but it'd need more smarts :

  • Only schedule if a worker is otherwise idle.
  • Ability to promote the job from low priority to high.

Maybe could be implemented with a low-priority, low-TTL queue ? Remove job from the low queue if it is added in the high queue. And make sure that you have a lot of workers. Not such a low-haging-fruit improvement, but worth experimenting with.

(05 Nov '12, 11:01) Vincent de P... ♦

I updated my answer based on the comment from Vincent de Phily, because Tirex can actually do the things he requests.

(05 Nov '12, 13:26) Jochen Topf

Source code available on GitHub .