Bike_road_access EV should be direction dependent

Open Source Routing Engine
1

As discussed in issue #3401 I tried to make the bike_road_access encoded value direction dependent.
Here are the needed extensions compared to the pull request branch of #3401.
This change was rather trivial so far. But making use of the now direction dependent bike_road_access encoded value is currently not possible. I believe it would require to be able to somehow assign direction dependent priorities in the custom model.
Something like this:

{
  "priority": [
    { "if": "true",  "multiply_by": "bike_priority" }
  ],
  "backward_priority": [
    { "if": "backward_bike_road_access == USE_SIDEPATH",  "multiply_by": "0.3" }
  ],
  "forward_priority": [
    { "if": "forward_bike_road_access == USE_SIDEPATH",  "multiply_by": "0.3" }
  ]
}

The new direction dependent custom rules would need to overwrite a direction dependent priority value.

Do you agree with such an approach or is there a simpler solution?

2

I’m unsure of what you are trying to do. The custom model already considers the direction and there should be no need to define a backward priority.

If a backward priority is necessary e.g. for bidirectional A* in reverse direction, then it is already handled via the boolean reverse property (as method argument), which then picks up the correct direction. The same mechanism is also already successfully used for other direction dependent encoded values like access or speed.

I tried to start with this one, but it is not trivial and needs further discussion.

Yes, this is correct :slight_smile: … merging xy_access with xy_road_access is not trivial but would solve a few problems. One of which is this strange backward hack in bike.json to allow access for reverse oneways and instead would just be able to use bike_road_access==DISMOUNT => speed=6kmh.

3

I had an example like this in mind.

Here a oneway cycleway runs on the right side along to a bi-directional residential road. I didn’t expect this example to work. Surprisingly it already works in both directions. But it is quite close. One can see that it is close as the residential is suggested as alternative:

image
image1092×928 346 KB

The other direction looks like this:

image
image1096×998 385 KB

As it was quite hard to even find this example, I came to the conclusion that currently a direction dependent bike_road_access encoded value with direction dependent priority is currently not needed. This might change in the far future, when more logic is moved from Java into the custom models.

4

Hm, I am still unsure what you mean. Do you mean the side of the road and e.g. in Germany the right side of the road should be preferred? How would this work with a custom model? I don’t think it would work and you would need some kind of pre-processing to assign the “main road” and “left” and “right” sides and their directions. I even have a prototype for this, but it is rather tricky.

Also note that the cycleways often these days have a oneway tag (like in your example), which makes it easier for us.

5

No, I don’t mean the side of the road, but the direction you move.

Take the example I described above with a oneway cycleway, which runs on the right side along to a bi-directional residential road. If you use the following custom rule

  "priority": [
      { "if": "bike_road_access == USE_SIDEPATH", "multiply_by": "0.5" }
  ]

this applies to both directions of the residential road! It also de-prioritizes in the priority of the residential in the opposite direction of the oneway cycleway, where you need to take the residential road. This is not what is intended.

The usage of backward_bike_road_access does not help, because currently there is only one direction independent priority you can influence in a custom model.

6

this applies to both directions of the residential road

But only because we currently do not store one value for every direction for bike_road_access. If we would then one direction suggests the sidepath and the reverse direction not => then we can include exactly the statement that you suggested.

I don’t see another solution to it (like you suggested with the forward_priority etc)

The usage of backward_bike_road_access does not help, because currently there is only one direction independent priority you can influence in a custom model.

What do you mean here? All statements in priority are considering the direction, e.g. speed which can have different values for up and downhill etc.

7

Thank you for explaining. Now I believe start to understand. Sorry for my lack of understanding so far. I didn’t know that and I don’t think that this is somewhere properly described. Maybe I missed it, but I looked it up in custom-models.md, where I would expect this information.

Does this mean that my prepared change, where I created one value for every direction for bike_road_access, does make sense and I could turn it into a pull request?

8

Now I believe start to understand. Sorry for my lack of understanding so far.

Really no worries … sorry for the lack of description :). Will think about a topic in custom-models.md

Does this mean that my prepared change, where I created one value for every direction for bike_road_access, does make sense and I could turn it into a pull request?

Did you try it out and it did what you wanted :slight_smile: ? The only problem I have is that more bits are used … and when merging xy_access with it we would at least be able to reduce the bits by 2 :wink:

9

Only partially. I checked via the “Show Routing Graph” feature in the browser, but I didn’t use it in a custom model, because I didn’t expect this to be useful.

The only problem I have is that more bits are used … and when merging xy_access with it we would at least be able to reduce the bits by 2 :wink:

I will try to figure out what such a merging would mean. I don’t expect that I can do that myself, but in case I’ll inform you how far I could get.

10

Yeah, probably a bigger change (will look into it soonish) with some unexpected things.