[Tagging] RFC - Feature Proposal - area of steps for pedestrians.
osm at tobias-knerr.de
Thu Apr 11 21:28:26 UTC 2019
On 10.04.19 00:45, Warin wrote:
> But then if they are curved or have corners then in order to project
> that correctly form one way to the other they would need to have
> corresponding nodes.
> Say if is curved at the top but not at the bottom .. if the curve goes
> straight down .. ok .. but what if it recedes to the side as it goes down?
> Not convinced either way!
A decent heuristic is to connect each node from the upper border to the
closest point (not necessarily a node) on the lower border, and vice
versa. Then you place steps at regular intervals along these connections.
For common step shapes, this should produce the expected results. I
might be able to cobble together a proof of concept over the next few
days if that could help convince you?
Note that the method I describe above does not even try to work for
winding steps (i.e. those which you don't ascend in a straight line).
But there are other algorithms that would work for those, and the two
classes of steps could potentially be distinguished with a tag.
> Only by using an incline tag on the upper/lower ways ... I think at this
> Then you also have the thought of unequal number of steps (Relation:
> or uneven rise/run... (no example as yet)
> All good questions.
>From my point of view, what we're discussing here is what the "medium
complexity" solution for steps should look like.
On the simple end of the spectrum, most steps can be represented just
fine as a single way.
On the super-detailed end, I'm sure that we'll want an approach based on
mapping individual steps as ways. It's easy to understand _and_ it works
for pretty much every weird special case (e.g. uneven rise/run).
So what we should be looking for, imo, is something in between that
saves us from having to use that kind of extreme micro-mapping for too
To me, this means is that it's ok if it doesn't work for everything. Of
course, it should still work for a sufficient amount of cases to be
worth bothering with, and you gave an example (the shape with lots of
right angles) where a relation works, and a polygon does not. That's
indeed a downside.
What this also means, though, is that it actually has to feel less
complex than the detailed solution to mappers. And that's what I'm not
so sure about with relation-based solutions. I've seen many mappers
avoid relations in favour of approaches that arguably involve
duplication and extra work (e.g. using addr:street instead of
associatedStreet). Based on that, I feel that polygons might be a better
candidate for that "medium complexity" sweet spot than relations: A bit
less powerful, but (perceived to be) much more approachable.
More information about the Tagging