Squash

Author: MarcelloPerathoner

.github/workflows/osrm-backend.yml

@@ -57,7 +57,7 @@ jobs:
 
         cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_CONAN=ON -DENABLE_NODE_BINDINGS=ON ..
         cmake --build . --config Release
-        
+
     # TODO: MSVC goes out of memory when building our tests
     # - name: Run tests
     #   shell: bash
@@ -331,7 +331,7 @@ jobs:
             build_node_package: true
             continue-on-error: true
             node: 22
-            runs-on: macos-15 # arm64 
+            runs-on: macos-15 # arm64
             BUILD_TYPE: Release
             CCOMPILER: clang
             CXXCOMPILER: clang++
@@ -419,7 +419,7 @@ jobs:
         fi
     # See: https://github.com/actions/toolkit/issues/946#issuecomment-1590016041
     # We need it to be able to access system folders while restoring cached Boost below
-    - name: Give tar root ownership 
+    - name: Give tar root ownership
       if: runner.os == 'Linux' && matrix.ENABLE_CONAN != 'ON'
       run: sudo chown root /bin/tar && sudo chmod u+s /bin/tar
 
@@ -429,7 +429,7 @@ jobs:
       id: install-boost
       with:
         boost_version: 1.85.0
-    
+
     - name: Install dev dependencies
       run: |
         # workaround for issue that GitHub Actions seems to not adding it to PATH after https://github.com/actions/runner-images/pull/6499
@@ -577,7 +577,7 @@ jobs:
       uses: actions/upload-artifact@v4
       if: failure()
       with:
-        name: logs
+        name: logs-${{ matrix.name }}
         path: test/logs/
 
     - name: Build Node package

CHANGELOG.md

@@ -1,5 +1,9 @@
+# Changelog
+
 # Unreleased
   - Changes from 6.0.0
+    - Features
+      - ADDED: Pedestrian area routing [#7161](https://github.com/Project-OSRM/osrm-backend/pull/7161)
 
 # 6.0.0
   - Changes from 6.0.0 RC2: None
@@ -182,7 +186,7 @@
       - CHANGED: Docker build, enabled arm64 build layer [#6172](https://github.com/Project-OSRM/osrm-backend/pull/6172)
       - CHANGED: Docker build, enabled apt-get update/install caching in separate layer for build phase [#6175](https://github.com/Project-OSRM/osrm-backend/pull/6175)
       - FIXED: Bump CI complete meta job to ubuntu-20.04 [#6323](https://github.com/Project-OSRM/osrm-backend/pull/6323)
-      - CHANGED: Node packages are now scoped by @project-osrm [#6386](https://github.com/Project-OSRM/osrm-backend/issues/6386)
+      - CHANGED: Node packages are now scoped by \@project-osrm [#6386](https://github.com/Project-OSRM/osrm-backend/issues/6386)
     - Routing:
       - CHANGED: Lazily generate optional route path data [#6045](https://github.com/Project-OSRM/osrm-backend/pull/6045)
       - FIXED: Completed support for no_entry and no_exit turn restrictions. [#5988](https://github.com/Project-OSRM/osrm-backend/pull/5988)
@@ -217,7 +221,7 @@
     - Build:
       - CHANGED: Node binaries now use Github Releases for hosting [#6030](https://github.com/Project-OSRM/osrm-backend/pull/6030)
     - Misc:
-      - FIXED: Upgrade to @mapbox/node-pre-gyp fix various bugs with Node 12/14 [#5991](https://github.com/Project-OSRM/osrm-backend/pull/5991)
+      - FIXED: Upgrade to \@mapbox/node-pre-gyp fix various bugs with Node 12/14 [#5991](https://github.com/Project-OSRM/osrm-backend/pull/5991)
       - FIXED: `valid` type in documentation examples [#5990](https://github.com/Project-OSRM/osrm-backend/issues/5990)
       - FIXED: Remove redundant loading of .osrm.cell_metrics [#6019](https://github.com/Project-OSRM/osrm-backend/issues/6019)
       - CHANGED: Increase PackedOSMIDs size to 34 bits. This breaks the **data format** [#6020](https://github.com/Project-OSRM/osrm-backend/issues/6020)

CONTRIBUTING.md

@@ -1,18 +1,21 @@
-# Everyone
+# Contributing
+
+## Everyone
 
 Please take some time to review our [code of conduct](CODE-OF-CONDUCT.md) to help guide your interactions with others on this project.
 
-# User
+## User
 
 Before you open a new issue, please search for older ones that cover the same issue.
 In general "me too" comments/issues are frowned upon.
 You can add a :+1: emoji reaction to the issue if you want to express interest in this.
 
-# Developer
+## Developer
 
 We use `clang-format` version `15` to consistently format the code base. There is a helper script under `scripts/format.sh`.
 The format is automatically checked by the `mason-linux-release` job of a Travis CI build.
 To save development time a local hook `.git/hooks/pre-push`
+
 ```
 #!/bin/sh
 
@@ -28,16 +31,16 @@ if [ x"$remote" = xorigin  ] ; then
     fi
 fi
 ```
+
 could check code format, modify a local repository and reject push due to unstaged formatting changes.
-Also `pre-push` hook  rejects direct pushes to `origin/master`.
+Also `pre-push` hook rejects direct pushes to `origin/master`.
 
 ⚠️ `scripts/format.sh` checks all local files that match `*.cpp` or `*.hpp` patterns.
 
-
 In general changes that affect the API and/or increase the memory consumption need to be discussed first.
 Often we don't include changes that would increase the memory consumption a lot if they are not generally usable (e.g. elevation data is a good example).
 
-## Pull Request
+### Pull Request
 
 Every pull-request that changes the API needs to update the docs in `docs/http.md` and add an entry to `CHANGELOG.md`.
 Breaking changes need to have a BREAKING prefix. See the [releasing documentation](docs/releasing.md) on how this affects the version.
@@ -57,25 +60,25 @@ If you do have commit access there are in general two accepted styles to merging
 
 1. Make sure the branch is up to date with `master`. Run `git rebase master` to find out.
 2. Once that is ensured you can either:
-  - Click the nice green merge button (for a non-fast-forward merge)
-  - Merge by hand using a fast-forward merge
+
+- Click the nice green merge button (for a non-fast-forward merge)
+- Merge by hand using a fast-forward merge
 
 Which merge you prefer is up to personal preference. In general it is recommended to use fast-forward merges because it creates a history that is sequential and easier to understand.
 
-# Maintainer
+## Maintainer
 
-## Doing a release
+### Doing a release
 
 There is an in-depth guide around how to push out a release once it is ready [here](docs/releasing.md).
 
-## The API
+### The API
 
 Changes to the API need to be discussed and signed off by the team. Breaking changes even more so than additive changes.
 
-## Milestones
+### Milestones
 
 If a pull request or an issue is applicable for the current or next milestone, depends on the target version number.
 Since we use semantic versioning we restrict breaking changes to major releases.
 After a Release Candidate is released we usually don't change the API anymore if it is not critical.
 Bigger code changes after a RC was released should also be avoided.
-

Doxyfile.in

@@ -13,14 +13,14 @@ QUIET                  = YES
 
 INPUT                  = @CMAKE_CURRENT_SOURCE_DIR@
 USE_MDFILE_AS_MAINPAGE = @CMAKE_CURRENT_SOURCE_DIR@/README.md
-FILE_PATTERNS          = *.h *.hpp *.c *.cc *.cpp *.md
+FILE_PATTERNS          = *.h *.hpp *.c *.cc *.cpp *.md *.dox
 RECURSIVE              = YES
 
 EXCLUDE                = @CMAKE_CURRENT_SOURCE_DIR@/third_party \
                          @CMAKE_CURRENT_SOURCE_DIR@/build \
                          @CMAKE_CURRENT_SOURCE_DIR@/node_modules \
                          @CMAKE_CURRENT_SOURCE_DIR@/unit_tests \
-			 @CMAKE_CURRENT_SOURCE_DIR@/benchmarks \
+                         @CMAKE_CURRENT_SOURCE_DIR@/benchmarks \
                          @CMAKE_CURRENT_SOURCE_DIR@/features
 
 SOURCE_BROWSER         = YES
@@ -40,5 +40,4 @@ CALLER_GRAPH           = YES
 DOT_IMAGE_FORMAT       = svg
 INTERACTIVE_SVG        = YES
 DOT_GRAPH_MAX_NODES    = 500
-DOT_TRANSPARENT        = YES
 DOT_MULTI_TARGETS      = YES

README.md

@@ -1,11 +1,11 @@
-## Open Source Routing Machine
-
+# Open Source Routing Machine
 
 [![osrm-backend CI](https://github.com/Project-OSRM/osrm-backend/actions/workflows/osrm-backend.yml/badge.svg)](https://github.com/Project-OSRM/osrm-backend/actions/workflows/osrm-backend.yml) [![Discord](https://img.shields.io/discord/1034487840219860992)](https://discord.gg/es9CdcCXcb)
 
 High performance routing engine written in C++ designed to run on OpenStreetMap data.
 
 The following services are available via HTTP API, C++ library interface and NodeJs wrapper:
+
 - Nearest - Snaps coordinates to the street network and returns the nearest matches
 - Route - Finds the fastest route between coordinates
 - Table - Computes the duration or distances of the fastest route between all pairs of supplied coordinates
@@ -18,6 +18,7 @@ To quickly try OSRM use our [demo server](http://map.project-osrm.org) which com
 For a quick introduction about how the road network is represented in OpenStreetMap and how to map specific road network features have a look at [the OSM wiki on routing](https://wiki.openstreetmap.org/wiki/Routing) or [this guide about mapping for navigation](https://web.archive.org/web/20221206013651/https://labs.mapbox.com/mapping/mapping-for-navigation/).
 
 Related [Project-OSRM](https://github.com/Project-OSRM) repositories:
+
 - [osrm-frontend](https://github.com/Project-OSRM/osrm-frontend) - User-facing frontend with map. The demo server runs this on top of the backend
 - [osrm-text-instructions](https://github.com/Project-OSRM/osrm-text-instructions) - Text instructions from OSRM route response
 - [osrm-backend-docker](https://github.com/project-osrm/osrm-backend/pkgs/container/osrm-backend) - Ready to use Docker images
@@ -28,7 +29,6 @@ Related [Project-OSRM](https://github.com/Project-OSRM) repositories:
 
 - [Hosted documentation](http://project-osrm.org)
 - [osrm-routed HTTP API documentation](docs/http.md)
-- [libosrm API documentation](docs/libosrm.md)
 
 ## Contact
 
@@ -41,6 +41,7 @@ Related [Project-OSRM](https://github.com/Project-OSRM) repositories:
 The easiest and quickest way to setup your own routing engine is to use Docker images we provide.
 
 There are two pre-processing pipelines available:
+
 - Contraction Hierarchies (CH)
 - Multi-Level Dijkstra (MLD)
 
@@ -86,13 +87,13 @@ After adding yourself to the `docker` group make sure to log out and back in aga
 
 We support the following images in the Container Registry:
 
-Name | Description
------|------
-`latest` | `master` compiled with release flag
-`latest-assertions` | `master` compiled with with release flag, assertions enabled and debug symbols
-`latest-debug` | `master` compiled with debug flag
-`<tag>` | specific tag compiled with release flag
-`<tag>-debug` | specific tag compiled with debug flag
+| Name                | Description                                                                    |
+| ------------------- | ------------------------------------------------------------------------------ |
+| `latest`            | `master` compiled with release flag                                            |
+| `latest-assertions` | `master` compiled with with release flag, assertions enabled and debug symbols |
+| `latest-debug`      | `master` compiled with debug flag                                              |
+| `<tag>`             | specific tag compiled with release flag                                        |
+| `<tag>-debug`       | specific tag compiled with debug flag                                          |
 
 ### Building from Source
 
@@ -166,7 +167,6 @@ For usage details have a look [these API docs](docs/nodejs/api.md).
 
 An exemplary implementation by a 3rd party with Docker and Node.js can be found [here](https://github.com/door2door-io/osrm-express-server-demo).
 
-
 ## References in publications
 
 When using the code in a (scientific) publication, please cite

cucumber.js

@@ -1,7 +1,7 @@
 module.exports = {
     default: '--strict --tags ~@stress --tags ~@todo --tags ~@mld --require features/support --require features/step_definitions',
-    ch: '--strict --tags ~@stress --tags ~@todo --tags ~@mld -f progress --require features/support --require features/step_definitions',
+    ch: '--strict --tags ~@stress --tags ~@todo --tags ~@mld --require features/support --require features/step_definitions',
     todo: '--strict --tags @todo --require features/support --require features/step_definitions',
     all: '--strict --require features/support --require features/step_definitions',
-    mld: '--strict --tags ~@stress --tags ~@todo --tags ~@ch --require features/support --require features/step_definitions -f progress'
+    mld: '--strict --tags ~@stress --tags ~@todo --tags ~@ch --require features/support --require features/step_definitions'
 };

docs/areas.md

@@ -0,0 +1,102 @@
+# How to route through pedestrian areas {#pedestrian_areas}
+
+@sa AreaManager
+
+How to route through pedestrian areas, or any other area where you can travel freely in
+all directions.
+
+OSRM routes over the inside of an area by "meshing" it, that is, by adding a virtual way
+between every pair of entry points of the area. These virtual ways always follow lines
+of sight and only use existing nodes. An entry point is where another way connects to
+the area.
+
+## Configuration
+
+This feature is EXPERIMENTAL and you must opt-in to it. To opt-in, you must declare the
+algorithm to be used for area meshing. In your LUA profile properties insert this line:
+
+```lua
+function setup()
+  ...
+  return {
+    properties = {
+      ...
+      area_meshing_algorithm = 'visgraph+dijkstra', -- << insert this line
+      ...
+    },
+  }
+end
+```
+
+Note: Only one algorithm is available currently.
+
+All areas to be meshed must be registered with the @ref AreaManager. Areas are mapped
+either as a closed way or a multipolygon relation. Both types must be configured
+separately.
+
+### process_relation(profile, relation, relations)
+
+To mesh a multipolygon relation you must register it in your @ref process_relation
+function. The process_relation function is called for every relation in the input file.
+You'll have to create the function like this:
+
+```lua
+function process_relation(profile, relation, relations)
+  if relation:has_tag('type', 'multipolygon') and relation:has_tag('highway', 'pedestrian') then
+    -- register the relation
+    area_manager:relation(relation)
+  end
+end
+
+-- don't forget to return the process_relation function from the profile
+return {
+  setup = setup,
+  process_way =  process_way,
+  process_node = process_node,
+  process_relation = process_relation, -- << add this
+  ...
+}
+```
+
+### process_way(profile, way, result, relations)
+
+To mesh a closed way you must register it in your @ref process_way function. The
+process_way function is called for every way in the input file. Insert following lines
+into your process_way function:
+
+```lua
+function process_way(profile, way, result, relations)
+  ...
+  if way:has_tag('highway', 'pedestrian') and way:has_true_tag('area') then
+    -- register the way
+    area_manager:way(way)
+  end
+  ...
+end
+```
+
+(Note that open ways cannot be meshed and will be ignored.)
+
+Some support for multipolygons is needed in this function too. Since the member ways of
+a multipolygon relation are untagged, and OSRM discards untagged ways, you must copy at
+least the defining tag (and the name, if you want guidance) from the relation to the
+way:
+
+```lua
+function process_way(profile, way, result, relations)
+  ...
+  for _, rel_id in pairs(area_manager:get_relations(way)) do
+    -- if this way is a member of a previously registered relation
+    -- we have to set at least one defining tag, else OSRM will discard it
+    local rel = relations:relation(rel_id)
+    data.highway = rel:get_value_by_key('highway')
+    -- also copy the name tag(s) from the relation the to way
+    WayHandlers.names(profile, rel, result, data)
+  end
+  ...
+end
+```
+
+At this point you have a basic configuration. Refer to @ref AreaManager for further
+details. A complete profile example is found in the file:
+[profiles/foot_area.lua](../profiles/foot_area.lua).