<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 7:45 AM, Peter Devoy <span dir="ltr"><<a href="mailto:peter@3xe.co.uk" target="_blank">peter@3xe.co.uk</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the suggestion Brian.  I did look into it but understood it using non<br>
Spherical Mercator projections couldn't be done without hacking/extension?<br></blockquote><div><br></div><div>That's probably fair. I can't say I know much about tiling those projections. We copy and convert our shapes to Spherical Mercator in PostGIS specifically for tile serving. We do have a thin layer in front of TileStache to convert Bing Maps quadkeys to X/Y/Zoom though.</div><div><br></div><div>I completely missed the significance of this aspect of your question! :) Now I'm really curious.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another reservation I have about Python tile servers is the extent to which<br>
their ability to scale could be hampered by the Global Interpreter Lock. Do you<br>
happen to have done any load testing?<br></blockquote><div><br></div><div>We've scaled horizontally. We serve 3 million tiles a week using two virtual TileStache servers with multiple WSGI threads each, fronted with CDN for caching. Our only performance hiccups have been Mapnik rendering tiles at some of the mid-range zoom levels, where we still show full polygons but the individual tiles cover a large enough area that the data is intensive. Luckily we are able to tune our caching to compensate for this due to varying data life cycles.<br><br>But that said, these are shaded raster Choropleth map tiles, so I doubt the same performance constraints would affect vector tiles as there's no rendering.</div><div><br></div><div>-B</div></div></div></div>