There are 2 type of transfers:
- 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
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