NearestPointOnLine is not on the line

[MKuranowski]

Recall that Section 3.3.1 of RFC 7946 defines a segment of a LineString not as a geodesic, but rather a straightforward linear interpolation between the coordinates of both points:

[...] every point on a line [...] can be calculated as

F(lon, lat) = (lon0 + (lon1 - lon0) * t, lat0 + (lat1 - lat0) * t)

with t being a real number greater than or equal to 0 and smaller
than or equal to 1. Note that this line may markedly differ from the
geodesic path along the curved surface of the reference ellipsoid.

turf.nearestPointOnLine(
  turf.lineString([[15,0],[0,90]]),
  [13.5, 52],
);

Gives a point with coordinates [ 14.999999999999996, 52.00952654924218 ]; which is not on the provided LineString, as there is no value for t that would satisfy the specified behavior. Looking at longitudes, t would be 0, but looking at latitudes t would have to be around 0.57. And 0 ≠ 0.57.

It looks to me as if #2717 was merged with disregard as to what a GeoJSON line actually is. If Turf wants to deviate from the spec, it should make that clear, and furthermore, be consistent with that assumption. Most other functions actually seem to follow the GeoJSON definition of line segments (#3053; afaik also union/difference family of functions).

[smallsaucepan]

Thanks for this @MKuranowski. You've highlighted an interesting point. The spec seems slightly conflicted in that it specifies WGS84 as the only CRS to use (geographic with values being angles) and then defines a line in an entirely planar way. The quote:

Note that this line may markedly differ from the geodesic path along the curved surface of the reference ellipsoid.

might be an attempt to address that tension. Which all might be a hold over from earlier drafts when GeoJson let you bring your own CRS to the table.

Looking at that section of the spec from a different point of view, it's possibly an attempt to describe a limitation of the format, rather than dictating the types of operations libraries can use it for. A way of saying GeoJson doesn't offer any way to define a "curve" like a bezier. Straight (shortest path) lines across whatever reference you decide on (which the anointed CRS indirectly infers should be an ellipsoid) are all you can do.

With that in mind, my take is that Turf is a geospatial library that uses GeoJson as its data format of choice.

Turf uses a variety of methods to perform its functions. With simple operations like distance we use spherical maths to provide the most accurate results, esp over long distances or at high latitudes. For others like union or containment we have to fall back to projecting and calculating in planar terms because the spherical math would be simply bonkers.

Where you're 100% on the money is that it isn't clear from the documentation when we're doing which. This is on the backlog to improve.

[MKuranowski]

Having slept on that, I think ultimately yes, the overarching issue is the inconsistency and lack of documentation.

If nearestPointOnLine assuming great circle arcs is the desired behavior, then #3053 should be reopned. One function claims a point is on a line, and the other claims it's way off.

The linear-interpolation definition of a line segment from the GeoJSON spec creates a bizarre, non-standard curve. I think the only proper way to find the length of such a curve is to integrate it, and to find a nearest point on it is to run a Newton-esque or golden-section search. That's just, for the lack of a better word, stupid. Although, I think it does allow you to perform boolean operations as-if the coordinates were on an Cartesian plane.

What's even more strange, WKT/WKB and GML also define line segments as linearly interpolated, OSM seems to be the only one defining a segment as a great circle arc; KML works in 3D so it does something different.

• WKT/WKB: https://docs.ogc.org/is/06-103r4/06-103r4.pdf#page=21

  A LineString is a Curve with linear interpolation between Points

  There are no other subtypes of Curves.

• GML: https://docs.ogc.org/is/07-036r1/07-036r1.pdf#page=72

  A gml:LineString is a special curve that consists of a single segment with linear interpolation (see D.3.5). It is defined by two or more coordinate tuples, with linear interpolation between them.

• OSM: https://wiki.openstreetmap.org/wiki/Way#Mathematical_note

  Each segment is assumed to be the shortest line on the Earth's surface (negating terrain issues) connecting its two ends, i.e. a geodesic on the figure of the Earth used.

• KML (https://docs.ogc.org/is/12-007r2/12-007r2.html#17) has multiple modes, but the default one is to cut through Earth's surface

  A straight line segment L in the 3D WGS 84 geocentric coordinate reference system (http://www.opengis.net/def/crs/EPSG/0/4978)

Adding more to the confusion is that mapping libraries also don't follow the GeoJSON spec. Since they draw "straight" lines on the Mercator projection, they draw rhumb lines. This results in 3 different interpretations of a line segment, which are all different: https://jsfiddle.net/hyuewaz8/.

[smallsaucepan]

Can't really comment on what other products or standards do. I'm sure they all have their reasons or rationales.

Wrt to Turf, if you find a situation where the documentation is ambiguous or the library is being internally inconsistent, please raise an issue. That comes with the caveat that (as mentioned above) similar sounding operations like nearestWhateverToWhatever may have to use different methods depending on what the "Whatevers" are.

In those cases though we should at least explain that in our documentation, so appreciate in advance any of those you're able to pinpoint 👍