Distance and Ramer–Douglas–Peucker functions. #791
Conversation
Move distance functions from the lineFeature to the util module, making the function names more explicit. Add a `rdpLineSimply` function for reducing the complexity of a line or polygon. Add a `rdpSimplifyData` method to the line and polygon features for doing this while setting data.
manthey
force-pushed
the
distance-functions
branch
from
c4a53de to
c30916a
Compare
| * | ||
| * @param {array} data A new data array. | ||
| * @param {number} [tolerance] The maximum variation allowed in map.gcs | ||
| * units. A value of zero will only remove perfectly colinear points. If |
There was a problem hiding this comment.
I am wondering if the unit should be pixels for the tolerance?
There was a problem hiding this comment.
It defaults to 0.5 pixel at the current zoom. But if you are overriding this, you might not want the tolerance to be dependent on the current scale of the map. So this can be made into current zoom pixels via map.unitsPerPixel(map.zoom()) * <tolerance in pixels>, or it can be in gcs units.
There was a problem hiding this comment.
so the user has to pass t = map.unitsPerPixel(map.zoom()) * or else we will use map.unitsPerPixel(map.zoom()) * 0.5?
There was a problem hiding this comment.
Yes. As other examples, perhaps you want to zoom in to level 16 and control the tolerance to 0.25 pixels visible there, in which case you would use map.unitsPerPixel(16) * 0.25, or perhaps you want limit the tolerance to some 50 meters, in which case this is just 50. By not forcing it to be in current pixels, it gives flexibility.
There was a problem hiding this comment.
I see. I am wondering if we could auto compute it given some initial parameter in a separate PR (as a new feature), not needed now, but wanted to mention it.
| * @param {geo.geoPosition} pt2 The second point. | ||
| * @returns {number} The distance squared. | ||
| */ | ||
| distance2dSquared: function (pt1, pt2) { |
There was a problem hiding this comment.
should we just have distance2d? It may be worth using turfjs? (https://turfjs.org/)
There was a problem hiding this comment.
If we return the non-squared versions, there is a lot of needless sqrt function calls, since mostly we are trying to find the smallest value.
There was a problem hiding this comment.
turfjs internally does everything on a spheroid. Their distance function, for instance, is much heavier because of this, always making multiple trigonometric function calls. Since we are usually already in a 2d spatial domain, this is vastly slower (and doesn't extend to pixel-space examples in a rational manner, or ellipsoids that are highly eccentric, etc.).
There was a problem hiding this comment.
sure, perhaps in the future we could consider it if we need more of these functions.
| * @param {geo.geoPosition} line2 The other end of the line. | ||
| * @returns {number} The distance squared. | ||
| */ | ||
| distance2dToLineSquared: function (pt, line1, line2) { |
There was a problem hiding this comment.
same here I think distance2dToLine is probably more useful?
|
|
||
| // use pixel space for ease of picking tolerance values in tests | ||
| map.gcs('+proj=longlat +axis=enu'); | ||
| map.ingcs('+proj=longlat +axis=esu'); |
There was a problem hiding this comment.
nice that we are using different gcs here
Move distance functions from the lineFeature to the util module, making the function names more explicit. Add a
rdpLineSimplyfunction for reducing the complexity of a line or polygon. Add ardpSimplifyDatamethod to the line and polygon features for doing this while setting data.