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
Is it possible make so edgeDataReducer or its result can take forward or backward into consideration like the weight function can.
I am creating an algoritm to reconstruct the path parts back to the original geoJson for more detailed path instructions and are storing the ids of the geoJson in an array in the edgeDataReducer (and handles duplicates etc).
The edgeData returned with the path will then look something like [1, 2, [3, 4], 5] and when taking the path in reverse [5, [3, 4], 2, 1] where the nested array is the result of an edge data reduction. The problem is that the reduced edge data does not reflect the direction, so trying to reconstruct the path requires an trial and error approach where all nested arrays are tried in both directions until the correct combination is found.
The text was updated successfully, but these errors were encountered:
It sounds like an oversight in the current design that it does not take direction into account, probably because my requirement for edge datas came up in a separate project from where I needed the differing forward/backward cost for edges.
So, yes, I think this is something that would make sense to implement. Having said that, I don't really plan on working on geojson-path-finder at the moment, so it's not likely I will do it myself for now. Happy to accept PRs though (although I'm apparently very slow to react to communications here... sorry about that).
Is it possible make so edgeDataReducer or its result can take forward or backward into consideration like the weight function can.
I am creating an algoritm to reconstruct the path parts back to the original geoJson for more detailed path instructions and are storing the ids of the geoJson in an array in the edgeDataReducer (and handles duplicates etc).
The edgeData returned with the path will then look something like
[1, 2, [3, 4], 5]
and when taking the path in reverse[5, [3, 4], 2, 1]
where the nested array is the result of an edge data reduction. The problem is that the reduced edge data does not reflect the direction, so trying to reconstruct the path requires an trial and error approach where all nested arrays are tried in both directions until the correct combination is found.The text was updated successfully, but these errors were encountered: