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
Transfers at the same stop (e.g., get out, wait for a bit, get on again)
Transfers where you have to walk to another stop
Case 1: transfer at same stop
We should add 1 minute of transfer time by default.
This case can be detected through other properties: different gtfs:trip, we're taking a different connection that the previous connection's lc:nextConnection, different gtfs:route, et cetera. We can support different ways. If nothing is set, we will always assume it's the same stop.
Case 2: walk to a different stop
We should add an amount of time which is retrieved in a certain way and which depends on user configuration: e.g., someone in a wheelchair, someone with a foldable bike, a sprinter, etc.
This is commonly referred to as "footpaths". Calculating footpaths is an intensive job and is a data problem on its own. It's not a problem we should be fixing in csa.js. Therefore we should have a hook which can be used by users of this library to give a footpath for the stations we're using in the queries.
Trade-off
Just in time information vs. performance: footpaths may become a bottleneck if not preloaded in memory
The text was updated successfully, but these errors were encountered:
There are 2 type of transfers:
Case 1: transfer at same stop
We should add 1 minute of transfer time by default.
This case can be detected through other properties: different gtfs:trip, we're taking a different connection that the previous connection's lc:nextConnection, different gtfs:route, et cetera. We can support different ways. If nothing is set, we will always assume it's the same stop.
Case 2: walk to a different stop
We should add an amount of time which is retrieved in a certain way and which depends on user configuration: e.g., someone in a wheelchair, someone with a foldable bike, a sprinter, etc.
This is commonly referred to as "footpaths". Calculating footpaths is an intensive job and is a data problem on its own. It's not a problem we should be fixing in csa.js. Therefore we should have a hook which can be used by users of this library to give a footpath for the stations we're using in the queries.
Trade-off
Just in time information vs. performance: footpaths may become a bottleneck if not preloaded in memory
The text was updated successfully, but these errors were encountered: