Area Routing

[MarcelloPerathoner]

This PR provides routing over areas.

It builds a visibility graph of the area, then runs dijkstra from each entry point to reduce the number of edges, then adds the remaining edges as ways to the router.

  

Documentation

Issue

Fixes #64 #2655 #7146

Tasklist

• CHANGELOG.md entry (How to write a changelog entry)
• update relevant Wiki pages
• add tests (see testing documentation)
• review
• adjust for comments

TODO

• entrances to buildings along the perimeter of the area,
• PT stations in the middle of the area,
• alternate algorithms, eg. retraction.

[DennisOSRM]

cool feature!

seems the linked screenshots don't show tho in the PR

[MarcelloPerathoner]

seems the linked screenshots don't show tho in the PR

I re-uploaded them. Do they show now?

[DennisOSRM]

seems the linked screenshots don't show tho in the PR

I re-uploaded them. Do they show now?

They do. Thanks a lot

[DennisOSRM]

Had a first look at the change. First of all, great feature! I think this has been on the todo list for more than 10 years 😀

The main question I have is that we should probably own the Dijkstra implementation that is used and not fall back to boost.

[MarcelloPerathoner]

Do we have a general dislike for boost? Just asking ...

[DennisOSRM]

Do we have a general dislike for boost? Just asking ...

Perhaps 😉

Also, routing is our expertise and we should own all routing logic.

[MarcelloPerathoner]

Dijkstra in itself is trivial to implement. The hardest piece is the priority queue, if we don't want to take the one in boost. They use a 4-ary heap. A binary heap will do for our problem sizes. I will look into this.

[DennisOSRM]

The good news is that heap implementations already exist in our code base:

• include/util/binary_heap.hpp
• include/util/d_ary_heap.hpp

[DennisOSRM]

just tweaked the settings s.t. GitHub Actions should now run automatically on push.

[MarcelloPerathoner]

I have now implemented Dijkstra and a binary heap that works with it. The d-ary heap in include/util/d_ary_heap.hpp looks like it could be coaxed into service too, but it is completely undocumented.

Shouldn't we drop / update the macos-x64 build since it is based on apple-clang-14? All other builds use clang >= 16.

[DennisOSRM]

Let me know when the change is ready for reviewing. 😉