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

Unpaved roads #3240

Merged
merged 19 commits into from
Aug 12, 2021
Merged

Unpaved roads #3240

merged 19 commits into from
Aug 12, 2021

Conversation

maksimandrianov
Copy link
Contributor

@maksimandrianov maksimandrianov commented Jul 28, 2021

Issue

Added the new option exclude_unpaved. This value indicates the willingness to take unpaved roads. If exclude_unpaved is set to 1, unpaved roads are excluded from the process of generating the route path, otherwise included.

Tasklist

  • Add tests
  • Add #fixes with the issue number that this PR addresses
  • Update the docs with any new request parameters or changes to behavior described
  • Update the changelog
  • If you made changes to the lua files, update the taginfo too.

Requirements / Relations

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

@maksimandrianov maksimandrianov force-pushed the andrianov_962_1 branch 4 times, most recently from c514e10 to 8a28ebb Compare August 4, 2021 11:12
@maksimandrianov
Copy link
Contributor Author

maksimandrianov commented Aug 4, 2021

The light demo of using the exclude_unpaved option:

Include unpaved Exclude unpaved OSM
Screenshot 2021-08-04 at 15 46 06 Screenshot 2021-08-04 at 15 45 53 Unpaved OSM way
Screenshot 2021-08-04 at 16 16 53
Screenshot 2021-08-04 at 15 46 32 Screenshot 2021-08-04 at 15 46 23 Unpaved OSM way
Screenshot 2021-08-04 at 16 27 56
Screenshot 2021-08-04 at 15 47 06 Screenshot 2021-08-04 at 15 46 40 Unpaved OSM way
Screenshot 2021-08-04 at 16 32 24

@kevinkreiser
Copy link
Member

@maksimandrianov can you please fill out the description of the pr just for book-keeping purposes. just a brief description of the changes. also dont forget to add it to the costing documentation in /docs

@maksimandrianov
Copy link
Contributor Author

maksimandrianov commented Aug 4, 2021

There are two implementations of the exclusion unpaved roads from a route in this PR:

  • Do not allow the use of unpaved roads in the beginning and end of a route. (The commit - b88ba5e)
  • Allow the use of unpaved roads in the beginning and end of a route. (This branch)

Examples:

Do not allow Allow OSM
No route found Screenshot 2021-08-04 at 15 47 43 Unpaved OSM way
Unpaved OSM way
Unpaved OSM way
Screenshot 2021-08-04 at 17 17 41
No route found Screenshot 2021-08-04 at 15 47 55 Unpaved OSM way
Screenshot 2021-08-04 at 17 23 51

@maksimandrianov maksimandrianov marked this pull request as ready for review August 5, 2021 13:49
@merkispavel
Copy link
Contributor

merkispavel commented Aug 5, 2021

There are two implementations of the exclusion unpaved roads from a route in this PR:
-Do not allow the use of unpaved roads in the beginning and end of a route. (The commit - b88ba5e)
-Allow the use of unpaved roads in the beginning and end of a route. (This branch)

origin and destination points are usually set intentionally so if one of them gets snapped to the unpaved road - why shouldn't we use it. The second (up-to-date) implementation definitely makes sense to me 👍

Though there's a small pitfall. In this case we don't say "get out of the unpaved road asap" so we can make completely-unpaved route in theory. It doesn't seem like a blocker for this PR imho, just wanted to share

@gknisely
Copy link
Member

gknisely commented Aug 5, 2021

@kevinkreiser @dnesbitt61 don't we usually have a range(0 to 1) for use_* options? Not sure if the naming (use_unpaved_roads) is correct here. Thoughts? cc @maksimandrianov

@kevinkreiser
Copy link
Member

@gknisely yes exactly, use_* options are in the range of 0-1, meaning they are not hard avoids but a soft avoid on a finite scale.

if you want to exclude certain types of roads from the start or end of the route, as in its not allowed to use those as candidates, then you should look into how loki does excludes. that is done in a different part of the request using the search filter. here is where it gets applied: https://github.com/valhalla/valhalla/blob/master/src/loki/search.cc#L38-L42

@gknisely
Copy link
Member

gknisely commented Aug 5, 2021

@gknisely yes exactly, use_* options are in the range of 0-1, meaning they are not hard avoids but a soft avoid on a finite scale.

if you want to exclude certain types of roads from the start or end of the route, as in its not allowed to use those as candidates, then you should look into how loki does excludes. that is done in a different part of the request using the search filter. here is where it gets applied: https://github.com/valhalla/valhalla/blob/master/src/loki/search.cc#L38-L42

@maksimandrianov I think that the above is a better implementation. Thoughts ^

@kevinkreiser
Copy link
Member

I agree that 0 should not be a hard exclusion of unpaved roads in the path but that they should be severely penalized. in the cases where unpaved roads are the only way between two locations we need to allow for that and this is the strategy that the project has followed since we started allowing tweaking costing in this way.

we can do hard exclusion on the search candidates as i pointed out above but have yet to add hard exclusion in the path finding phase. not that we couldnt do that, but we need to do a bit of a design process there to make sure it works for all cases where we would want to do that. id argue that is not so useful and not so common that a person will tolerate absolutely no unpaved roads or no highways or not tolls for example. if that is the only way to go, they'd rather have A route than none or than one that makes them drive 2 hours out of their way

@genadz
Copy link
Contributor

genadz commented Aug 10, 2021

@merkispavel

Though there's a small pitfall. In this case we don't say "get out of the unpaved road asap" so we can make completely-unpaved route in theory. It doesn't seem like a blocker for this PR imho, just wanted to share

To avoid that we can penalize unpaved roads more than ordinary roads.

@genadz
Copy link
Contributor

genadz commented Aug 10, 2021

I agree that 0 should not be a hard exclusion of unpaved roads in the path but that they should be severely penalized. in the cases where unpaved roads are the only way between two locations we need to allow for that and this is the strategy that the project has followed since we started allowing tweaking costing in this way.

we can do hard exclusion on the search candidates as i pointed out above but have yet to add hard exclusion in the path finding phase. not that we couldnt do that, but we need to do a bit of a design process there to make sure it works for all cases where we would want to do that. id argue that is not so useful and not so common that a person will tolerate absolutely no unpaved roads or no highways or not tolls for example. if that is the only way to go, they'd rather have A route than none or than one that makes them drive 2 hours out of their way

@kevinkreiser I think in this case hard exclusion is more preferable and clear way. There are several reasons for that I see:

  • It's expected and completely clear behavior to return a route without unpaved roads in case I set exclude_unpaved=true. I will be very surprise if I get a route with unpaved edges. From my perspective it's worse to get a route with unpaved roads in case there is a route without unpaved roads rather than return "No route" in case the only way to go is to use unpaved edges.
  • Choosing correct penalty it's very difficult task. This value should be aligned with other many constants that we already use for other options. Moreover, it should be aligned with other options that we will introduce in the future. So, we can't guarantee for 100% that avoid_unpaved will work correctly with all combinations of options that we have for now (like use_tracks, use_tolls and other that have big penalties).
  • I do believe that there are very few cases when unpaved road is the only way to go from the origin to the destination. As for me it's okay to return "No route", a user takes a responsibility for setting parameters. But, if we really want to cover such cases and return a route, we can do that on the second pass of the path finding algorithm.

P.S. if we treated all use_*=0 parameters as hard exclusion and handle "No route" cases only on the second pass we could improve performance for such requests (due to lower costs).

@maksimandrianov
Copy link
Contributor Author

@gknisely yes exactly, use_* options are in the range of 0-1, meaning they are not hard avoids but a soft avoid on a finite scale.

if you want to exclude certain types of roads from the start or end of the route, as in its not allowed to use those as candidates, then you should look into how loki does excludes. that is done in a different part of the request using the search filter. here is where it gets applied: https://github.com/valhalla/valhalla/blob/master/src/loki/search.cc#L38-L42

But we want to see the hard exclusion here. I cannot imagine how the level of avoidance of unpaved roads can help drivers.
I have used the dest_only example, when implemented this.

@maksimandrianov
Copy link
Contributor Author

@kevinkreiser @dnesbitt61 don't we usually have a range(0 to 1) for use_* options? Not sure if the naming (use_unpaved_roads) is correct here. Thoughts? cc @maksimandrianov

If it is a problem I can rename this variable. exclude_unpaved_roads? Or do you have any suggestion of a better readable name?

@maksimandrianov
Copy link
Contributor Author

maksimandrianov commented Aug 10, 2021

3. we could change all use_ options to work like this but that would be a breaking change. existing requests would start hard excluding stuff if set to 0

Unfortunately, if use_* set to 0, it does not mean hard exclusion - https://github.com/valhalla/valhalla/blame/master/docs/api/turn-by-turn/api-reference.md#L105

I will fix naming, thank you for the detailed explanation!

@genadz
Copy link
Contributor

genadz commented Aug 10, 2021

  1. i dont think its ok to have different semantics for options of the same type. all use_ options should work the same

completely agree, we shouldn't put different meanings for two use_* options

@kevinkreiser
Copy link
Member

kevinkreiser commented Aug 10, 2021

@maksimandrianov @genadz yeah i think if we change the name to something else, then we could also migrate the other use_ options to match that naming and depricate as i mentioned in the last part of my previous comment

so now the real question is, what is a better name than use_

@@ -412,7 +412,8 @@ bool AutoCost::Allowed(const baldr::DirectedEdge* edge,
((pred.restrictions() & (1 << edge->localedgeidx())) && !ignore_restrictions_) ||
edge->surface() == Surface::kImpassable || IsUserAvoidEdge(edgeid) ||
(!allow_destination_only_ && !pred.destonly() && edge->destonly()) ||
(pred.closure_pruning() && IsClosed(edge, tile))) {
(pred.closure_pruning() && IsClosed(edge, tile)) ||
(!use_unpaved_roads_ && !pred.unpaved() && edge->unpaved())) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i like this trick of using a bit to specify whether the predecessor was or wasnt unpaved instead of keeping track of the pruning state. i think its easier to reason about than setting and unsetting the pruning. we should switch to doing this for closures. cc @mandeepsandhu

@dnesbitt61
Copy link
Member

The bicycle costing option avoid_bad_surfaces does a hard exclusion when set to a value of 1. Not sure if I like the naming of this option, but it does mix penalties and exclusion.

@kevinkreiser
Copy link
Member

kevinkreiser commented Aug 10, 2021

The bicycle costing option avoid_bad_surfaces does a hard exclusion when set to a value of 1.

@dnesbitt61 i had the same thought, use the term avoid_, reverse the range (since it has the opposite meaning) and then deprecate all of the use_ options. and i had the same thought that i didnt love the naming but i have a feeling there is no naming that i would love 😄

@maksimandrianov
Copy link
Contributor Author

The bicycle costing option avoid_bad_surfaces does a hard exclusion when set to a value of 1.

@dnesbitt61 i had the same thought, use the term avoid_, reverse the range (since it has the opposite meaning) and then deprecate all of the use_ options. and i had the same thought that i didnt love the naming but i have a feeling there is no naming that i would love 😄

May be do we leave use_* option naming as it is? I agree with @kevinkreiser, because avoid and use are similar in clarity/readability terms.

@maksimandrianov
Copy link
Contributor Author

maksimandrianov commented Aug 11, 2021

@kevinkreiser, @genadz the naming was fixed, PTAL

kevinkreiser
kevinkreiser previously approved these changes Aug 11, 2021
Copy link
Member

@kevinkreiser kevinkreiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

other than the change to the docs wording, this looks good to me. i would like @gknisely 's opinion on the tagging values though

@kevinkreiser
Copy link
Member

@maksimandrianov please add an entry to the changelog. a new request parameter certainly deserves an entry in the changelog

@@ -122,6 +122,7 @@ The following options are available for `auto`, `bus`, `hov`, `taxi`, and `truck
| :-------------------------- | :----------- |
| `height` | The height of the vehicle (in meters). |
| `width` | The width of the vehicle (in meters). |
| `exclude_unpaved` | This value indicates the whether or not the path may include unpaved roads. If `exclude_unpaved` is set to 1, unpaved roads are not allowed to be used in the process of generating the route path, otherwise they are allowed. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maksimandrianov should we mention here that it's allowed to start and end with unpaved roads, but it's not allowed to have them in the middle ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. @maksimandrianov can you make the change log more descriptive too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I made

@@ -122,6 +122,7 @@ The following options are available for `auto`, `bus`, `hov`, `taxi`, and `truck
| :-------------------------- | :----------- |
| `height` | The height of the vehicle (in meters). |
| `width` | The width of the vehicle (in meters). |
| `exclude_unpaved` | This value indicates the whether or not the path may include unpaved roads. If `exclude_unpaved` is set to 1, unpaved roads are not allowed to be used in the process of generating the route path, otherwise they are allowed. If `exclude_unpaved` is set to 1 it is allowed to start and end with unpaved roads, but is not allowed to have them in the middle of the route path. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is some contradiction between second and third sentences. @maksimandrianov Could you rewrite it ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants