[postgis-devel] Introducing wagyu to validate MVT polygons

[Raúl Marín Rodríguez]

Hi,

> other OSGeo project. Their builds rely on mason which has to be patched

I also dislike mason and we (CARTO) also need to use forks and host our own
packages for it.

> Let's keep the Mapbox mess confined to the Mapnik family, that is
> painful enough to maintain as it is.

Both libraries are header only so the "Mapbox mess" should be contained.
Does that makes it better?

Related to this, what's the policy for packaging header only libraries? It
seems that libwagyu-dev provides everything.

> out in distribution packages, and their projects tend to die when they
> aren't commercially viable

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.


 > - wagyu github repo shows 2% codecov badge

 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.

> - it does not show itself in PostGIS's codecov

Yes. It is one of the things I mentioned are pending. I plan to add it to
the travis matrix.

> - there are almost no commits in 2018

That isn't great but I would only worry if it was like that and had
important issues; but that's not the case.

> - until your last commit travis was broken
> - documentation ticket is open since 2016
> - links in https://github.com/mapbox/wagyu/tree/master/docs lead to dead
pages

Same thing could be said about Postgis. That doesn't make it worse.

 > - it ships bubble sort?

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.

> And just a naive question on my own: "Why always checking the geom
validity ?"
> Why not have to call ST_MakeValid on userland prior to ST_AsMVT, but
>only if really needed.

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.
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 it
led to broken visualizations because some decoders/renderers rely on it.

Regards

>

-- 

*Raúl Marín Rodríguez *carto.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181221/bcbc009e/attachment.html>