GeoSegment is unnecessary

[rjyounes]

A GeoSegment is just the special case of a GeoRoute with two points. If it were to subclass GeoRoute, it makes the representation of a GeoRoute messy because it uses a different mechanism for ordering (comesFromPlace, goesToPlace rather than an ordered collection). The triples using those predicates will be inferred between every pair of consecutive points on the route.

Either we should keep the class and redefine it as a GeoRoute with two members, dropping the predicates from the definition, or deprecate/delete it.

[kstudzin]

We are correcting GeoRegion to GeoRoute in #1160.

I think the current definition, including the formal definition, leave it unclear if GeoSegment is a curve or a line. I had the impression it was a line, but looking at it a second time it wasn't 100% clear it can't be a curve.

For context, this came up due to the gist CCO mapping. CCO has a GeospatialLineString class, which is similar to GeoRoute and has a GeospatialLine subclass. I was trying to understand if GeoSegment and GeospatialLine were essentially equivalent

[rjyounes]

GeoRoute and GeoSegment cannot contain curves, else the ordered collection of points or the comesFromPlace and goesToPlace values, respectively, would not be deterministic. They would each define, not a path, but an infinite set of paths.

[kstudzin]

The way I think about it is that now we assume the function connecting the two points is a line. I was imagining overriding that with a more complex function. I think we should add the word "line" to the definition: "An ordered set of GeoPoints that defines a path of line segments from starting point to ending point."

[marksem]

Dropping GeoSegment seems reasonable. GeoRoute seems sufficient for upper onto like gist. If someone finds a good justification for keeping GeoSegment, I agree it should be re-defined in terms of specialization of a GeoRoute.