[postgis-devel] Enabling wagyu by default

[Raúl Marín Rodríguez]

Hi,

> Ok, but the "backend" term and the "default" term make me think it is
configurable by user, is it ? Documentation does not say, even for
https://postgis.net/docs/ST_AsMVTGeom.html

Maybe calling it backend isn't the most appropiate term.

It can't be changed at runtime since I want to avoid adding any more
flags to the ST_AsMVT functions (they have a lot already).

There is a note about it in the 3.0 docs:
https://github.com/postgis/postgis/blob/372f572d972eaefd63724445b54aafdfe7190bf3/doc/reference_output.xml#L1064


> So, do you think it's worth adding some links to the postgis
> wiki (or manual?) for known users of those functions ?

Do we do it for other functions? But since using ST_AsMVT properly isn't
straightforward maybe some extra information (either wiki, blog or in the
manual) wouldn't hurt.



> That said, I don't see any risk in having our own implementation of an
algorithm which we know works.

I've discussed this with Martin, and he mentions it in the e-mail too, but
if we had an equivalent (in terms of functionality and performance) function
using GEOS I wouldn't hesitate to drop wagyu.


> If such an eventuality would happen with the wagyu project,
> we'd be willing to fork/continue to maintain it for our own purposes.

See above, if for some reason we had to stop using wagyu my first option
would be to push harder to implement this in either geos or, god forbid,
native postgis.


> 1) Do we just bring the code in and compile it?  We aren't requiring user to precompile?
> 2) Does it download the source from somewhere?
> 3) Are any of our bots testing with building with wagyu

It's already there, under the recently added deps/ folder, same as
with uthash code.

Currently there is only one travis machine building with `--with-wagyu`.
The idea is to turn it on by default and see if anything breaks and then
leave a machine building `--without-wagyu`.

> I'm more concerned about the logistics of defaulting it.  If it's like it uses it if it finds it available in system like other things, I'm okay with that
but if it then increases the compilation or downloads additional etc,
I'm a bit uneasy about that.

It's included in the tarball, so no downloads required. In my machine, building
the wagyu code without cache takes ~8 seconds (blame C++ templates).


> Seems like the risks of using Wagyu are (if it is not maintained by the original developers):

> - compilation problems going forward (since PostGIS is vendoring it)
> - functional limitations as MVT requirements evolve
> - finding issues which are showstoppers

The one I most concerced about is the first one; that's why I want to make
it a default now so there is enough time to fix any build issue.

As far a new MVT requirements, as far as I can remember, the v3 spec
which is under development will introduce some changes (splines,
different attribute enconding...) that will require extra
development, but nothing related polygon transformation.


> These are mitigated by:

> - it sounds like current functionality is adequate for current usage?  (Are there unit tests to assure this?)
> - the fallback is to revert to using GEOS, as per before
> - hopefully GEOS will provide new, robust overlay functionality soon
> - GEOS can fairly easily implement the same clipping algorithm as Wagyu, which should provide similar performance

There are a bunch of regress/ tests that pass for both GEOS and wagyu.
I've included as many corner cases as I found while generating a lot of
tiles and comparing differences between the two. This has led me to find
quite a bit of bugs in the GEOS implementation (you can see the release
notes for 2.4.x and 2.5.x) and none in wagyu.

And yes, if we had a function in geos to do the fast clipping + validation
in **integer coordinates** we could easily drop wagyu.


As I don't see any big arguments against it, I'll try enabling it as soon
as I can and see how bots behave, ideally before the alpha2 release.



-- 
Raúl Marín Rodríguez
carto.com