You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following on from a discussion on a raw_tiles issue, we might want to think about wrapping Shapely to avoid common pitfalls when going geometric operations.
For example:
We usually think of a polygon-polygon intersection as returning a polygon, but it can also return points or linestrings, or a geometry collection of any/all of those. Wrapping the operation to match our mental processes would result in fewer issues, likethese. Alternatively, we could return a tuple of (points, lines, polygons), which would make dealing with the non-polygon bits more explicit.
We could convert all empty geometries into None, or an explicit empty geometry type which raises an exception when used in any operation. This would make it easier to enforce checking for emptiness. We almost always want to discard features with empty geometries, and do not want to include them in any output.
The text was updated successfully, but these errors were encountered:
Following on from a discussion on a
raw_tiles
issue, we might want to think about wrapping Shapely to avoid common pitfalls when going geometric operations.For example:
(points, lines, polygons)
, which would make dealing with the non-polygon bits more explicit.None
, or an explicit empty geometry type which raises an exception when used in any operation. This would make it easier to enforce checking for emptiness. We almost always want to discard features with empty geometries, and do not want to include them in any output.The text was updated successfully, but these errors were encountered: