This proposal aims to establish the tag incline:across to map the lateral inclination of ways.
The tag is already widely used, so hopefully we can make it “official”.
Please discuss this proposal on its wiki talk page.
1 Like
Thank you for takng the effort for this proposal! I have two comments:
- On roads there are different cross section profiles. Wider roads often have “roof_profiles” (Dachprofil in german) where the highest point of the road is in the middle. The distiction positive/negative values to imply right/left is not possible there.
- You could add an example how to tag this for sidewalks without their own geometry. I guess
sidewalk:right:incline:across=2%would fit? - See this example: On this cycleway water runs to the left side, but there is one point (something like a crossing) where the right curb is lowered and water runs to the right side. This is a very short segment, about 3m. Would you split the way into three ways, or can such short segments be ignored? (I am no wheelchair user and cannot determine how relevant this is for them)
incline:across:left=* + incline:across:right=* would be needed for that.
1 Like
In this case, I would assume it’s some kind of crossing and just map the way coming from the street, crossing the cycleway and ending on the actual sidewalk. Or in other words I would map a way perpenticular to the camera view. The cycleway would be unaltered (except for the shared Node).
This would also be my suggestion.
As @UW_Amy_Bordenave already suggested a further refinement / extension of the key would be necessary to cover that case. On the other hand one can ask how reasonable mapping such a thing would be (at least regarding the use case: accessibility).
In pedestrian zones / streets without curbs, the profile is often with the lowest point in the middle, because water runoff should not go to the buildings. This also needs left and right, and it is a use case for accessibility.
1 Like
When you can’t actually measure the angle, would incline:across=slight/substantial work?
incline:across= can only use =up vs =down as incline=
If it’s the sole determining factor, you might be able to directly use wheelchair=
How would you define “up” and “down”?
That’s not according to the definition of :left/:right suffixes which describe objects on the side of a way, but not the two halves of the way object itself.
Different wheelchair types (and different users of each different wheelchair type) each have different requirements.
If there is no object type prefix, what else would the suffix refer to but the side of the element?
<object>:<side>=* - statement about the presence of <object> on the <side> of this element, ex. sidewalk:left=yes meaning “yes there is a sidewalk on the left side of this element”
vs <property>:<side>=* - statement about the <property> on the <side> of this element, ex. surface:left=concrete meaning “concrete is the surface on the left side of this element”
The two could be used together, though I think generally at that point you should probably be using <object>:<side>=separate, + <property>=* on the separately-mapped object rather than <object>:<side>:<property>=*:
highway=residential + sidewalk:left=separate, and surface=concrete on the footway=sidewalk,
vs highway=residential + sidewalk:left=yes + sidewalk:left:surface=concrete)
<object>:<side1>:<property>:<side2>=* - statement about the <property> on the <side2> of the <object> on the <side1> of this element, ex. sidewalk:left:surface:left=concrete meaning “concrete is the surface on the left(side2) of the sidewalk on the left(side1) side of this element”
I would not recommend using that, but the logic holds.
1 Like
It’s the same logic for positiveness: Upward towards the right is =up
Is there any difference from other factors ? =substantial suggests =no or =limited
Another option without evaluating wheelchair= might be obstacle:wheelchair=incline:across to expand on obstacle=unevenness
Can you guarantee that the distinction between <object> and <property> is always easy to determine and unambiguous?
How do you extend this scheme in case of 3 or 4 parts? A way may very well be level in the middle but have steep slopes on both sides.
A tag for the shape of the surface of the way is a good thing, but a incline:across tag is not sufficient for a good description. That’s like trying to describe roofs by just roof:orientation but without roof:shape.
I’m confused by what you are asking. incline:across:left= is the same as surface:left=
If the problem is semantic with your interpretation, can you think of incline:across:left= as for the left-side edge?
incline:across:*ward= is another option, but *:*ward= is more functionally for traffic, while physical sides is best in *:left=
This doesn’t need incline:across:lanes= (yet)
This isn’t trying to draw the crown line, which is further more complicated for rolling crowns. Your requirement is towards roof:ridge= , not roof:shape=
Right. That’s the same way of misusing what is documented for :left/:right. That key is added less than 20 times a year, so hardly “in use”.
Sure, this references the left-side edge. There might be e.g. a kerb there, so incline:across:left might be something around 90°. But defining the incline there doesn’t tell you anything about the incline on the rest of road.
Would, for those who see :left as problematic, another word, lets say :left_half oder :left_part oder :left_side be better?
It would be better, but it doesn’t solve the problem for this tag. A road may be inclined towards the middle, but is it a arched shape? Or steeper sides with a flat middle? Or is it more like a heap in the middle? For many data users the whole “incline:across” doesn’t matter at all, but for those who profit from the information more details about the shape are needed.
Might this be tagging tooooooooooooooooo-far? 
Instead of “incline”, it might be better to use “camber” or similar, so as to avoid confusion with longitudinal incline. The word “cant” is also used, but has several meanings: Cant (road and rail) - Wikipedia and so might be confusing.
I would be inclined to only add such a tag where there is adverse camber (typically something like the whole road slopes down to the right gutter, but the curve of the road is going left) or excessive camber, e.g. the very edge of the road surface becomes problematically steep, in particular for pedestrians and cyclists (this can be exacerbated where the road surface is natural cobble or similar).
Note that sometimes the gutter is in the middle of the road, as in really old single-lane streets.
4 Likes
I guess this proposed tag will be applied mostly (95%) on sidewalks with a constant lateral incline. Those 95% are covered perfectly on this proposal.
For the remaining 5% of ways with that tag, I would not try too hard. If you tag :left_side (and :middle) and :right_side you could get the next 4.9% and the 0.1% rest we can miss, but that’s OK.
1 Like
Similarly, a router could benefit from knowing whether a tight curve in a road is banked or not. Banking toward the center of the curve would raise the practical speed for the road, but sometimes a poorly designed road might be banked too little, forcing a slowdown.
The problem I think exist with this proposed tag is WHERE the value applies, whether it it incline or camber or anything referring to the road cross section profile. Do we start breaking ways up into straight and curved sections to all for the different values on curves and possible banking? In the UK it is possible for roads to be wider on curves, so even if the side and crown elevations are the same, the incline angle changes from straight to through the curve and back to any straight.
Perhaps such a value should be recorded at a node along the way, not the way itself.
1 Like