Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] Integrate wagyu to validate MVT polygons #356
@flippmoke PostGIS has its own
I would say that one way may be to understand what wagyu is doing to the contours to make them valid and try porting only that part of it, building on top of LWGEOM's abstractions. Documentation would help - link to https://github.com/mapbox/wagyu/blob/master/docs/intersections_chains.md on documentation looks dead, even a TBD with pointer to some code would be good - I'm not good at following templated C++ for now.
Is following integer grid a must for wagyu's underlying algorithms? Can it operate on doubles?
Yes, it can. In my "bridge" file you can change just by modifying this line
The thing is that for MVT if you are using doubles for validation you need to grid any resulting points after the process is done, which can lead again to an invalid geometry. It's rare but I've seen it happening in our current MVT implementation with st_makevalid.
Wagyu is not designed to operate on doubles. It will operate, but it has issues around several sections of the code - mapbox/wagyu#76. My current thought is that it would likely be best to introduce scaling for doubles before they are used in wagyu and then de-scale once it is complete. This is destructive to original values, but wagyu by its nature is destructive to original geometry state due to the snap rounding that occurs during its operation. This was a design choice that was acceptable during our creation of it because everything will be an integer coordinate and lossey once it is put into vector tiles.
I've changed the API of the adaptor to receive a geometry and a bounding box instead of 2 geometries. This is so, instead of asking wagyu to clip the 2 geometries (which was slow when most of the polygon was outside the tile), it checks the bounding box per linear_ring and uses
I've also added a handle for interruptions in 9126fd9. It's not super nice since it involves adding some code in the library itself (in the most expensive loops) but I don't see any other way around it.
In the process I detected a bug in the GEOS path that made some ST_AsMVTGeom occasionally output float numbers. I'll probably push the fix in a different ticket, but a proper fix requires a big hit in performance (basically re-running validation, which is already the slowest part).
The only thing pending now is to create a new .travis build to check the
Current comparison (trunk vs wagyu): 20190104_trunk_vs_20190109_wagyu_interrupt.pdf