Not so far, though this means they can experiment with that.
Part of the challenge of rendering maps quickly is simplifying features, clipping and filtering the data. E.g. you might have a layer containing really high resolution national boundaries. Most tiles won't even contain any part of it, and those who do will either contain a small subsection or a vastly simplified version. If you were to try client side rendering based on that, you're potentially looking at gigabytes of data to transfer to the client.
What they're doing is essentially doing all the steps apart from the final rasterisation, and then storing that vector data on a per tile basis, so that they can process only the relevant vector data - whether to serve it up as is, or rasterise it.
One major advantage is that things like styles (line widths, colours) can be modified without having to re-render the entire map data set. Instead you just have to on-the-fly rasterise the already prepared tiles, which you can do without totally killing performance.
Part of the challenge of rendering maps quickly is simplifying features, clipping and filtering the data. E.g. you might have a layer containing really high resolution national boundaries. Most tiles won't even contain any part of it, and those who do will either contain a small subsection or a vastly simplified version. If you were to try client side rendering based on that, you're potentially looking at gigabytes of data to transfer to the client.
What they're doing is essentially doing all the steps apart from the final rasterisation, and then storing that vector data on a per tile basis, so that they can process only the relevant vector data - whether to serve it up as is, or rasterise it.
One major advantage is that things like styles (line widths, colours) can be modified without having to re-render the entire map data set. Instead you just have to on-the-fly rasterise the already prepared tiles, which you can do without totally killing performance.