Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
water features with boundary=yes gappy in some areas #735
Notably around Manhattan and some nearby areas:
Viewable here as of 14 Oct 2016: http://tangrams.github.io/explorer/#13.0/40.7609/-73.9744/boundary/true
Comment from Slack, for context:
Confirmed this is still a problem on dev with v1 tiles.
In the case of NYC area, we think this is because of the coastline derived water polygon (openstreetmapdata.com) is mostly coincidental with the riverbank polygons for Hudson, East River, and various riverbank channels of those rivers. Which is a widespread data problem we'll need to engineer around.
Hopefully this diagram will help explain what's going on. We have data from the database which is like the top row, with water polygons overlapping. The tops of the polygons don't overlap exactly. Although the difference has been exaggerated here to be easier to see, often the differences can be only thousandths of a "meter" unit. The bottoms of the polygons show the opposite: they align exactly.
The second row shows what's "mathematically correct" with a black dashed line standing in for some sort of tie-break between A and B.
We currently try to make this work by taking the boundary of each polygon and subtracting any other polygons which overlap it. This leads to the next few rows in the diagram, showing each polygon's boundary with the other polygon subtracted.
On the final row, these are combined together, showing the tops of the polygons "stitching" or "dashing" and the bottoms missing entirely!
I think this is because the current algorithm is commutative. The current algorithm could be summarised as:
The missing boundary problem arises because there are some segments of the boundaries of polygons which are exactly the same, and so get subtracted from both by each other, leaving a gap. The stitching problem occurs because polygons can have very similar - but not identical - boundaries, so both subtract small segments of each other's boundary.
The previous algorithm, which was replaced because of performance problems, was similar to:
Although this is slower, creating a single boundary line up-front ensures that there are no missing sections of the boundary. Doing the subtraction in an ordered way allows us to buffer each polygon by a small amount, which will reduce (but probably not eliminate) the "stitching" or "dashing" problem.