<div dir="ltr">Compared to the classic mod_tile/renderd architecture, the benefits of vector tiles seems to be:<div>- easier to render different stylesheets (including retina, png+jpeg, etc)</div><div>- much less "metatiles" to maintain (2 or 3 levels of vector tiles coming from the database instead of 18+)</div>

<div>- allows client side rendering</div><div><br></div><div>Andy's talk as SOTM-EU was very interesting, check it again: <a href="http://stateofthemap.eu/en/slots/10">http://stateofthemap.eu/en/slots/10</a></div><div>

<br></div><div>Mapnik is the engine producing and using vector (data) tiles.</div><div>There should be a better approach than nodejs to drive it...</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

2014-06-25 10:25 GMT+02:00 Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi,<br>
<br>
   if you have followed recent developments then you know that both<br>
Mapbox and Andy Allan have moved, or are moving, away from producing<br>
raster tiles the old fashioned way, to producing raster tiles on-the-fly<br>
from pre-computed vector tiles.<br>
<br>
For the time being (i.e. until we have reached a point where every<br>
possible client can simply process vector tiles directly), this seems to<br>
be an elegant solution that allows great flexibility in styling at a<br>
manageable cost.<br>
<br>
For those of you who are not familiar with the concept, I would suggest<br>
you review Dane Springmeyer's presentation at SOTM US 2013 and 2014, and<br>
Andy Allan's talk at SOTM EU 2014; all talks are recorded and available<br>
online.<br>
<br>
As far as I can see, the current implementations of this concept are<br>
based on the idea: "Let's make it so that we always have a world-wide<br>
set of current vector tiles, and render raster tiles from that on the fly."<br>
<br>
In order not to require too many vector tiles, vector tiles are usually<br>
produced for zoom levels no higher than 14; and the z14 vector tile will<br>
contain all information required for rendering any higher zoom tile<br>
below it.<br>
<br>
(There's also the technical possiblity of combining vector tiles from<br>
different zoom levels to produce a raster tile, e.g. you could load<br>
woodland boundaries from a z12 vector tile and road geometries from a<br>
z14 tile but I'll ignore that for now - Dane explains in his 2014 talk.)<br>
<br>
With our old-fashioned raster tile servers, based on renderd or tirex,<br>
the updating and even the production of tiles is demand-driven. You are<br>
usually well advised to do some pre-rendering on a tile server but you<br>
don't *have* to; likewise, tiles don't have to be updated as a diff<br>
comes in, they are just marked as outdated, then when someone asks for<br>
them next time they get updated. (And if updating doesn't work fast<br>
enough, an old tile is delivered and the update happens in its own time.)<br>
<br>
I wonder if this old architecture could somehow be combined with the<br>
shiny new world of vector tiles, something along these lines:<br>
<br>
1. Browser requests tile from Apache<br>
2. Apache (mod_tile) checks if the raster tile is in the memory cache<br>
3. if yes, deliver from memory cache<br>
4. if no, mod_tile checks if the required vector tile(s) is/are on disk<br>
5. if yes and vector tile is current, render raster tile, store in<br>
memory cache, and deliver<br>
5. if yes and vector tile is outdated, request new vector tile from<br>
tirex/renderd and proceed as above, falling back to using the outdated<br>
vector tile if response takes too long<br>
6. if no, request new vector tile from tirex/renderd and proceed as<br>
above, returning 404 if response takes too long<br>
<br>
This would require a significantly beefed-up mod_tile (that includes<br>
mapnik for turning vector tiles into raster tiles) and only a slightly<br>
modified tirex/renderd (able to produce vector tiles in much the same<br>
way they now produce raster tiles). A lot of work that has gone into<br>
tirex/renderd regarding different storage backends, queue management<br>
etc. would probably be valuable for this use case too.<br>
<br>
This architecture would also do away with nodejs altogether, although<br>
whether a C/C++ Apache module and a C/C++ and/or Perl based backend is<br>
any better is of course very much a matter of taste.<br>
<br>
I'd be interested to hear your opinions on this.<br>
<br>
Bye<br>
<span class="HOEnZb"><font color="#888888">Frederik<br>
<br>
--<br>
Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org">frederik@remote.org</a>  ##  N49°00'09" E008°23'33"<br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/dev" target="_blank">https://lists.openstreetmap.org/listinfo/dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Christian Quest - OpenStreetMap France</div>
</div>