[FEA] linestring-linestring intersection (pairwise)

[harrism]

Is your feature request related to a problem? Please describe.

A function to return, for each specified pair of linestrings, the point at which they intersect. We may also need the segment index within each linestring of the intersection.

#648 (comment)

[github-actions]

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.

[isVoid]

We may also need the segment index within each linestring of the intersection.

Can you confirm?

[harrism]

Based on the recent meeting I believe the answer is yes.

[isVoid]

Linestring intersections can return not only points, but also linestrings. This happens when two linestrings overlaps. Based on this, the return result of intersecting two linestrings could be not just points, but also linestrings.

Another challenge is that linestring can have multiple intersections per pair. We can use a geometry collection to store the result, e.g. MultiPoint for point intersections and MultiLinestring for multiple linestring overlaps.

To sum up, the result for each row can have at most one MultiPoint and one MultiLineString. Thus the result can be stored in a pair of MultiPoint and MultiLineString array. With the following indices arrays for both the lhs and rhs inputs:

point_geometry_idx: list of idx, the `j`th element in the `i`th row of the series indicates the multilinestring idx on lhs/rhs of the `j`th intersecting point of the `ith` pair.
linestring_geometry_idx: list of idx, the `j`th element in the `i`th row of the series indicates the multilinestring idx on lhs/rhs of the `j`th overlapping linestring of the `ith` pair.
point_part_idx: list of idx, the `j`th element in the `i`th row of the series indicates the segment idx on lhs/rhs of the `j`th intersecting point of the `ith` pair.
linestring_part_idx: list of idx, the `j`th element in the `i`th row of the series indicates the segment idx on lhs/rhs of the `j`th overlapping linestring of the `ith` pair.

[harrism]

point_geometry_idx: list of idx, the jth element in the ith row of the series indicates the multilinestring idx on lhs/rhs of the jth intersecting point of the ith pair.
linestring_geometry_idx: list of idx, the jth element in the ith row of the series indicates the multilinestring idx on lhs/rhs of the jth overlapping linestring of the ith pair.
point_part_idx: list of idx, the jth element in the ith row of the series indicates the segment idx on lhs/rhs of the jth intersecting point of the ith pair.
linestring_part_idx: list of idx, the jth element in the ith row of the series indicates the segment idx on lhs/rhs of the jth overlapping linestring of the ith pair.

Oooh, that's confusing... Perhaps we can encapsulate it somehow.

[thomcom]

This is probably why GeoPandas and Shapely just return the objects that are in the intersection, right? We don't want users to have to reconstruct their dataset from indices and etc, maybe we can reorganize the data on the way back to become a new set of union_offsets and union_types that represent the intersection using the original input data?

[isVoid]

using the original input data?

Intersection primitive may create new data that does not belong to original input data. I was thinking of using union column type to encapsulate the intersecting-point/overlapping-linestrings. At best it can encapsulate the mixed geometry types (thereby eliminating the need of using two separate column for point and linestring).

Subsequently, the union column style can help reduce the number indices columns by half.