You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
varhelpers=require("@turf/helpers");varlength=require('@turf/length').defaultvarPathFinder=require("geojson-path-finder");vargeojson=require("./data/CA_Sec_A_tracks.json");// Each degree of latitude is 111km, so precision of .001 snaps vertices within 100mvarpathFinder=newPathFinder(geojson,{precision: 0.001});// Same linevarstart=Point([-116.467875,32.590604]);varend=Point([-116.503565,32.607618]);varpath=pathFinder.findPath(start,end);// # Different routesvarstart=Point([-116.467078,32.593434]);varend=Point([-116.523801,32.979053]);varpath=pathFinder.findPath(start,end);
I found that the default precision (.00001) was too small. I think precision of .001 degrees should be fine, although it would be ideal if alternates had an exact point where they intersected the PCT line.
By default, geojson-path-finder uses turf.distance as the weight function, and the returned distance is in kilometers.
Didn't check start/end points far off the tracks in the GeoJSON.
The difference between turf.length (on the resulting LineString of path.path's coordinates) and path.weight is like .6%, which might just be from floating point rounding? Not sure, but it's close enough to definitely not calculate path length again.
Cumulative elevation change
path.path reports the same coordinates that are passed into it. So if there are elevation values in the original GeoJSON LineStrings, there will be elevation values in the returned coordinates. This means that the easiest way to get cumulative elevation gain/loss to a point is to sum up the third values of the coords.
Here's JS code to calculate elevation change from an array of coordinates, where each coordinate is an array of [lon, lat, elevation]. elevChangeReduce should be faster than elevChangeFilter because the former only makes two passes through the list of coordinates instead of 4. After finding out the importance of setting the initial value in Array.prototype.reduce, they give the same result.
// Given an array of coordinates, find the marginal elevation// gain/loss of each segment// [1, 3, 2, 5] -> [2, -1, 3]functiongetIncrementalDifference(coords){constchanges=coords.map((point,index)=>{constnextPoint=coords[index+1];if(nextPoint){returnnextPoint[2]-point[2]}})returnchanges;}functionelevChangeReduce(coords){constchanges=getIncrementalDifference(coords)constpositiveReducer=(acc,cur)=>{if(cur>0){returnacc+cur}else{returnacc}}constnegativeReducer=(acc,cur)=>{if(cur<0){returnacc+cur}else{returnacc}}// Note: You need to set 0 as the initial value, or else the initial value is the first element!positiveSum=changes.reduce(positiveReducer,0)negativeSum=changes.reduce(negativeReducer,0)return[positiveSum,negativeSum]}functionelevChangeFilter(coords){constchanges=getIncrementalDifference(coords)constpositiveVals=changes.filter(val=>val>0)constnegativeVals=changes.filter(val=>val<0)constpositiveSum=positiveVals.reduce((acc,cur)=>acc+cur)constnegativeSum=negativeVals.reduce((acc,cur)=>acc+cur)return[positiveSum,negativeSum]}elevChangeReduce(coords)// -> [ 2875.0599999999995, -2209.789999999999 ]elevChangeFilter(coords)// -> [ 2875.0599999999995, -2209.789999999999 ]
The text was updated successfully, but these errors were encountered:
GeoJSON Path finder is very helpful.
Usage
I found that the default precision (
.00001
) was too small. I think precision of .001 degrees should be fine, although it would be ideal if alternates had an exact point where they intersected the PCT line.By default,
geojson-path-finder
usesturf.distance
as the weight function, and the returned distance is in kilometers.Didn't check start/end points far off the tracks in the GeoJSON.
The difference between
turf.length
(on the resulting LineString ofpath.path
's coordinates) andpath.weight
is like .6%, which might just be from floating point rounding? Not sure, but it's close enough to definitely not calculate path length again.Cumulative elevation change
path.path
reports the same coordinates that are passed into it. So if there are elevation values in the original GeoJSON LineStrings, there will be elevation values in the returned coordinates. This means that the easiest way to get cumulative elevation gain/loss to a point is to sum up the third values of the coords.Here's JS code to calculate elevation change from an array of coordinates, where each coordinate is an array of
[lon, lat, elevation]
.elevChangeReduce
should be faster thanelevChangeFilter
because the former only makes two passes through the list of coordinates instead of 4. After finding out the importance of setting the initial value inArray.prototype.reduce
, they give the same result.The text was updated successfully, but these errors were encountered: