Hi Giorgino,
here are two ideas for what could be the correct predicate:
1) intersect (
https://postgis.net/docs/ST_Intersects.html ). This is true if both geometries are not disjoint. Note that the documentation says: ST_Overlaps, ST_Touches, ST_Within all imply spatial intersection. So the Within-case is covered in addition to all cases covered by Overlaps.
However, you ask whether the resultant multipoint will have a size greater than one. I am not entirely sure, what you mean by that. Touches would be true for cases where the intersection is only one point or finitely many points so you may want to rule that out.
The intersection could also be multiple points if the linestrings meet at multiple locations without sharing a common line. I don't know of a way to check for "touch at more than one point but possibly only finitely many points". But if you want them to intersect in a way such that they share at least one common piece of a line with positive length then what you want to check is whether the dimension of the intersection of their interior is at least 1. The distinction I am referring to is illustrated here:
https://ibb.co/sJP2mF3
So that would be my idea 2):
2) use the relate check with the mask "1********". This checks whether the intersection of their interior is of dimension 1. I believe this is equivalent to "overlaps or within(a,b) or within(b,a)" for one-dimensional geometries like linestrings. I think the correct code would look like this:
linestring_2d line_test1({ point_2d(0.0, 0.0), point_2d(2.0, 0.0) });
linestring_2d line_test2({ point_2d(0.0, 0.0), point_2d(1.0, 0.0) });
boost::geometry::de9im::mask mask("1********");
bool check = boost::geometry::relate(line_test1, line_test1, mask);
Now, with regard to your hashing issue. I am not an hashing-expert, but I hope the following considerations are helpful:
You could normalize the orientation input linestrings like this: compare the start and the end point lexicographically: start < end iff start.x < end x || (start.x == end.x && start.y < end.y). Reverse the linestring if start is not smaller than end, then hash as you do now. The reversal does not need to be stored explicitly, you can just traverse it in the opposite direction during hashing. However, if start == end, that check is insufficient, and maybe you can then compare the point after start with end and so on until you can be sure of the orientation (if all points are the same, there is nothing do reverse).
This may be sufficient if your linestrings are normalized up to orientation. However, if you have two linestrings like {a,b,c} and {a,c}, where b is some point on the line [a, c], that hashing mechanism would be still insufficient to detect spatial equality. You could eliminate that by normalizing the linestrings in the hashing function by eliminating all such points b. However, I noted that you use double coordinates, so there may be surprises with regard to what points are actually collinear (for example, numbers like 0.2 are not exactly representable in double precision) and whether that is correctly detected by the side-strategy. Maybe your geometries are generated in a way that makes this a non-issue, though.
Kind regards
Tinko