<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 29. März 2019 um 12:43 Uhr schrieb Christoph Hormann <<a href="mailto:osm@imagico.de">osm@imagico.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
* you should be aware that you can't uniquely define the shape of a two <br>
dimensional surface in three dimensions exclusively through the shape <br>
of its outline.  You can do that in 2d (provided what you have has a <br>
defined outline) but not in 3d.  That is simple mathematics.  So you'd <br>
have to document what assumptions you make regarding the shape of the <br>
surface, otherwise the meaning of your proposal would be ill-defined.<br></blockquote><div><br></div><div><br></div><div>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).</div><div>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).<br></div><div><br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* tying yourself to the idea of polygons being the ideal way to map <br>
anything in OSM could prevent you from finding a both mapping and data <br>
use efficient way to document things.  You should keep in mind that >90 <br>
percent of stairs that exist are simple constant width + strait step <br>
stairs that can perfectly accurately be mapped with a linear <br>
highway=steps and a width tag. </blockquote><div><br></div><div><br></div><div>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 representation.<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> If you approach the problem with how to <br>
extend this method in ways that are (a) optional and backwards <br>
compatible, (b) make use of the information already present in the <br>
linear way mapping and (c) that cover most of the other <10 percent of <br>
the cases without the idea that the solution *has to be in the form of <br>
a polygon variant* that would more likely yield an efficient solution.</blockquote></div><div><br></div><div>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.</div><div><br></div><div>When it is needed, you can add the lateral connections.</div><div><br></div><div>Cheers,<br></div><div>Martin<br></div><div><br></div><div><br></div></div>