<div>Hi,</div><div><br></div><div>> <span style="color:rgb(34,34,34);font-size:14px">other OSGeo project. Their builds rely on mason which has to be patched</span></div><div><span style="color:rgb(34,34,34);font-size:14px"><br></span></div><div><font color="#222222"><span style="font-size:14px">I also dislike mason and we (CARTO) also need to use forks and host our own packages for it.</span></font></div><div><br></div><div>> <span style="color:rgb(34,34,34);font-size:14px">Let's keep the Mapbox mess confined to the Mapnik family, that is</span></div><span style="color:rgb(34,34,34);font-size:14px">> painful enough to maintain as it is.</span><div><font color="#222222"><span style="font-size:14px"><br></span></font></div><div><font color="#222222"><span style="font-size:14px">Both libraries are header only so the "Mapbox mess" should be contained. Does that makes it better?</span></font></div><div><font color="#222222"><span style="font-size:14px"><br></span></font></div><div><font color="#222222"><span style="font-size:14px">Related to this, what's the policy for packaging header only libraries? It seems that libwagyu-dev provides everything.</span></font></div><div><font color="#222222"><span style="font-size:14px"><br></span></font></div><div><font color="#222222"><span style="font-size:14px">> </span></font><span style="color:rgb(34,34,34);font-size:14px">out in distribution packages, and their projects tend to die when they</span><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34);font-size:14px">> aren't commercially viable</span></div><div><font color="#222222"><span style="font-size:14px"><br></span></font></div><div><font color="#222222"><span style="font-size:14px">This is indeed something to worry about. I'm considering wagyu as a mostly done product (similar to uthash) and that's why I dislike less the idea of bringing in the code instead of using system libraries.</span></font></div><div><font color="#222222"><span style="font-size:14px"><br></span></font><div><br></div><div> > - wagyu github repo shows 2% codecov badge</div><div><br></div><div> It seems to be some recent issue with the ci. It was 90+% a few commits ago. Nevertheless it has an automatic way to generate tests that has been run for hours multiple times to detect bugs.</div><div><br></div><div>> - it does not show itself in PostGIS's codecov</div><div><br></div><div>Yes. It is one of the things I mentioned are pending. I plan to add it to the travis matrix.</div><div><br></div><div>> - there are almost no commits in 2018</div><div><br></div><div>That isn't great but I would only worry if it was like that and had important issues; but that's not the case.</div><div><br></div><div>> - until your last commit travis was broken</div><div>> - documentation ticket is open since 2016</div><div>> - links in <a href="https://github.com/mapbox/wagyu/tree/master/docs" target="_blank">https://github.com/mapbox/w<wbr>agyu/tree/master/docs</a> lead to dead pages</div><div><br></div><div>Same thing could be said about Postgis. That doesn't make it worse.</div><div><br></div><div> > - it ships bubble sort?</div><div><br></div><div>I saw that and found it surprising too. Nevertheless it's supposed to be the fastest ordering method for small array sizes and it has't appeared as an issue in the perf analysis I've done.</div><div><span style="color:rgb(34,34,34);font-size:14px"><br></span></div><div><span style="color:rgb(34,34,34);font-size:14px">> And just a naive question on my own: "Why always checking the geom validity ?"</span><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34);font-size:14px">> Why not have to call ST_MakeValid on userland prior to ST_AsMVT, but</span><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34);font-size:14px">>only if really needed.</span></div><div><span style="color:rgb(34,34,34);font-size:14px"><br></span></div><div><font color="#222222"><span style="font-size:14px">I guess that you mean calling ST_MakeValid before ST_AsMVTGeom right. It's pretty simple: the process of both simplifying and snapping to the 4096x4096 tile can turn valid geometries into invalid.</span></font></div><div><font color="#222222"><span style="font-size:14px">We also tested removing the validation (it was't there in 2.4 if I recall correctly) and producing invalid geometries according to the MVT spec,  but </span></font><span style="font-size:14px;color:rgb(34,34,34)">it led to broken visualizations because some decoders/renderers rely on it.</span></div><div><br></div><div>Regards</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" data-smartmail="gmail_signature"></div>
</blockquote>
</div><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><b style="font-size:12.8px"><font color="#666666">Raúl Marín Rodríguez <br></font></b><a href="http://carto.com/" style="font-size:12.8px" target="_blank">carto.com</a><div><br></div></div></div></div></div></div><br>