osm2streets
osm2streets copied to clipboard
Mark geometry lane based on `placement=` tags
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.
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.
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).)
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)
a-b-street/abstreet#897 has a bunch of relevant notes
Maybe finished by #139, or do we have much more left to do with placement?
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
.