-
Notifications
You must be signed in to change notification settings - Fork 661
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
indoor routing - data model, data processing #3509
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great to add some gurka unit tests which prove the edges and nodes are getting parsed properly with respect to their tags and values. it doesnt have to be in depth or anything just build the data in gurka and then assert that the properties on the nodes, edges and edgeinfos are set properly. looks great so far!
Thanks @dnesbitt61, @kevinkreiser for the fast feedback. I will add a few gurka tests, to make sure each indoor element gets parsed properly. |
Adding gurka tests:
|
…into indoor_routing
@liyinxiao would you mind putting all of the tests into the same test file? i think it would be slightly more tractable if they were all together in an indoor routing gurka test suite rather than in separate files. you could even build one map with all the features you want to test rather than a different map for each one. since we already have over 100 gurka tests its starting to become difficult to find a particular test 😄 |
Good idea! Re-running gruka tests:
|
@liyinxiao looks like you need to run |
CI tests failed. I looked into it, and when I run
This error occurs with or without my commits. Any suggestions around this error will be appreciated. |
Ah yes, we semi-recently changed the python unit tests and unfortunately it seems we forgot to prints out the test logs when the test fails so you can tell what the heck is going. in this case just manually running
shows:
this is basically saying the tile sizes have changed, which is completely expected in this case. the cool thing is that it means our canned Utrecht osm pbf data must have some ways tagged in such a way that you are parsing them out. unfortunately this makes for a bit of a brittle test. any time we change the data we'll get failures here. i think its ok though we simply update the numbers when we expect them to change. in this case that first test was |
Thanks, it worked! Yeah, your utrecht_netherlands.osm.pbf contains 128 OSM ways with level tag, which are going into the tiles. |
…a which is now fixed
["corridor"] = {["auto_forward"] = "false", ["truck_forward"] = "false", ["bus_forward"] = "false", ["taxi_forward"] = "false", ["moped_forward"] = "false", ["motorcycle_forward"] = "false", ["pedestrian_forward"] = "true", ["bike_forward"] = "false"}, | ||
["elevator"] = {["auto_forward"] = "false", ["truck_forward"] = "false", ["bus_forward"] = "false", ["taxi_forward"] = "false", ["moped_forward"] = "false", ["motorcycle_forward"] = "false", ["pedestrian_forward"] = "true", ["bike_forward"] = "false"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there was just an unfortunate typo here, we needed to set pedestrian_forward
rather than just pedestrian
then later on we derive pedestrian_backward
from forward unless the way is a one way only footway (like an escalator)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching this! don't know how I missed this..
{"Cx", {{"highway", "steps"}, {"indoor", "yes"}, {"level", "1;2"}}}, | ||
{"xy", {{"highway", "steps"}, {"indoor", "yes"}, {"level", "2;3"}}}, | ||
{"yJ", {{"highway", "steps"}, {"indoor", "yes"}, {"level", "3"}}}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i added an alternate path here, you can take the steps rather than use the elevator to get to the 3rd floor
test/gurka/test_indoor.cc
Outdated
const auto* node = graphreader.nodeinfo(node_id); | ||
EXPECT_EQ(node->type(), baldr::NodeType::kBuildingEntrance); | ||
EXPECT_TRUE(node->access() & baldr::kPedestrianAccess); | ||
|
||
node_id = gurka::findNode(graphreader, layout, "I"); | ||
node = graphreader.nodeinfo(node_id); | ||
EXPECT_EQ(graphreader.nodeinfo(node_id)->type(), baldr::NodeType::kElevator); | ||
EXPECT_TRUE(node->access() & baldr::kPedestrianAccess); | ||
} | ||
|
||
TEST_F(Indoor, DirectedEdge) { | ||
baldr::GraphReader graphreader(map.config.get_child("mjolnir")); | ||
|
||
auto directededge = std::get<1>(gurka::findEdgeByNodes(graphreader, layout, "B", "C")); | ||
const auto* directededge = std::get<1>(gurka::findEdgeByNodes(graphreader, layout, "B", "C")); | ||
EXPECT_EQ(directededge->use(), baldr::Use::kSteps); | ||
EXPECT_TRUE(directededge->forwardaccess() & baldr::kPedestrianAccess); | ||
EXPECT_TRUE(directededge->reverseaccess() & baldr::kPedestrianAccess); | ||
|
||
directededge = std::get<1>(gurka::findEdgeByNodes(graphreader, layout, "G", "H")); | ||
EXPECT_EQ(directededge->use(), baldr::Use::kElevator); | ||
EXPECT_TRUE(directededge->forwardaccess() & baldr::kPedestrianAccess); | ||
EXPECT_TRUE(directededge->reverseaccess() & baldr::kPedestrianAccess); | ||
|
||
directededge = std::get<1>(gurka::findEdgeByNodes(graphreader, layout, "K", "L")); | ||
EXPECT_EQ(directededge->use(), baldr::Use::kEscalator); | ||
EXPECT_TRUE(directededge->forwardaccess() & baldr::kPedestrianAccess); | ||
EXPECT_TRUE(directededge->reverseaccess() & baldr::kPedestrianAccess); | ||
|
||
directededge = std::get<1>(gurka::findEdgeByNodes(graphreader, layout, "D", "E")); | ||
EXPECT_EQ(directededge->indoor(), false); | ||
EXPECT_TRUE(directededge->forwardaccess() & baldr::kPedestrianAccess); | ||
EXPECT_TRUE(directededge->reverseaccess() & baldr::kPedestrianAccess); | ||
|
||
directededge = std::get<1>(gurka::findEdgeByNodes(graphreader, layout, "E", "F")); | ||
EXPECT_EQ(directededge->indoor(), true); | ||
EXPECT_TRUE(directededge->forwardaccess() & baldr::kPedestrianAccess); | ||
EXPECT_TRUE(directededge->reverseaccess() & baldr::kPedestrianAccess); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i added some hardening for all of these. what i did first was add teh routing test below but it failed immediately to even route at all. this made me immediately think that the access was messed up, so to check that i hardened all of these tests to see if pedestrians were even allowed on these edges/nodes. it turned out that no they weren't in some cases which was what the lua change fixed
// first route should take the elevator node | ||
auto result = gurka::do_action(valhalla::Options::route, map, {"E", "J"}, "pedestrian"); | ||
gurka::assert::raw::expect_path(result, {"EF", "FG", "GH", "HI", "IJ"}); | ||
|
||
// second route should take the stairs because we gave the elevator a huge penalty | ||
result = gurka::do_action(valhalla::Options::route, map, {"E", "J"}, "pedestrian", | ||
{{"/costing_options/pedestrian/elevator_penalty", "3600"}}); | ||
gurka::assert::raw::expect_path(result, {"EF", "CF", "Cx", "xy", "yJ"}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is pretty straightforward. first we take a route that only has a 5 second penalty to take the elevator, which is obviously cheaper than turning and then takign the steps with their penalty. then we jack up the elevator penalty so that the steps become more appealing
@@ -4503,7 +4555,7 @@ | |||
], | |||
"description": "This tag contains a phonetic guide to pronouncing the official name for a country used in that country if it differs from what is in the name tag" | |||
}, | |||
{ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i appreciate this clean up, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liyinxiao thanks so much for getting the ball rolling on this awesome feature, i did a couple of documentation clean up things but this looks great and it will be great to get to the next step!
Issue
#3469
In this PR, we make the changes to data processing and the data model, basically to get data into the tiles. The indoor elements are routable but all of the maneuvers will be of type "DirectionsLeg_Maneuver_Type_kContinue". Maneuver and narration support (with tests) can be added in another PR.
A few key ideas:
Test plan
Tasklist
Requirements / Relations
Link any requirements here. Other pull requests this PR is based on?