Do not generate intermediate .osrm file in osrm-extract. #6354

SiarheiFedartsou · 2022-08-31T18:44:28Z

Issue

closes #6329

Tasklist

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

Requirements / Relations

Link any requirements here. Other pull requests this PR is based on?

SiarheiFedartsou · 2022-09-01T16:08:32Z

Some things to discuss:

Now in order to generate .osrm file user has to pass --dump-nbg-graph flag to osrm-extract. Is it a good naming? Should we may be make it default and allow to disable by CLI option? I can imagine that someone somehow relies on this file and uses osrm-components with it(it is really low chance IMO, but still).
The only place where this .osrm can be used is osrm-components tool which is as I understand purely for debug, so IMO .osrm feels a bit "loud" name for such kind of files. May be rename it to something?
We suggest to pass this .osrm file everywhere in the docs as if it is really used as input file(e.g. ./osrm-customize ./berlin-latest.osrm). Actually it is just a base name. So I suggest to just remove this extension from everywhere: like ./osrm-partition ./berlin-latest. But for backward compatibility leave the ability to work if it was passed in the old way(we may emit warning if it used this way). I can imagine that a lot of people have working pipelines with this .osrm in them.

@mjjbell WDYT?

SiarheiFedartsou · 2022-09-01T16:09:01Z

.github/workflows/osrm-backend.yml

-          docker run $MEMORY_ARGS -t -v "${PWD}:/data" "${TAG}" osrm-customize /data/berlin-latest.osrm
-          docker run $MEMORY_ARGS --name=osrm-container -t -p 5000:5000 -v "${PWD}:/data" "${TAG}" osrm-routed --algorithm mld /data/berlin-latest.osrm &
+          docker run $MEMORY_ARGS -t -v "${PWD}:/data" "${TAG}" osrm-extract --dump-nbg-graph -p /opt/car.lua /data/berlin-latest.osm.pbf
+          docker run $MEMORY_ARGS -t -v "${PWD}:/data" "${TAG}" osrm-components /data/berlin-latest.osrm /data/berlin-latest.geojson


Added kind of smoke test for osrm-components.

SiarheiFedartsou · 2022-09-01T16:09:43Z

include/extractor/extraction_containers.hpp

@@ -75,6 +72,8 @@ class ExtractionContainers
    std::vector<InputTrafficSignal> external_traffic_signals;
    TrafficSignals internal_traffic_signals;

+    std::vector<NodeBasedEdge> normal_edges;


Not sure about naming here, tbh haven't tried to dive into the logic there, just made it available from outside.

I would go with used_edges, given that's the log message at the point of generation
https://github.com/Project-OSRM/osrm-backend/pull/6354/files#diff-e52614280a87ada8afc739a67e55e7d2cc111d11a9f23fc429b7c2d20dd1d8d7R861

SiarheiFedartsou · 2022-09-01T16:09:55Z

include/extractor/extraction_containers.hpp

@@ -84,11 +83,12 @@ class ExtractionContainers

    std::vector<InputManeuverOverride> external_maneuver_overrides_list;
    std::vector<UnresolvedManeuverOverride> internal_maneuver_overrides;
+    std::unordered_set<NodeID> internal_barrier_nodes;


The same about naming.

barrier_nodes should be fine. It's just a set of standard node IDs, we haven't converted from a different representation.

Renamed to used_barrier_nodes as we already use barrier_nodes for barrier's OSM ids.

SiarheiFedartsou · 2022-09-01T16:10:18Z

include/extractor/extractor.hpp

-               std::vector<UnresolvedManeuverOverride>,
-               TrafficSignals>
-    ParseOSMData(ScriptingEnvironment &scripting_environment, const unsigned number_of_threads);
+    ParsedOSMData ParseOSMData(ScriptingEnvironment &scripting_environment,


IMO this ParsedOSMData is a bit more readable than tuple we used before.

SiarheiFedartsou · 2022-09-01T16:14:35Z

src/extractor/extraction_containers.cpp

+        auto node_id_iterator = used_node_id_list.begin();
+        const auto all_nodes_list_end = all_nodes_list.end();
+
+        for (const auto index : util::irange<NodeID>(0, used_node_id_list.size()))


We were running it while writing nodes on disk here in WriteNodes method:

osrm-backend/src/extractor/extraction_containers.cpp

Line 857 in 96f5780

void ExtractionContainers::WriteNodes(storage::tar::FileWriter &writer) const

Probably can be refactored to be more readable(less iterator juggling etc), but IMO it is safer to keep it with as less changes as possible for now.

SiarheiFedartsou · 2022-09-01T16:15:17Z

src/extractor/extractor.cpp

+        osm_node_ids.push_back(current_node.node_id);
+    }
+
+    if (config.dump_nbg_graph)


Now we are dumping .osrm file only if it was explicitly requested.

mjjbell · 2022-09-26T21:26:34Z

src/tools/components.cpp

-
-    extractor::files::readRawNBGraph(
-        path, nop, coordinate_list, osm_node_ids, edge_list, annotation_data);
+    extractor::files::readRawNBGraph(path, coordinate_list, osm_node_ids, edge_list);


mjjbell · 2022-09-26T21:46:03Z

.github/workflows/osrm-backend.yml

+            exit 1
+          fi
+
+          # here we check that `osrm-partition` accepts base file path with `.osrm` extension even if `.osrm` file doesn't exist


I noticed the command args refer to the .osrm file. We probably want to change the wording there too.

osrm-backend/src/tools/customize.cpp

Lines 78 to 80 in 41dda32

"input,i",

boost::program_options::value<boost::filesystem::path>(&customization_config.base_path),

"Input file in .osrm format");

mjjbell · 2022-09-26T21:54:28Z

include/extractor/extraction_containers.hpp

@@ -75,6 +72,8 @@ class ExtractionContainers
    std::vector<InputTrafficSignal> external_traffic_signals;
    TrafficSignals internal_traffic_signals;

+    std::vector<NodeBasedEdge> normal_edges;


I would go with used_edges, given that's the log message at the point of generation
https://github.com/Project-OSRM/osrm-backend/pull/6354/files#diff-e52614280a87ada8afc739a67e55e7d2cc111d11a9f23fc429b7c2d20dd1d8d7R861

mjjbell · 2022-09-26T21:55:46Z

include/extractor/extraction_containers.hpp

@@ -84,11 +83,12 @@ class ExtractionContainers

    std::vector<InputManeuverOverride> external_maneuver_overrides_list;
    std::vector<UnresolvedManeuverOverride> internal_maneuver_overrides;
+    std::unordered_set<NodeID> internal_barrier_nodes;


barrier_nodes should be fine. It's just a set of standard node IDs, we haven't converted from a different representation.

mjjbell · 2022-09-26T21:56:19Z

include/extractor/extraction_containers.hpp

@@ -84,11 +83,12 @@ class ExtractionContainers

    std::vector<InputManeuverOverride> external_maneuver_overrides_list;
    std::vector<UnresolvedManeuverOverride> internal_maneuver_overrides;
+    std::unordered_set<NodeID> internal_barrier_nodes;
+    NodeVector internal_nodes;


Similarly, I'd go with used_nodes

src/extractor/node_based_graph_factory.cpp

mjjbell · 2022-09-26T22:02:51Z

include/extractor/node_based_graph_factory.hpp

@@ -38,11 +38,15 @@ class NodeBasedGraphFactory
    // node-based graph to represent the OSM network. This includes geometry compression, annotation
    // data optimisation and many other aspects. After this step, the edge-based graph factory can
    // turn the graph into the routing graph to be used with the navigation algorithms.
-    NodeBasedGraphFactory(const boost::filesystem::path &input_file,
-                          ScriptingEnvironment &scripting_environment,
+    NodeBasedGraphFactory(ScriptingEnvironment &scripting_environment,


Above comment will need updating.

mjjbell · 2022-09-26T22:23:44Z

README.md


-Note that `berlin-latest.osrm` has a different file extension. 
+Note that `berlin-latest` has no file extension. 


Referring just to the base path feels a bit odd, but I don't really have a better suggestion. Maybe always use the OSM file as the argument?

See https://github.com/Project-OSRM/osrm-backend/pull/6354/files#r982510784

SiarheiFedartsou · 2022-09-28T14:52:00Z

README.md

@@ -65,7 +65,7 @@ The flag `-v "${PWD}:/data"` creates the directory `/data` inside the docker con
    docker run -t -v "${PWD}:/data" osrm/osrm-backend osrm-partition /data/berlin-latest.osrm
    docker run -t -v "${PWD}:/data" osrm/osrm-backend osrm-customize /data/berlin-latest.osrm

-Note that `berlin-latest.osrm` has a different file extension. 
+Note there is no `berlin-latest.osrm` file, but multiple `berlin-latest.osrm.*` files, i.e. `berlin-latest.osrm` is not file path, but "base" path referring to set of files and there is an option to omit this `.osrm` suffix completely(e.g. `osrm-partition /data/berlin-latest`). 


@mjjbell I noticed that all our files match .osrm.* pattern, so IMO it feels as a good idea to still use .osrm extension everywhere, but consider it as "base" path, but not separate file. WDYT?

Yep, agreed.

SiarheiFedartsou · 2022-09-28T14:55:04Z

@mjjbell can you take a look again?

And also let's discuss these questions:

Some things to discuss:

Now in order to generate .osrm file user has to pass --dump-nbg-graph flag to osrm-extract. Is it a good naming? Should we may be make it default and allow to disable by CLI option? I can imagine that someone somehow relies on this file and uses osrm-components with it(it is really low chance IMO, but still).

The only place where this .osrm can be used is osrm-components tool which is as I understand purely for debug, so IMO .osrm feels a bit "loud" name for such kind of files. May be rename it to something?

We suggest to pass this .osrm file everywhere in the docs as if it is really used as input file(e.g. ./osrm-customize ./berlin-latest.osrm). Actually it is just a base name. So I suggest to just remove this extension from everywhere: like ./osrm-partition ./berlin-latest. But for backward compatibility leave the ability to work if it was passed in the old way(we may emit warning if it used this way). I can imagine that a lot of people have working pipelines with this .osrm in them.

@mjjbell WDYT?

For 1 I doubt someone really relies on it and it is super straightforward to just pass this additional flag if it is really needed.

For 3 I now more inclined to leave this .osrm extension everywhere with a note that it is not a specific file anymore, but base path for all other files we need(all of them have .osrm.* pattern in name)

mjjbell · 2022-09-29T19:56:21Z

Now in order to generate .osrm file user has to pass --dump-nbg-graph flag to osrm-extract. Is it a good naming? Should we may be make it default and allow to disable by CLI option? I can imagine that someone somehow relies on this file and uses osrm-components with it(it is really low chance IMO, but still).

The only place where this .osrm can be used is osrm-components tool which is as I understand purely for debug, so IMO .osrm feels a bit "loud" name for such kind of files. May be rename it to something?

It's the internal node-based-graph representation prior to compression, creation of dummy edges and other stuff that doesn't exist in the OSM data. So I would say it's the correct arg name, but I agree that it's not obvious that this should generate an .osrm file.

Renaming it to .nbg seems like a good fit with the other toolchain output, given we have already have the OSM IDs and coordinates in .nbg_nodes, and the compressed graph in .cnbg.

We suggest to pass this .osrm file everywhere in the docs as if it is really used as input file(e.g. ./osrm-customize ./berlin-latest.osrm). Actually it is just a base name. So I suggest to just remove this extension from everywhere: like ./osrm-partition ./berlin-latest. But for backward compatibility leave the ability to work if it was passed in the old way(we may emit warning if it used this way). I can imagine that a lot of people have working pipelines with this .osrm in them.

Thinking longer-term, I can see an approach where we pass around a metadata/config file, that includes information about the settings used during processing, and detailing which datasets have been generated (e.g. if we wanted to support optional loading), which maybe could be a good use for an .osrm file? In which case it would be beneficial to keep the instructions for passing that as the argument. What do you think?

mjjbell · 2022-09-29T20:04:53Z

For 3 I now more inclined to leave this .osrm extension everywhere with a note that it is not a specific file anymore, but base path for all other files we need(all of them have .osrm.* pattern in name)

Sorry I'm reading everything in the wrong order. If that's the case, then I agree, and it also aligns with the potential of a config/metadata file in the future.

mjjbell · 2022-09-29T20:05:57Z

README.md

@@ -65,7 +65,7 @@ The flag `-v "${PWD}:/data"` creates the directory `/data` inside the docker con
    docker run -t -v "${PWD}:/data" osrm/osrm-backend osrm-partition /data/berlin-latest.osrm
    docker run -t -v "${PWD}:/data" osrm/osrm-backend osrm-customize /data/berlin-latest.osrm

-Note that `berlin-latest.osrm` has a different file extension. 
+Note there is no `berlin-latest.osrm` file, but multiple `berlin-latest.osrm.*` files, i.e. `berlin-latest.osrm` is not file path, but "base" path referring to set of files and there is an option to omit this `.osrm` suffix completely(e.g. `osrm-partition /data/berlin-latest`). 


Yep, agreed.

mjjbell · 2022-09-29T20:07:32Z

src/extractor/extractor.cpp

+
+    if (config.dump_nbg_graph)
+    {
+        storage::tar::FileWriter writer(config.GetPath(".osrm").string(),


Only suggested change would be to make this .nbg

mjjbell · 2022-09-29T20:15:51Z

For 1 I doubt someone really relies on it and it is super straightforward to just pass this additional flag if it is really needed.

Agreed. Also, given the .osrm file is marked as temporary in the toolchain, I don't think users can have expectations of stability.

v5.27.0 - Changes from 5.26.0 - API: - ADDED: Add Flatbuffers support to NodeJS bindings. [Project-OSRM#6338](Project-OSRM#6338) - CHANGED: Add `data_version` field to responses of all services. [Project-OSRM#5387](Project-OSRM#5387) - FIXED: Use Boost.Beast to parse HTTP request. [Project-OSRM#6294](Project-OSRM#6294) - FIXED: Fix inefficient osrm-routed connection handling [Project-OSRM#6113](https://gihub.com/Project-OSRM/osrm-backend/pull/6113) - FIXED: Fix HTTP compression precedence [Project-OSRM#6113](Project-OSRM#6113) - NodeJS: - FIXED: Support `skip_waypoints` in Node bindings [Project-OSRM#6060](Project-OSRM#6060) - Misc: - ADDED: conanbuildinfo.json for easy reading of dependencies [Project-OSRM#6388](Project-OSRM#6388) - CHANGED: Improve performance of JSON rendering. Fix undefined behaviour in JSON numbers formatting. [Project-OSRM#6380](Project-OSRM#6380) - ADDED: Add timestamps for logs. [Project-OSRM#6375](Project-OSRM#6375) - CHANGED: Improve performance of map matching via getPathDistance optimization. [Project-OSRM#6378](Project-OSRM#6378) - CHANGED: Optimize RestrictionParser performance. [Project-OSRM#6344](Project-OSRM#6344) - ADDED: Support floats for speed value in traffic updates CSV. [Project-OSRM#6327](Project-OSRM#6327) - CHANGED: Use Lua 5.4 in Docker image. [Project-OSRM#6346](Project-OSRM#6346) - CHANGED: Remove redundant nullptr check. [Project-OSRM#6326](Project-OSRM#6326) - CHANGED: missing files list is included in exception message. [Project-OSRM#5360](Project-OSRM#5360) - CHANGED: Do not use deprecated Callback::Call overload in Node bindings. [Project-OSRM#6318](Project-OSRM#6318) - FIXED: Fix distance calculation consistency. [Project-OSRM#6315](Project-OSRM#6315) - FIXED: Fix performance issue after migration to sol2 3.3.0. [Project-OSRM#6304](Project-OSRM#6304) - CHANGED: Pass osm_node_ids by reference in osrm::updater::Updater class. [Project-OSRM#6298](Project-OSRM#6298) - FIXED: Fix bug with reading Set values from Lua scripts. [Project-OSRM#6285](Project-OSRM#6285) - FIXED: Bug in bicycle profile that caused exceptions if there is a highway=bicycle in the data. [Project-OSRM#6296](Project-OSRM#6296) - FIXED: Internal refactoring of identifier types used in data facade [Project-OSRM#6044](Project-OSRM#6044) - CHANGED: Update docs to reflect recent build and dependency changes [Project-OSRM#6383](Project-OSRM#6383) - Build: - REMOVED: Get rid of Mason. [Project-OSRM#6387](Project-OSRM#6387) - CHANGED: Use clang-format from CI base image. [Project-OSRM#6391](Project-OSRM#6391) - ADDED: Build Node bindings on Windows. [Project-OSRM#6334](Project-OSRM#6334) - ADDED: Configure cross-compilation for Apple Silicon. [Project-OSRM#6360](Project-OSRM#6360) - CHANGED: Use apt-get to install Clang on CI. [Project-OSRM#6345](Project-OSRM#6345) - CHANGED: Fix TBB in case of Conan + NodeJS build. [Project-OSRM#6333](Project-OSRM#6333) - CHANGED: Migrate to modern TBB version. [Project-OSRM#6300](Project-OSRM#6300) - CHANGED: Enable performance-move-const-arg clang-tidy check. [Project-OSRM#6319](Project-OSRM#6319) - CHANGED: Use the latest node on CI. [Project-OSRM#6317](Project-OSRM#6317) - CHANGED: Migrate Windows CI to GitHub Actions. [Project-OSRM#6312](Project-OSRM#6312) - ADDED: Add smoke test for Docker image. [Project-OSRM#6313](Project-OSRM#6313) - CHANGED: Update libosmium to version 2.18.0. [Project-OSRM#6303](Project-OSRM#6303) - CHANGED: Remove EXACT from find_package if using Conan. [Project-OSRM#6299](Project-OSRM#6299) - CHANGED: Configure Undefined Behaviour Sanitizer. [Project-OSRM#6290](Project-OSRM#6290) - CHANGED: Use Conan instead of Mason to install code dependencies. [Project-OSRM#6284](Project-OSRM#6284) - CHANGED: Migrate to C++17. Update sol2 to 3.3.0. [Project-OSRM#6279](Project-OSRM#6279) - CHANGED: Update macOS CI image to macos-11. [Project-OSRM#6286](Project-OSRM#6286) - CHANGED: Enable even more clang-tidy checks. [Project-OSRM#6273](Project-OSRM#6273) - CHANGED: Configure CMake to not build flatbuffers tests and samples. [Project-OSRM#6274](Project-OSRM#6274) - CHANGED: Enable more clang-tidy checks. [Project-OSRM#6270](Project-OSRM#6270) - CHANGED: Configure clang-tidy job on CI. [Project-OSRM#6261](Project-OSRM#6261) - CHANGED: Use Github Actions for building container images [Project-OSRM#6138](Project-OSRM#6138) - CHANGED: Upgrade Boost dependency to 1.70 [Project-OSRM#6113](Project-OSRM#6113) - CHANGED: Upgrade Ubuntu CI builds to 20.04 [Project-OSRM#6119](Project-OSRM#6119) - CHANGED: Make building osrm-routed optional [Project-OSRM#6144](Project-OSRM#6144) - FIXED: Run all unit tests in CI [Project-OSRM#5248](Project-OSRM#5248) - FIXED: Fix installation of Mason CMake and 32 bit CI build [Project-OSRM#6170](Project-OSRM#6170) - FIXED: Fixed Node docs generation check in CI. [Project-OSRM#6058](Project-OSRM#6058) - CHANGED: Docker build, enabled arm64 build layer [Project-OSRM#6172](Project-OSRM#6172) - CHANGED: Docker build, enabled apt-get update/install caching in separate layer for build phase [Project-OSRM#6175](Project-OSRM#6175) - FIXED: Bump CI complete meta job to ubuntu-20.04 [Project-OSRM#6323](Project-OSRM#6323) - CHANGED: Node packages are now scoped by @Project-OSRM [Project-OSRM#6386](Project-OSRM#6386) - Routing: - CHANGED: Lazily generate optional route path data [Project-OSRM#6045](Project-OSRM#6045) - FIXED: Completed support for no_entry and no_exit turn restrictions. [Project-OSRM#5988](Project-OSRM#5988) - ADDED: Add support for non-round-trips with a single fixed endpoint. [Project-OSRM#6050](Project-OSRM#6050) - FIXED: Improvements to maneuver override processing [Project-OSRM#6125](Project-OSRM#6125) - ADDED: Support snapping to multiple ways at an input location. [Project-OSRM#5953](Project-OSRM#5953) - FIXED: Fix snapping target locations to ways used in turn restrictions. [Project-OSRM#6339](Project-OSRM#6339) - ADDED: Support OSM traffic signal directions. [Project-OSRM#6153](Project-OSRM#6153) - FIXED: Ensure u-turn exists in intersection view. [Project-OSRM#6376](Project-OSRM#6376) - FIXED: Gracefully handle no-turn intersections in guidance processing. [Project-OSRM#6382](Project-OSRM#6382) - Profile: - CHANGED: Bicycle surface speeds [Project-OSRM#6212](Project-OSRM#6212) - Tools: - CHANGED: Do not generate intermediate .osrm file in osrm-extract. [Project-OSRM#6354](Project-OSRM#6354)

…M#6354)

Deprecate .osrm file

c8abeb0

SiarheiFedartsou mentioned this pull request Aug 31, 2022

Deprecate .osrm file #6329

Closed

SiarheiFedartsou added 8 commits August 31, 2022 22:43

Deprecate .osrm file

237d794

Deprecate .osrm file

af8059f

Deprecate .osrm file

5fab7ba

Deprecate .osrm file

8e6d018

Deprecate .osrm file

1648b9c

Deprecate .osrm file

e17fa9d

Deprecate .osrm file

09ca325

Deprecate .osrm file

156e5a9

SiarheiFedartsou commented Sep 1, 2022

View reviewed changes

SiarheiFedartsou marked this pull request as ready for review September 1, 2022 16:15

SiarheiFedartsou changed the title ~~Deprecate .osrm file~~ Do not generate intermediate .osrm file in osrm-extract. Sep 1, 2022

SiarheiFedartsou added 2 commits September 1, 2022 18:17

Deprecate .osrm file

13245be

Deprecate .osrm file

1b940a6

SiarheiFedartsou mentioned this pull request Sep 23, 2022

Stop signs for the turn function in lua profiles #4828

Closed

5 tasks

mjjbell requested changes Sep 26, 2022

View reviewed changes

SiarheiFedartsou added 5 commits September 27, 2022 18:11

Do not generate intermediate .osrm file in osrm-extract.

1bb75f8

Merge branch 'master' into sf-osrm-file

500ea83

Do not generate intermediate .osrm file in osrm-extract.

a96cb23

Do not generate intermediate .osrm file in osrm-extract.

c3be71a

Do not generate intermediate .osrm file in osrm-extract.

bbfff7d

SiarheiFedartsou commented Sep 28, 2022

View reviewed changes

SiarheiFedartsou requested a review from mjjbell September 28, 2022 14:55

mjjbell approved these changes Sep 29, 2022

View reviewed changes

Do not generate intermediate .osrm file in osrm-extract.

fd8ccde

SiarheiFedartsou merged commit 2188833 into master Sep 30, 2022

SiarheiFedartsou mentioned this pull request Nov 10, 2022

Running osrm-extract on us-latest.osm.pbf #6448

Closed

greenscientist mentioned this pull request Nov 25, 2022

Fix start of osrm-contract chairemobilite/transition#469

Merged

mattwigway pushed a commit to mattwigway/osrm-backend that referenced this pull request Jul 20, 2023

Do not generate intermediate .osrm file in osrm-extract. (Project-OSR…

0d77f06

…M#6354)

DennisOSRM deleted the sf-osrm-file branch May 3, 2024 12:29

sjkeerthi mentioned this pull request Aug 20, 2024

osrm file issue #7018

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Do not generate intermediate .osrm file in osrm-extract. #6354

Do not generate intermediate .osrm file in osrm-extract. #6354

SiarheiFedartsou commented Aug 31, 2022 •

edited

Loading

SiarheiFedartsou commented Sep 1, 2022

SiarheiFedartsou Sep 1, 2022

SiarheiFedartsou Sep 1, 2022

mjjbell Sep 26, 2022 •

edited

Loading

SiarheiFedartsou Sep 1, 2022

mjjbell Sep 26, 2022

SiarheiFedartsou Sep 27, 2022

SiarheiFedartsou Sep 1, 2022

SiarheiFedartsou Sep 1, 2022 •

edited

Loading

SiarheiFedartsou Sep 1, 2022

mjjbell Sep 26, 2022

mjjbell Sep 26, 2022

SiarheiFedartsou Sep 28, 2022

mjjbell Sep 26, 2022 •

edited

Loading

mjjbell Sep 26, 2022

mjjbell Sep 26, 2022

mjjbell Sep 26, 2022

mjjbell Sep 26, 2022

SiarheiFedartsou Sep 28, 2022

SiarheiFedartsou Sep 28, 2022

mjjbell Sep 29, 2022

SiarheiFedartsou commented Sep 28, 2022

mjjbell commented Sep 29, 2022

mjjbell commented Sep 29, 2022 •

edited

Loading

mjjbell Sep 29, 2022

mjjbell Sep 29, 2022

mjjbell commented Sep 29, 2022

	"input,i",
	boost::program_options::value<boost::filesystem::path>(&customization_config.base_path),
	"Input file in .osrm format");


		Note that `berlin-latest.osrm` has a different file extension.
		Note that `berlin-latest` has no file extension.

Do not generate intermediate .osrm file in osrm-extract. #6354

Do not generate intermediate .osrm file in osrm-extract. #6354

Conversation

SiarheiFedartsou commented Aug 31, 2022 • edited Loading

Issue

Tasklist

Requirements / Relations

SiarheiFedartsou commented Sep 1, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mjjbell Sep 26, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SiarheiFedartsou Sep 1, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mjjbell Sep 26, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SiarheiFedartsou commented Sep 28, 2022

mjjbell commented Sep 29, 2022

mjjbell commented Sep 29, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mjjbell commented Sep 29, 2022

SiarheiFedartsou commented Aug 31, 2022 •

edited

Loading

mjjbell Sep 26, 2022 •

edited

Loading

SiarheiFedartsou Sep 1, 2022 •

edited

Loading

mjjbell Sep 26, 2022 •

edited

Loading

mjjbell commented Sep 29, 2022 •

edited

Loading