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
contract over nodes connecting edges with differing names/speed #4608
Conversation
Co-authored-by: Kevin Kreiser <kevinkreiser@gmail.com>
…even remove most of edgeinfo stuff for shortcuts, no need to store name, pronunciations etc; adapt all tests which were relying on the fact that names/speed break up shortcuts
@@ -61,6 +61,7 @@ CMakeLists.txt.user | |||
.idea | |||
/.tidytmp | |||
vcpkg*/ | |||
*.log |
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.
doing some graph build experiments and logging to .log. happens frequently, might as well put it in .gitignore
// Get names - they apply over all edges of the shortcut | ||
auto names = edgeinfo.GetNames(); | ||
auto tagged_values = edgeinfo.GetTaggedValues(); | ||
auto linguistics = edgeinfo.GetLinguisticTaggedValues(); | ||
|
||
auto types = edgeinfo.GetTypes(); |
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.
those are not needed anymore either
gurka::findEdge(reader, layout, "highway", end_node, baldr::GraphId{}, 0, true); | ||
for (const auto& pair : | ||
node_pairs{{"A", "C"}, {"C", "A"}, {"H", "J"}, {"J", "H"}, {"J", "L"}, {"L", "J"}}) { | ||
const auto shortcut = gurka::findEdgeByNodes(reader, layout, pair.first, pair.second); |
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.
the findEdges
is tripping now that we don't keep the name for the shortcut anymore. in the end actually could keep it, it has no adverse effects other than a few more lines of redundant code (which is why I removed it)
@@ -67,38 +67,6 @@ TEST(Shortcuts, LoopWithoutShortcut) { | |||
EXPECT_FALSE(shortcut.Is_Valid()) << "Shortcuts found. Check the map."; | |||
} | |||
|
|||
// Here no shortcuts are created. There could be one from A to C with speed 80 but in the opposite |
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 entirely redundant now
…es: seems like it's randomly selecting one of the 2, no matter what the costing says..
@@ -1571,7 +1571,7 @@ TEST(BiDiAstar, test_recost_path) { | |||
)"; | |||
const gurka::ways ways = { | |||
// make ABC to be a shortcut | |||
{"ABC", {{"highway", "primary"}, {"maxspeed", "80"}}}, | |||
{"ABC", {{"highway", "motorway"}, {"maxspeed", "80"}}}, |
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 needed so we still create separate shortcuts
@@ -36,6 +36,9 @@ | |||
* FIXED: fix config generator with thor.costmatrix_allow_second_pass [#4567](https://github.com/valhalla/valhalla/pull/4567) | |||
* FIXED: infinite loop or other random corruption in isochrones when retrieving partial shape of an edge [#4547](https://github.com/valhalla/valhalla/pull/4547) | |||
* FIXED: Aggregation updates: update opposing local idx after aggregating the edges, added classification check for aggregation, and shortcut length changes [#4570](https://github.com/valhalla/valhalla/pull/4570) | |||
* FIXED: Fix segfault in OSRM serializer with bannerInstructions when destination is on roundabout [#4480](https://github.com/valhalla/valhalla/pull/4481) |
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.
those were misplaced in the "Enhancement" section. I didn't make the effort to align them properly time-wise, still better than before
@@ -270,8 +270,8 @@ ComplexRestrictionBuilder CreateComplexRestriction(const OSMRestriction& restric | |||
}; | |||
|
|||
struct Result { | |||
uint32_t forward_restrictions_count; | |||
uint32_t reverse_restrictions_count; | |||
uint32_t forward_restrictions_count = 0; |
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 finally fixes an issue where we report ridiculous numbers for restrictions, like 2 billion restrictions on level 2
@@ -1,4 +1,5 @@ | |||
#include "gurka.h" | |||
#include <boost/format.hpp> |
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.
fixes osx ci
wtf.. just wanted to see the performance improvement and sources_to_targets runs into OOM.. even with a single thread and quite a small bbox for random locations. master is quick and hardly any memory.. can't see yet how that's possible.. EDIT: another fluke.. I had a crazy high max_matrix_distance in my config (5 mio km 😂), which creates a super bloated adjacency queue and does lead to OOM. And I had another instance for master, with another config.. |
this is ready for review now I’ll do some more analysis next week, at least with a country size extract. |
next week more.. |
there's some minor improvement for performance improvement will have an exponential relationship with overall distance, but since bidir a* is pretty directed, it's a pretty scaled down exponential relationship.. I'd expect the p90 routes to have a clearer improvement, e.g. moscow -> madrid or so. diffs for (dijkstra) costmatrix are a lot more pronounced, 20 x 20 random locations in germany over 50 requests show 200 secs (branch) vs 260 secs (master). here the shortcut status for germany-latest:
resulting in a minor size reduction of 15 MB for level tiles (411 MB total) and 4 MB for level 0 tiles (113 MB total). I think this particular one doesn't really need a full planet RAD test yet. It's pretty straight forward and it's fairly easy to see that it won't have any impact on expansion (other than performance) or narration. however, next ones are more sensitive and there I'd run a full planet RAD. what do you think @gknisely @kevinkreiser @dnesbitt61 ? |
// TODO(nils): this test fails currently, because bidir A* has a problem with 2 shortcuts between the | ||
// same nodes: https://github.com/valhalla/valhalla/issues/4609 |
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 disabled test is the reason why the reported coverage is so low BTW.
also, good to mention: if I run this on master (with the appropriate edits to make sure it's 2 shortcuts with different superseded edges between A and E), it fails too.
closing in favor of #4613 |
fixes #4599
most of the changes are concerning tests to play nicely with the new logic. the real changes are just removing a few lines.
I'll share some more insights once I got the last test to build,
astar
has an obnoxious test which is hard to adapt to the new logic..