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 > stage. > Then you also have the thought of unequal number of steps (Relation: > 9441459) > 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 many steps. 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. Tobias _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
