<div dir="ltr"><div>Hi,</div><div><br></div><div>in the OpenScienceMap project we actually use Tirex in our vector-tiles stack. For this I wrote a simple Tirex backend that can render any kind of TileStache layers[1]. <br>
</div><div>I can definitely recommend Tirex for renderqueue management, though I havent looked what is provided by the Tilelive components yet.</div><div><br></div><div>To produce Mapbox vector-tiles Mapzen implemented a TileStache VecTiles provider[2]. </div>
<div><br></div><div>So for those who enjoy python the first part to create vector-tiles together with Tirex is somewhat working. So far I was only concerned with client-side vector rendering. Not sure whether Mapnik (without nodejs) can use mvt to render bitmap tiles yet.</div>
<div><br></div><div><br></div><div>Regards,</div><div>Hannes</div><div><br></div><div><br></div><div>[1]<a href="https://github.com/hjanetzek/TirexStache">https://github.com/hjanetzek/TirexStache</a></div><div>[2]<a href="https://github.com/mapzen/TileStache/tree/integration-1">https://github.com/mapzen/TileStache/tree/integration-1</a><br>
</div><div><a href="https://github.com/mapzen/vector-datasource/wiki/Mapzen-Vector-Tile-Service">https://github.com/mapzen/vector-datasource/wiki/Mapzen-Vector-Tile-Service</a><br></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Wed, Jun 25, 2014 at 10:25 AM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>></span> wrote:<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">Hannes</div>
</div>