Skip to content
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

Make edge weight a strongly defined type #3601

Closed
oxidase opened this issue Jan 23, 2017 · 3 comments · Fixed by #6421
Closed

Make edge weight a strongly defined type #3601

oxidase opened this issue Jan 23, 2017 · 3 comments · Fixed by #6421
Labels

Comments

@oxidase
Copy link
Contributor

oxidase commented Jan 23, 2017

Working on #2399 found different weight types

PR #2399 unifies weight types as EdgeWeight but compile-time type checking is required to check all places.
It would also good to define strongly typed EdgeDuration, TurnWeight and TurnDuration to have compile-type checks and avoid problems by mixing edge/turn weights and durations.

@daniel-j-h
Copy link
Member

Yes, yes please. I poked @danpat often enough some time ago that we ended up building and incorporating

https://github.com/Project-OSRM/osrm-backend/blob/master/include/util/strong_typedef.hpp#L43
https://github.com/Project-OSRM/osrm-backend/blob/master/include/util/typedefs.hpp#L40-L44

which is similar to the one in Boost, except that it does not allow implicit conversions.

@danpat
Copy link
Member

danpat commented Jan 23, 2017

@oxidase yeah, you want to take a look and see if OSRM_STRONG_TYPEDEF is usable here? Check the OSMNodeID type as an example (also, include/util/coordinate.hpp where we use it to prevent lon/lat swap mistakes).

It should be fully optimized away under -O3, and will give the compile-time checking you're after.

@TheMarex
Copy link
Member

TheMarex commented Jul 6, 2017

This has no clear priority right now. We should have a look at this when we got some downtime for refactors.

mjjbell referenced this issue Oct 20, 2022
Currently OSRM parses traffic signal nodes without consideration
for the direction in which the signal applies. This can lead
to duplicated routing penalties, especially when a forward and backward
signal are in close proximity on a way.

This commit adds support for directed signals to the extraction and
graph creation. Signal penalties are only applied in the direction
specified by the OSM tag.

We add the assignment of traffic directions to the lua scripts,
maintaining backwards compatibility with the existing boolean
traffic states.

As part of the changes to the internal structures used for tracking
traffic signals during extraction, we stop serialising/deserialising
signals to the `.osrm` file. The traffic signals are only used by
`osrm-extract` so whilst this is a data format change, it will not
break any existing user processes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants