Process boundaries from RAWR tiles the same way we do from SQL. #362
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
iandees
approved these changes
Jan 21, 2019
…he use of the word 'boundary' both for the features in the 'boundaries' layer, and the line separating the interior of the polygon from the exterior.
rmarianski
approved these changes
Jan 21, 2019
tilequeue/query/rawr.py
Outdated
| between a line and a polygon. The main idea is to remove points, and any | ||
| other geometry which might throw a wrench in the works. | ||
| """ | ||
| from shapely.geometry import MultiLineString |
There was a problem hiding this comment.
Yup, good idea. Fixed in 92ba304.
tilequeue/query/rawr.py
Outdated
| # nasty hack: in the SQL, we don't query the lines table for | ||
| # boundaries layer features - instead we take the rings (both outer | ||
| # and inner) of the polygon features in the polygons table - which are | ||
| # also called the "boundary" of the polygon. the back below replicates |
There was a problem hiding this comment.
Well spotted, thanks! Fixed in f97dd53.
zerebubuth
added a commit
that referenced
this pull request
Feb 1, 2019
We include buffered land into the boundaries table, but we want to keep it as a polygon, not turn it into a set of outer/inner ring linestrings.
zerebubuth
added a commit
that referenced
this pull request
Feb 1, 2019
Exclude buffered land polygons from changes made in #362.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We don't query boundaries at all from the
planet_osm_linestable, instead we select the polygons and generate linestring boundaries from them. This is to ensure that boundaries are correctly oriented with the interior on the left.However, we weren't doing this for RAWR tiles, and were using the lines from
planet_osm_linesin their original orientation. Theplanet_osm_linestable contains multiple copies of the line; from the original way, plus any boundary relations it is part of. This meant that the two linestrings making up a section of border were in the same direction, and therefore the boundary would be flipped if the geometry was "used" by the wrong side first (which depends on the order in the file, which is non-deterministic).The fix for this is a bit of an egregious hack; it just drops any
boundarieslinestrings and turns polygons into their boundaries (clipped to the tile). This matches the SQL invector-datasource, but isvector-datasource-specific processing which doesn't seem to belong intilequeue, but I couldn't figure a less hacky way to do it without major refactoring.Connects to tilezen/vector-datasource#1770.