[Tagging] RFC - Feature Proposal - area of steps for pedestrians.
61sundowner at gmail.com
Tue Apr 9 22:45:14 UTC 2019
On 10/04/19 01:42, Tobias Knerr wrote:
> On 29.03.19 07:05, Warin wrote:
> Detailed steps would be great for 3d rendering, so I'm very interested
> in the topic as a data consumer. However, reading the proposal leaves me
> with open questions. Could you describe the intended logic for
> constructing the geometry of the individual steps from an area_steps
> relation? I can think of several good heuristics myself, but the notable
> "same number of nodes" rule makes me think you have something specific
> in mind.
> I do have some concerns regarding ease of mapping:
> - I'm not convinced that a relation (rather than an area:highway
> polygon) is necessary in typical cases. Usually, the most acute angles
> of the polygon mark the point where the bottom/top border is separated
> from the side border. It would seem sufficient to draw explicit lateral
> ways only in cases where that assumption doesn't hold.
That assumes that the laterals are straight lines, not always the case.
Then consider Relation: 9443810 - if drawn as an area it would be 10 right angled corners.
How would an area aid determination of what is the top, bottom and laterals?
> - Requiring the same number of nodes for the upper and lower way seems
> very fragile. It's unexpected that inserting nodes into a way (or
> removing them from a perfectly straight line) would invisibly break data.
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!
> Also, you suggest that different step_count values for the left and
> right side could be modelled using your relation. But I don't see how I
> could tell whether the steps are "missing" from the top or bottom?
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.
And I'll add to them :)
If another way in another relation overlays one of the ways in a step relation it would make sense to incorporate it into the relation ..
and now there would be, for example 3 ways forming the upper wayS .. and if duplication is required then the lower way would need to be split similarly.
More information about the Tagging