InteriorPointLine return endPoint of LineString, which is not the "interior point" of the linestring

[kunlinyu]

Let's say if we have a LineString with only two vertices, so both of them are "EndPoint". The InteriorPointLine will return one of the endPoint to be the result. But this result is not lay on the "interior" part of the LineString.

After I read the code, I think, maybe the author don't hope to create new vertex, instead, just pick one from existed vertices. But I think the algorighm break the "Interior" and make this happen:

lineString.Contains(lineString.InteriorPoint()) == false

[kunlinyu]

@dr-jts

[kunlinyu]

I try to modify the code. But realize the "correct" code may not exist. We use two double variables to represent the coordinate. And two vertices to represent one line segment. But the segment is a mathematical concept about the coordinates set. Which is a continuous open set. Almost non pair of <double, double> lay in the coordinates set mathematically. Because <double, double> is a discrete close set.

We should never use the code below:

lineString.Contains(lineString.InteriorPoint())

but we should use this:

lineString.Distance(lineString.InteriorPoint()) < epsilon

Further more:

points.Distance(points.InteriorPoint()) < epsilon;
lineString.Distance(lineString.InteriorPoint()) < epsilon;
polygon.Contains(polygon.InteriorPoint())  // this is OK

[dr-jts]

Yes, there is a slight inconsistency that you point out, where the "Interior point" of a two-point line does not test being an interior point according to the spatial predicates (using the OGC Mod-2 rule semantics).

Really the InteriorPoint API was not designed to do this - it's just a way to get a point of a LineString which is guaranteed to lie on the line, and be close to the line centroid.