MultiGeometry binary predicate support.

[thomcom]

Description

Closes #1063
Closes #1210

MultiPoint and MultiLineString predicates, this PR.

An exception to this involves MultiLineStrings that can be merged by their endpoints. Shapely/GEOS appears to merge these MultiLineStrings before calling the binary predicates on them, producing different results for contains, covers, crosses, touches, and within. We can only duplicate this behavior by implementing a merge functionality of our own.

This PR has implementations of Multi geometry binary predicates for:
Point-MultiPoint
MultiPoint-Point
MultiPoint-MultiPoint
Point-MultiLinestring
MultiLineString-Point
LineString-MultiLinestring
MultiLinestring-LineString
MultiLineString-MultiLineString

Remaining to be tested and implemented are one Polygon configuration: Polygon-MultiLineString and the MultiPolygon configurations.

(Multi)LineString-(Multi)LineString tests have issues caused by non-simple MultiLineStrings - that is, any LineString that has self-intersection is non-simple.

crosses

Crosses compares the vertices of intersection with boundary vertices of the lhs and rhs, and is true only when the intersection vertices are not equal to boundary vertices of the lhs or rhs.

There are two fundamental issues in the crosses predicate that I'm still befuddled on:

1. LineString "compaction": GEOS appears to connect sequential endpoints lines in a MultiLineString into a single LineString before computing intersections. This is the major issue facing this PR.

touches

The touches predicate appears to have the same fundamental issues as the crosses predicate and fails on the same cases. This is because touches compares vertices of intersection with boundary vertices of the lhs and rhs, and is true when the intersection vertices only equal boundary vertices.

MultiPolygon incomplete

Major improvements also need to be made to the Polygon.contains predicate in order to handle predicates with MultiPolygon types on the lhs. This is because MultiPolygon.contains({MultiLineString, MultiPolygon}) iff all geometries of the rhs are contained in any geometry of the lhs. This requires that improvements be made to the point-in-polygon and .contains routines to better handle many-to-many operations.

Quadtree point in polygon can be used with many-to-many operations, but will quickly create results too large for memory with large sets of lhs and rhs. A single MultiPolygon in the lhs needs to have a many-to-many point in polygon called against the points in its corresponding rhs, but does not need to compute point in polygon for all of the points in the other, non-corresponding rhss.

MultiPolygon predicates have begun implementation here:

https://github.com/thomcom/cuspatial/tree/feature/multipolygon-test-dispatch

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[isVoid]

It feels like you need a separate API that handles linestring merging. Something like:

void merge_points_on_multilinestring_range(MultiLinestringRange range, OutputIt output);

Because calling the self intersection just to remove the additional points is too expensive.

[isVoid]

Suggested change

	# of indexes that contain point intersections and do not contain line
	# of indices that contain point intersections and do not contain line

[isVoid]

It says "none of the points of intersection is in the boundary of the geometry". AKA, there is 0 points in the intersection results that are in the boundary. Shouldn't this be

lhs_boundary_matches == 0

?

[isVoid]

A small docstring helps:

Suggested change

	def _preprocess(self, lhs, rhs):
	def _preprocess(self, lhs, rhs):
	"""Linestring overlaps with another linestring if the overlapping part of
	two linestring is not the entire section of the linestring.
	"""

Sounds correct?

[isVoid]

I thought only backward slash needs escaping, does forward slash too?

[isVoid]

Why is noqa needed? There's no import here.