[postgis-devel] Enabling wagyu by default

[Daniel Baston]

> 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.

Can you open some tickets on the GEOS trac for these? I'd like to get the
GEOS implementation improved, but as far as I know there are no open bugs.
(Not claiming that the bugs don't exist, only that I can't fix something I
don't know about.)

Dan

On Fri, May 31, 2019 at 5:10 AM Raúl Marín Rodríguez <rmrodriguez at carto.com>
wrote:

> 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20190531/8cc4a6c8/attachment.html>