[Tagging] RFC - Feature Proposal - area of steps for pedestrians.
dieterdreist at gmail.com
Fri Mar 29 12:58:15 UTC 2019
Am Fr., 29. März 2019 um 12:43 Uhr schrieb Christoph Hormann <osm at imagico.de
> * you should be aware that you can't uniquely define the shape of a two
> dimensional surface in three dimensions exclusively through the shape
> of its outline. You can do that in 2d (provided what you have has a
> defined outline) but not in 3d. That is simple mathematics. So you'd
> have to document what assumptions you make regarding the shape of the
> surface, otherwise the meaning of your proposal would be ill-defined.
the general assumption for stairs is that all steps have the same height
and same "depth". This is not universally true, but especially for steps
which are big there is usually an architect involved who tries to make them
like this (people are very sensitive to varying step heights, just 1-2 cm
of an outlier and many people will have problems).
While I agree with you that for 3d you need height information (the area
proposal has a suggestion for this), the main application for area steps is
rendering IMHO, and unless you do 3D-rendering, all what you need is the
corner of the uppermost and lowest step with information how many steps are
in between (so you can interpolate, assuming equal width).
> * tying yourself to the idea of polygons being the ideal way to map
> anything in OSM could prevent you from finding a both mapping and data
> use efficient way to document things. You should keep in mind that >90
> percent of stairs that exist are simple constant width + strait step
> stairs that can perfectly accurately be mapped with a linear
> highway=steps and a width tag.
agreed (well, besides topology: with this model you cannot "connect" things
to the steps or "disconnect" them). This still means that there are >10%
steps where additional information is required to make a good graphical
> If you approach the problem with how to
> extend this method in ways that are (a) optional and backwards
> compatible, (b) make use of the information already present in the
> linear way mapping and (c) that cover most of the other <10 percent of
> the cases without the idea that the solution *has to be in the form of
> a polygon variant* that would more likely yield an efficient solution.
in the end, all areas can be represented as polygons (or approximated, see
triangles in 3D rendering for curved shapes), but this proposal (at least
the original one) doesn't define polygons by giving their closed outline,
on the contrary, the idea was to require only two opposing sides (of a
road, or the upper and lower ways of steps or of a slope) and imply the
"connections". This has the advantage that you do not get "crossing" ways
(to close the polygon) across the road, which would lead to confusion and
clutter the editing screen.
When it is needed, you can add the lateral connections.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging