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

[Transportation] OSM access:both_ways=no wrongfully interpreted as denied access #339

Open
sokadd opened this issue Feb 21, 2025 · 0 comments

Comments

@sokadd
Copy link

sokadd commented Feb 21, 2025

First we need to understand what access:both_ways even tries to describe. Problem is, it is not even directly documented, although the suffix :both_ways is:

The third option both_ways is used for the lane in the middle of the road that is used in both directions (e.g. a centre turn lane). This should not be used to mean "forward and backward", as this is the default meaning of all un-suffixed keys. Under certain circumstances an additional forward or backward behind both_ways is needed.

By applying this explanation to the access key, we get the understanding that highways with access:both_ways=no have a "middle"/"center turn" lane, but you are no allowed to use it.

The following OSM example shows this clearly with ways 1014909000 and 1014908999:

The corresponding Overture features are 0871faa0a8ffffff0474bfb8a7497e48 and 0861faa0afffffff0479fe40a6440659 where you can also spot the denied access_restriction.

By my understanding, the Overture data is wrong about this, because restricting access to the middle lane does not mean restricting access to the entire highway, in both directions.

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

No branches or pull requests

1 participant