<div dir="ltr">> This has led me to find<br>> quite a bit of bugs in the GEOS implementation (you can see the release<br>> notes for 2.4.x and 2.5.x) and none in wagyu.<div><br></div><div>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.)</div><div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 31, 2019 at 5:10 AM Raúl Marín Rodríguez <<a href="mailto:rmrodriguez@carto.com">rmrodriguez@carto.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
> Ok, but the "backend" term and the "default" term make me think it is<br>
configurable by user, is it ? Documentation does not say, even for<br>
<a href="https://postgis.net/docs/ST_AsMVTGeom.html" rel="noreferrer" target="_blank">https://postgis.net/docs/ST_AsMVTGeom.html</a><br>
<br>
Maybe calling it backend isn't the most appropiate term.<br>
<br>
It can't be changed at runtime since I want to avoid adding any more<br>
flags to the ST_AsMVT functions (they have a lot already).<br>
<br>
There is a note about it in the 3.0 docs:<br>
<a href="https://github.com/postgis/postgis/blob/372f572d972eaefd63724445b54aafdfe7190bf3/doc/reference_output.xml#L1064" rel="noreferrer" target="_blank">https://github.com/postgis/postgis/blob/372f572d972eaefd63724445b54aafdfe7190bf3/doc/reference_output.xml#L1064</a><br>
<br>
<br>
> So, do you think it's worth adding some links to the postgis<br>
> wiki (or manual?) for known users of those functions ?<br>
<br>
Do we do it for other functions? But since using ST_AsMVT properly isn't<br>
straightforward maybe some extra information (either wiki, blog or in the<br>
manual) wouldn't hurt.<br>
<br>
<br>
<br>
> That said, I don't see any risk in having our own implementation of an<br>
algorithm which we know works.<br>
<br>
I've discussed this with Martin, and he mentions it in the e-mail too, but<br>
if we had an equivalent (in terms of functionality and performance) function<br>
using GEOS I wouldn't hesitate to drop wagyu.<br>
<br>
<br>
> If such an eventuality would happen with the wagyu project,<br>
> we'd be willing to fork/continue to maintain it for our own purposes.<br>
<br>
See above, if for some reason we had to stop using wagyu my first option<br>
would be to push harder to implement this in either geos or, god forbid,<br>
native postgis.<br>
<br>
<br>
> 1) Do we just bring the code in and compile it?  We aren't requiring user to precompile?<br>
> 2) Does it download the source from somewhere?<br>
> 3) Are any of our bots testing with building with wagyu<br>
<br>
It's already there, under the recently added deps/ folder, same as<br>
with uthash code.<br>
<br>
Currently there is only one travis machine building with `--with-wagyu`.<br>
The idea is to turn it on by default and see if anything breaks and then<br>
leave a machine building `--without-wagyu`.<br>
<br>
> 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<br>
but if it then increases the compilation or downloads additional etc,<br>
I'm a bit uneasy about that.<br>
<br>
It's included in the tarball, so no downloads required. In my machine, building<br>
the wagyu code without cache takes ~8 seconds (blame C++ templates).<br>
<br>
<br>
> Seems like the risks of using Wagyu are (if it is not maintained by the original developers):<br>
<br>
> - compilation problems going forward (since PostGIS is vendoring it)<br>
> - functional limitations as MVT requirements evolve<br>
> - finding issues which are showstoppers<br>
<br>
The one I most concerced about is the first one; that's why I want to make<br>
it a default now so there is enough time to fix any build issue.<br>
<br>
As far a new MVT requirements, as far as I can remember, the v3 spec<br>
which is under development will introduce some changes (splines,<br>
different attribute enconding...) that will require extra<br>
development, but nothing related polygon transformation.<br>
<br>
<br>
> These are mitigated by:<br>
<br>
> - it sounds like current functionality is adequate for current usage?  (Are there unit tests to assure this?)<br>
> - the fallback is to revert to using GEOS, as per before<br>
> - hopefully GEOS will provide new, robust overlay functionality soon<br>
> - GEOS can fairly easily implement the same clipping algorithm as Wagyu, which should provide similar performance<br>
<br>
There are a bunch of regress/ tests that pass for both GEOS and wagyu.<br>
I've included as many corner cases as I found while generating a lot of<br>
tiles and comparing differences between the two. This has led me to find<br>
quite a bit of bugs in the GEOS implementation (you can see the release<br>
notes for 2.4.x and 2.5.x) and none in wagyu.<br>
<br>
And yes, if we had a function in geos to do the fast clipping + validation<br>
in **integer coordinates** we could easily drop wagyu.<br>
<br>
<br>
As I don't see any big arguments against it, I'll try enabling it as soon<br>
as I can and see how bots behave, ideally before the alpha2 release.<br>
<br>
<br>
<br>
-- <br>
Raúl Marín Rodríguez<br>
<a href="http://carto.com" rel="noreferrer" target="_blank">carto.com</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>