mapbox / osrm-tag-rewriter Goto Github PK

Re-writes multiple deprecated but still present OpenStreetMap tags for routing engines

License: MIT License

CMake 14.21% Shell 7.49% C++ 55.42% Gherkin 22.88%

osrm-tag-rewriter's Introduction

osrm-tag-rewriter

Rewrites OpenStreetMap tags for example from motorway junction nodes to its ramps. Mainly for easier handling in our routing engine.

Building

A recent libosmium is getting downloaded to third_party by invoking the ./deps.sh script.

./deps.sh
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
cmake --build .

Using Mason

You can build this project using packages bundled with mason:

./masonize.sh
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DENABLE_MASON=On
cmake --build .

Running

./osrm-tag-rewriter in.osm.pbf out.osm.pbf

Tests

See the tests directory.

pushd tests
./check.sh
popd

Rewriters

Destination Tags

Rewrites OpenStreetMap exit_to= Node tags on highway=motorway_junction to destination= tags on the adjacent way when possible to do so without ambiguity.

Query for exit_to node tags, Bay Area: http://overpass-turbo.eu/s/kEM
Query for destination way tags, Bay Area: http://overpass-turbo.eu/s/kEN

Exit Numbers

Rewrites OpenStreetMap ref= Node tags on highway=motorway_junction to junction:ref= tags on the adjacent way when possible to do so without ambiguity.

License

Distributed under the MIT License (MIT).

osrm-tag-rewriter's People

Contributors

Stargazers

Watchers

Forkers

testbigorg rubythonode isabella232 samuelbrucksch

osrm-tag-rewriter's Issues

Re-write exit numbers from highway junction nodes into `junction:ref` way tags

We should re-purpose this project to handle all our tag re-writing. Maybe have a single binary with multiple re-writing passes you can enable or disable on the command line.

Specifically we need to re-write ref tag on the highway=motorway_junction node into junction:ref tag when unambiguously possible.

Context:

cc @willwhite

Handle :left and :right suffixes

There are some exit_to:left, exit_to:right and ref:left, ref:right tags we have to handle.
The edge case we stumbled upon are sub-exits, e.g. with ref=1 A; 1B + ref:left=1A + ref:right=1B:

https://www.openstreetmap.org/edit#map=18/37.26047/-121.85779

Currently we only re-write the ref tag which is terrible here: both ways splitting off will get the 1A; 1B as exits which is plain wrong. We have a few options here:

parse :left and :right suffices and try to associate them with the correct way
don't re-write ref tags if there are also :left and :right tags on the motorway junction node
just re-tag these edge cases with junction:ref already in the data

It looks like there are roughly 700 ref:left and ref:right tags out in the wild and 570 of those are in combination with the ref tag. So we screw up most of them currently.

(Same applies to exit_to, exit_to:left, exit_to:right of which there are not that many luckily)

@1ec5 @srividyacb opinions here?

Handle implicit oneways

At the moment our destination and exit number re-writer only re-writes if the ramp is a oneway by means of having a oneway=* tag.

There are two implied oneways:

we should check in addition.

These are edge cases but for correctness sake we should handle them anyway.

Do not rewrite on all possible destinations

Capturing from https://github.com/mapbox/directions-feedback/issues/575#issuecomment-312885363 and https://github.com/mapbox/directions-feedback/issues/575#issuecomment-312891683:

We currently rewrite exit_to tags into destination tags, if no destination tag is already present (see here).

OSRM treats destination and destination:ref as a combined field, just as we did a while back with name and ref.

This results in combinations as this:

It combines this node and this way into CA 82: SR-82 as an announcement.

We have multiple choices: handling destination and destination:ref separately in OSRM or prevent rewriting on all destination* flags.

For now, the simple fix would be to don't rewrite, if any destination is already present on the target way.

/cc @daniel-j-h @willwhite