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

Mark geometry lane based on placement= tags #6

Open
tordans opened this issue Mar 27, 2022 · 6 comments
Open

Mark geometry lane based on placement= tags #6

tordans opened this issue Mar 27, 2022 · 6 comments
Assignees
Labels
tracking issue Ongoing bigger project with more specific tasks listed inside

Comments

@tordans
Copy link

tordans commented Mar 27, 2022

For his Straßenraumkarte, Supaplex uses the tag placement=right_of:1 to clarify where lanes are positioned in relation to the geometry-line.

Additionally, placement=right_of:1 helps to place the lanes precisely in relation to position of the osm way by indicating that the way geometry is located right of the first (left) lane and all other lanes are to be rendered right of it.

https://supaplexosm.github.io/strassenraumkarte-neukoelln/posts/2021-12-31-micromap-update#bike-lanes-position-them-right


I think osm2lanes would have to evaluate this tag in order to allow renderer to precisely position the lanes.


Maybe the osm2lanes schema could be something like this

lane1 > position_from_geometry=-2
lane2 > position_from_geometry=-1
lane3 > position_from_geometry=0
lane4 > position_from_geometry=1


I don't think that is the next important part, but I was thinking about it and wanted to start the documentation/discussion.

@droogmic
Copy link
Collaborator

Maybe the osm2lanes schema could be something like this

I think I would prefer a single top level attribute, like we do with highway type and lifecycle, as it will basically always be an incrementing scale?.

A way_centre_index: usize of 1 means that centre of the second of n lanes must follow the way's geometry. (Better name needed).

The assumption we make is that this will then always be at the center of the specified lane.
We could instead provide a distance in meters from the left edge that the center of the way is located at?

Either way, it's probably better to add this in relatively early on, as it might be harder to add later.

@BudgieInWA
Copy link
Collaborator

BudgieInWA commented Mar 28, 2022

I agree on a top level attribute. Like way_placement = Placement::RightOf(1). Maybe canonicalised to way_right_of: (with way_distance_from_left and way_at_center: true for the particular lane or separator for convenience).

The values for placement are described at the top of the Tagging section of the proposal. In practice, placement:{start,end} can be tagged to avoid needing to guess based on placement=transition, so maybe that could be represented in addition. (placement:{start,end} can refer to the lanes that don't exist on this way, referring to the road that the way connects to instead (e.g. a freeway exit lane on the right might have placement:start=left_of:-1 because the way starts one lane over in the freeway itself).)

@dabreegster dabreegster transferred this issue from a-b-street/osm2lanes May 1, 2022
@dabreegster
Copy link
Contributor

All: I started a new repository to focus on the next layer above osm2lanes that handles geometry and all of the questions around merging/snapping ways. Even though there's no code there yet, I hope it's at least more organized to keep all the issues in one place. (We could've also tagged them, but my intention is to move code out of A/B Street into this repo)

@BudgieInWA BudgieInWA changed the title Mark geometry lane based on placement=right_of:1 Mark geometry lane based on placement= tags May 2, 2022
@dabreegster
Copy link
Contributor

dabreegster commented Nov 10, 2022

a-b-street/abstreet#897 has a bunch of relevant notes

@BudgieInWA BudgieInWA self-assigned this Nov 10, 2022
@dabreegster
Copy link
Contributor

Maybe finished by #139, or do we have much more left to do with placement?

@BudgieInWA
Copy link
Collaborator

Two things still need doing:

  • Shifting geometry with a different start and end offset so we can render placement:start/placement:end pairs.
  • Inferring placement start/end for ways tagged placement=transition.

@dabreegster dabreegster added the tracking issue Ongoing bigger project with more specific tasks listed inside label Feb 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tracking issue Ongoing bigger project with more specific tasks listed inside
Projects
None yet
Development

No branches or pull requests

4 participants