9 ms·

Not sure if I understand why real-time tile rendering on servers doesn't work. Googly clearly does not pre-render tiles and it looks like it works fine for the

Not sure if I understand why real-time tile rendering on servers doesn't work. Googly clearly does not pre-render tiles and it looks like it works fine for them. Request is made, data collected, relevant tiles rendered, returned to client-side. Yes, I know, Google has $billions in computing resources, but does it really take that much server-power to render tiles? (even for 1,000s of requests/second?) Is it a matter of data transfer or processing capacity? A screen sized 2048x1536 would need to load 48 tiles at a time. Google's tiles for a city avg about 14KB/tile, so 672KB. 5,000 of these a second is 3.4GB. (I'm a front-end guy so this is a little out of my league.)

awj 14y ago
The problem, generally, is that rendering the tiles is computationally expensive. You have to wade through each feature (thing that could be represented in the tile) and decide if it intersects the tile, then decide if/how it will be rendered, then render and composite it with every other visible feature. Doing all of that work quickly is possible, it just isn't simple. Also, for most people the data involved changes relatively infrequently. Why have the server render the same tiles repeatedly when you could just cache the result and reduce it to a simple file hosting problem? Also, your 2048x1536 screen may likely be loading more than 48 tiles. It's common to request tiles around the current viewport and (less common) above/below the current zoom to ensure they're present before they're needed. To see this in action, see how fast/far you have to scroll a google map before you can "catch it" with tiles that aren't loaded.
rbranson 14y ago
Google pre-renders tiles. They have publicly stated that they use MapReduce for this.
dsl 14y ago
Google pre-renders every map tile for every zoom level. When a request comes in all they have to do is combine it with a dynamic image header (the color pallet is generated on the fly to support custom map styles) and ship it out.

awj 14y ago

The problem, generally, is that rendering the tiles is computationally expensive. You have to wade through each feature (thing that could be represented in the tile) and decide if it intersects the tile, then decide if/how it will be rendered, then render and composite it with every other visible feature. Doing all of that work quickly is possible, it just isn't simple. Also, for most people the data involved changes relatively infrequently. Why have the server render the same tiles repeatedly when you could just cache the result and reduce it to a simple file hosting problem? Also, your 2048x1536 screen may likely be loading more than 48 tiles. It's common to request tiles around the current viewport and (less common) above/below the current zoom to ensure they're present before they're needed. To see this in action, see how fast/far you have to scroll a google map before you can "catch it" with tiles that aren't loaded.

rbranson 14y ago

Google pre-renders tiles. They have publicly stated that they use MapReduce for this.

dsl 14y ago

Google pre-renders every map tile for every zoom level. When a request comes in all they have to do is combine it with a dynamic image header (the color pallet is generated on the fly to support custom map styles) and ship it out.