New module @turf/point-to-line-distance

[stebogit]

Following up #906 (comment)

/**
 * Returns the minimum distance between a {@link Point} and a {@link LineString}, being the distance from a line the
 * minimum distance between the point and any segment of the `LineString`.
 *
 * @name pointToLineDistance
 * @param {Feature<Point>|Array<number>} point Feature or Geometry
 * @param {Feature<LineString>|Array<Array<number>>} line GeoJSON Feature or Geometry
 * @param {string} [units=kilometers] can be degrees, radians, miles, or kilometers
 * @param {boolean} [mercator=false] if distance should be on Mercator or WGS84 projection
 * @returns {number} distance between point and line
 * @example
 * var pt = turf.point([0, 0]);
 * var line = turf.lineString([[1, 1],[-1, 1]);
 *
 * var d = pointToLineDistance(pt, line, 'miles');
 * //=69.11854715938406
 */
module.exports = function (point, line, units, mercator) {

Note: This module, like probably all the other distance related ones, calculates distance with a little error, due to the current Earth radius value (see discussion #715).

This module might allow a faster computation of @turf/point-on-line. I'll try work on that to test any improvement.

Also, we can also use the following functions (thanks @tmcw) to implement the @turf/wgs84-to-mercator module:

/**
 * Convert lon/lat values to 900913 x/y.
 * from https://github.com/mapbox/sphericalmercator
 *
 * @private
 * @param {Array<number>} lonLat WGS84 point
 * @returns {Array<number>} Mercator [x, y] point
 */
function toMercator(lonLat) { ...

/**
 * Convert 900913 x/y values to lon/lat.
 * from https://github.com/mapbox/sphericalmercator
 *
 * @private
 * @param {Array<number>} xy Mercator [x, y] point
 * @returns {Array<number>} WGS84 [lon, lat] point
 */
function toWGS84(xy) { ...

[stebogit]

I don't get why this is failing... 😞
It has something to do with eslint, but I don't understand where

[rowanwins]

You broke it @stebogit - we're all doomed!

[stebogit]

Now, I fixed several issues updating other turf modules dependencies (don't know why that was necessary since I merged master...), but now this fails on Travis (not on my computer) in few tests due to decimal approximation.
How come the result is different? What might be different?

[DenisCarriere]

@stebogit New error, looks like you might need to add a round() or truncate() to the test cases:

    not ok 8 city-segment-projected1
      ---
        operator: deepEqual
        expected: 3.589782772179696
        actual:   3.589782772179697

[stebogit]

@DenisCarriere Could the approximation in the calculation result depend on the nose version? Cause as I said in my computer they all pass.

[stebogit]

🎉

[DenisCarriere]

Published under v4.0.0 will be published in v4.7.0 when I do the full publish