Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix the accessibility of transit connect edges #3948

Merged
merged 2 commits into from
Feb 3, 2023

Conversation

kevinkreiser
Copy link
Member

So the transit routing test was failing because the transit connect edges (the ones from the street network to the transit network) are marked with no pedestrian (or any other) access. This was because during the transit gtfs feed ingestion we forgot to set the in/egress node traversability (this can be either none (default), both, entrance or exit). at the moment the ingestion doesnt have the ability to differentiate between entrance and exit so the fix here is to simply set to both (the new default). transitland provided a "directionality" on in/egresses and it is unclear exactly where this comes from.

looking at the spec it might come from pathways.txt::is_unidirectional where the spec can tell you between two stops (in this case stop means any of the 4 types: platform, station, in/egress/generic or boarding area) what directions you can walk (the oneway-ness of edges within the station). from that we could determine that if from a an in/egress to a station node you can only go forward and not reverse then it must be ingress-only and not egress, similar story for from station to in/egress must be egress-only and not ingress. we can and should add a TODO to parse this information in the first phase of ingestion so that in the future we abide by it. for now it is enough to allow access in my opinion.

anyway by allowing access at these nodes, we propogate (in transit builder) that access onto the transit connection edges we create. because these node traversibilities were not set, and their default is kNone, when we made the transit connection edges they also got the same access, which is to say no access. costing then couldnt use them to find transit stations in the data and so the first check in the multimodal algorithm failed with: i dont see any freaking transit stations in your data wtf.

with this fixed the algorithm now says it just cant find a path, which is likely to do with schedule information. there are 3 things to check there:

  1. either in the feed to tiles conversion is still screwing up the dates (have to check pivot date and numerical conversions as well as schedule validity dates)
  2. the test data we put in the test feed is wrong
  3. or the test request specifies the date wrong

const auto& tn = transit.nodes(i);
stops.insert(tn.onestop_id());
if (tn.type() == static_cast<uint32_t>(NodeType::kTransitEgress)) {
EXPECT_NE(tn.traversability(), static_cast<uint32_t>(Traversability::kNone));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pbf better have it set

@@ -405,6 +409,10 @@ TEST(GtfsExample, MakeTile) {
graph_tile_ptr tile = reader.GetGraphTile(graphid);
for (const auto& edge : tile->GetDirectedEdges()) {
uses[edge.use()]++;
if (edge.use() == Use::kTransitConnection) {
EXPECT_TRUE((edge.forwardaccess() & kPedestrianAccess) ||
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resulting connect edge better have access

Copy link
Member

@nilsnolde nilsnolde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and one closer:) thx!!

@nilsnolde nilsnolde merged commit 3fac970 into master Feb 3, 2023
@nilsnolde nilsnolde deleted the kk_fix_transit_connect_access branch February 3, 2023 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants