
<html><body><div><br></div><div>On Apr 30, 2018, at 04:03 AM, Christoph Hormann <osm@imagico.de> wrote:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content">I think that is a good idea - i in particular like that the toolchain <br>used seems to be free of NodeJS. ;-)</span></div></div></blockquote></div><div><span><br data-mce-bogus="1"></span></div><div><span>This was in the back of my mind, but more important to me was being free of Mapnik. Mapnik offers great output if generating images, but it's always seemed more work than it's worth if you're not using any of those features.</span></div><div><br><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><blockquote type="cite" class="quoted-plain-text"></blockquote>As you know i doubt serious overall mapper feedback is possible at the <br>moment with client side rendered vector tiles but the possibility of <br>additional QA functionality based on data in the vector tiles is an <br>interesting option.</span></div></div></blockquote></div><div><span><br data-mce-bogus="1"></span></div><div><span>I know your views on simplification and mapper feedback, but I don't find them to be issues. I suspect the answer is that we'll have to see to be sure. Even if some difficulty in feedback from simplification happens, I feel that QA based on data in vector tiles is more valuable. I have to figure out what causes a label far more often than I have to look at the precise details of a geometry.</span></div><div><span> </span><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content">I have not actually tested it yet but you seem to be using stone age <br>Natural Earth data at z0-z5 - which is a big step back from OSM-carto <br>IMO.</span></div></div></blockquote></div><div><span><br data-mce-bogus="1"></span></div><div><span>I didn't find noticeable differences between the Natural Earth and OSM data I'm using at these very low zooms</span></div><div><span> </span><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content">Do you have practical experience in deployments with loading external <br>data, in particular the coastlines, in PostGIS with regular (daily) <br>updates? Certainly this is possible but it is also kind of and extreme <br>case of using PostGIS for something it is not intended for.</span></div></div></blockquote></div><div><span><br data-mce-bogus="1"></span></div><div><span>I've been using the same script with my server demoing the new WMF style work. It doesn't run automatically there, but i have run it a lot. It takes about 30 seconds to load and process the water polygons for the coastline on my home server, and that includes clustering and index building. It takes longer to download the file.</span></div><div><span><br data-mce-bogus="1"></span></div><div><span>The script makes sure to create a table optimised for rendering, with the contents clustered, indexes created for a read-only case, and some other tweaks. This avoids bloated tables.</span></div><div><span><br data-mce-bogus="1"></span></div><div><span>How do you consider this case extreme?</span></div><div><span> </span><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content">In the client style the method to specify colors seems rather odd to <br>me - is this some kind of standard in this field or is this just an <br>invention of you?</span></div></div></blockquote></div><div><span><br data-mce-bogus="1"></span></div><div><span>I've been experimenting with different colour selection methods, and have found using a limited colour palette helpful. I want to specify colours in LCH, not sRGB, and Tangram scene files, like most style files, only allow direct input of the latter.</span></div></body></html>