Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Warin

On 30/03/19 11:13, Nick Bolten wrote:
I like the idea of addressing the area-ness of steps! Thanks for 
taking the initiative on this. I have a couple questions and ideas 
that are hopefully helpful.


# curb (kerb) lines

What would you think of tagging each step way as a kerb line? e.g., 
each step way could be barrier=kerb, kerb=raised, and could have other 
relevant kerb tags like kerb:height.


This would make it very easy to know what tags to use for virtually 
any curb-like feature in OSM with non-trivial length: make it a curb 
line. This would also dovetail with other curb line conventions, such 
as knowing which side is higher (the side on the right of the way).


Rather tedious to map anything other than a straight line! See the 
Queluz National Palace for example. Or relation 9443810 - it turns 3 
right angle corners..


# Determining upper/lower steps + number of members

The example says you would set one step to role=lower and one to 
role=upper. Does this mean that the relation effectively applies to a 
single step?


No. It applies to a set of steps ... you map the top and bottom and 
identify each. You could do it .. very small area! For a single step I'd 
rather go with your barrier curb idea.


On a stairway, a single vertical part of a step could of course serve 
as both upper and lower, so we'd need more information if a single 
relation described the whole stairway.


As a follow-up, what about using the order of relation members, like 
how bus routes do? This might make it easier to map whole stairways: 
order = ascending (literally). You could then use the role to describe 
segments if the stairway splits, though a role like role=1 might be off.


err does not work. They form a closed way. As such one lateral will be 
connecting from top to bottom, while the other will be connecting from 
bottom to top.
Best to have the direction of the lateral way point upwards, but even 
that does not matter as the top is identified by the role in the 
relation as is the bottom.


# one-to-one way nodes?

For mapping a step, the proposal says, "Create 2 ways, one for the 
upper part of the steps, another for the lower. They should have the 
same number of nodes and have the same direction."


I'm wondering why they need to have the same number of nodes. It seems 
to me that the Queluz National Palace example would actually be 
impossible to map as a single area this way, since it splits into two 
stairways at the top. But I might be misunderstanding the proposal.
Err no you don't misunderstand it. I think it is a function for the 
renders to ease drawing of these non linear ways such as the Queluz 
National Palace example, connections between the upper and lower way 
nodes form the point where rendering lines change direction...


The Queluz National Palace example needs 3 areas to be defined. But the 
present imagery does not have enough definition for me to do that. I 
have roughly done th elower bit, the upper two are simple ways..


The Sydney Opera House has quite a few steps - not all of them mapped. 
But they are much easier to map being larger + linear and with the 
better imagery we have with the NSW LPI Imagery. I have just done 
relation 9443810 for a set as mentioned above.





# In combination with one or more highway=steps ways

It's fairly complicated to route on areas, and this one in particular 
seems even moreso. What would you think of recommending mapping both 
an area (which is good for rendering/barriers/advanced routing) and 
one or more highway=steps (which is good for routing + network 
analysis + attaching to a building entrance) ways?


Yep. I think;
 the laterals should be tagged as steps - that way they can be used for 
routing and hand rails and number of steps.
the upper and lower ways should be tagged as footways - that way they 
can be used for routing .. and tactile paving..


This would aid routing as any connecting way to any of the ways - top, 
bottom or lateral should route.


-- Still thinking on it. Mixed feeling on the suggestion 
of providing a central way of steps .. the 2 sides would handle routing.



On Thu, Mar 28, 2019, 8:06 PM Warin <61sundow...@gmail.com 
> wrote:


Hi,

This one has been sitting for a long while! Still not certain
about some
aspects of it.

See what you make of it.

https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps


Discussion here for preference.


___
Tagging mailing list
Tagging@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Nick Bolten
I like the idea of addressing the area-ness of steps! Thanks for taking the
initiative on this. I have a couple questions and ideas that are hopefully
helpful.

# curb (kerb) lines

What would you think of tagging each step way as a kerb line? e.g., each
step way could be barrier=kerb, kerb=raised, and could have other relevant
kerb tags like kerb:height.

This would make it very easy to know what tags to use for virtually any
curb-like feature in OSM with non-trivial length: make it a curb line. This
would also dovetail with other curb line conventions, such as knowing which
side is higher (the side on the right of the way).

# Determining upper/lower steps + number of members

The example says you would set one step to role=lower and one to
role=upper. Does this mean that the relation effectively applies to a
single step? On a stairway, a single vertical part of a step could of
course serve as both upper and lower, so we'd need more information if a
single relation described the whole stairway.

As a follow-up, what about using the order of relation members, like how
bus routes do? This might make it easier to map whole stairways: order =
ascending (literally). You could then use the role to describe segments if
the stairway splits, though a role like role=1 might be off.

# one-to-one way nodes?

For mapping a step, the proposal says, "Create 2 ways, one for the upper
part of the steps, another for the lower. They should have the same number
of nodes and have the same direction."

I'm wondering why they need to have the same number of nodes. It seems to
me that the Queluz National Palace example would actually be impossible to
map as a single area this way, since it splits into two stairways at the
top. But I might be misunderstanding the proposal.

# In combination with one or more highway=steps ways

It's fairly complicated to route on areas, and this one in particular seems
even moreso. What would you think of recommending mapping both an area
(which is good for rendering/barriers/advanced routing) and one or more
highway=steps (which is good for routing + network analysis + attaching to
a building entrance) ways?

Best,

Nick

On Thu, Mar 28, 2019, 8:06 PM Warin <61sundow...@gmail.com> wrote:

> Hi,
>
> This one has been sitting for a long while! Still not certain about some
> aspects of it.
>
> See what you make of it.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps
>
>
> Discussion here for preference.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians. -constant width stairs

2019-03-29 Thread Warin

On 30/03/19 10:43, Christoph Hormann wrote:

On Saturday 30 March 2019, Warin wrote:

However where the stair width is large, say 100s of meters, picking
the centre becomes harder.

That's an editor UI problem, not a data model problem.


Most renders pay no attention to the width
so the rendering is poor.

That's because almost all rendering software lacks native support for
ground unit operations so this is relatively complicated to implement.

But designing data models to work around limitations of current
software, in other words:  Suggesting mappers to invest thousands of
hours of work to spare software developers the need to learn what a
projection scale factor is, that is not an approach i would recommend.


Ok. But for edge cases of non rectangular, non even steps .. this approach 
could be a solution?



But i am getting carried away...


Feel free!
Just 'measured' the Sydney Opera House steps - 85 m wide. Certainly seems wider 
when you walk them,
and narrower when it is full of people sitting/standing to watch something.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians. -constant width stairs

2019-03-29 Thread Christoph Hormann
On Saturday 30 March 2019, Warin wrote:
>
> However where the stair width is large, say 100s of meters, picking
> the centre becomes harder.

That's an editor UI problem, not a data model problem.

> Most renders pay no attention to the width 
> so the rendering is poor.

That's because almost all rendering software lacks native support for 
ground unit operations so this is relatively complicated to implement.

But designing data models to work around limitations of current 
software, in other words:  Suggesting mappers to invest thousands of 
hours of work to spare software developers the need to learn what a 
projection scale factor is, that is not an approach i would recommend.

But i am getting carried away...

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians. -constant width stairs

2019-03-29 Thread Warin

On 29/03/19 22:41, Christoph Hormann wrote:


   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.  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.



Where the stair width is narrow it is easy to pick the centre for a simple way 
and tag it for the width.

However where the stair width is large, say 100s of meters, picking the centre 
becomes harder.
Most renders pay no attention to the width so the rendering is poor.
Routers too will think that the distance is greater than reality.

By placing laterals at each side these issues might be minimised.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians. -Tags on the ways

2019-03-29 Thread Warin

On 29/03/19 20:12, Martin Koppenhoefer wrote:


Am Fr., 29. März 2019 um 08:28 Uhr schrieb Warin 
<61sundow...@gmail.com >:




should the upper and lower ways be tagged with highway=footway so
as to connect the two laterals?
should the laterals be tagged with highway=steps
That may aid editing, rendering and routing...



it would be in the tradition of pedestrian routing around the squares, 
now also around steps ;-)
Seriously, I would not tag any of these with highway=steps, I would 
rather draw another way for the routing, in the middle of the laterals 
(actually the laterals may often not be needed at all, if they are 
just straight lines between the upper and lower start and endpoints. 
They might be needed for topology reasons if you want to connect other 
things explicitly, e.g. retaining walls, buildings, etc.).


The laterals would be required for handrails, differing number of steps 
from side to side.


Adding tags on the ways does several things;
provides present routing on any connection to any outer way - including 
the laterals

present rendering of the out side area
stops validators and quality tools complaining about the ways.
shows the shape of the area. While most are rectangular some are not.

By making a system that maps all occurrences in the same way there are 
no edge cases that have to have specials.


The relation will still draw attention, but that is only one 
warning/error rather than 5.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians. Compatibility and barriers.

2019-03-29 Thread Warin

On 29/03/19 20:12, Martin Koppenhoefer wrote:


Am Fr., 29. März 2019 um 08:28 Uhr schrieb Warin 
<61sundow...@gmail.com >:


On 29/03/19 17:59, Martin Koppenhoefer wrote:


can you explain how it relates to this proposal?

https://wiki.openstreetmap.org/wiki/Relations/Proposed/Area



That proposal is very broad , it defines implicit areas of any
kind, steps, ramps, flat bits . I think that is too much in one
proposal to consider and detail.



As far as I see you proposed the same tagging for your proposal, 
"type=area" for the relation, why so generic if the scope is reduced 
to area steps?

Compatibility. If/when that goes ahead.
You are also including the same proposed roles and concepts for the 
stairmodelling, "upper" and "lower". The main difference to the 
original area relation proposal is that you didn't add the other 
applications, like defining implicit or adding explicit barrier 
features and punctual exceptions to these barriers.


I think barriers on stairs could be simply added as separate ways. This 
would allow for barriers to be across the stairs at any angle, for any 
length, for any pattern. It requires no additional tags.

Nor am I defining ramps, etc. Just steps is hard enough.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians. -inconstancy across the step face.

2019-03-29 Thread Warin

On 30/03/19 05:16, Christoph Hormann wrote:

On Friday 29 March 2019, Martin Koppenhoefer wrote:

* 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".

That would not be a very sensible assumption since that would be
impossible for any stairs where the upper and lower end are not
equidistant across their whole length because then not all steps can
have a constant depth.


In this case the stairs can have a different number of steps from on side to 
the other.
This keeps the same 'rise' and 'run' (technical step terms for 'depth' and 
'height') the same for all the steps.
Making the step rise and run is important for safety .. it is also cheaper!
Think you will find most modern steps follow this method of construction, at 
least the ones I have come across do.

What of the case where the stair rise/run is not constant?
Document the rise/run on each lateral ... assuming that the change across the 
step facer is consistent.
If it is inconsistent, separate the areas at the line/s of inconsistency.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Runway Holding Positions

2019-03-29 Thread Steven Estes
Yup.  Typo on my part.  Digging some more, I have a better understanding of
the tagging system.  It doesn't look like holding_position:type is seeing a
ton of use, and from what I can tell, it'd be more conventional and less
onerous to drop "type" and go with holding_position=.  I can document that
in the aeroway=holding_position tag page, with links back to that page from
holding_position=runway, =intermediate, & =ILS.  I'm planning on using the
same format as the How to Map section of waterway=dock
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Ddock


On Fri, Mar 29, 2019 at 3:37 PM Brad Neuhauser 
wrote:

> On Fri, Mar 29, 2019 at 2:14 PM Steven Estes  wrote:
>
>> Sorry, I was confused.  It looks the tag format would be
>> aeroway=holding_position:type=runway.
>>
>
> I think you have a typo here, in practice this would be two separate
> key/value tags: aeroway=holding_position and holding_position:type=runway.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Runway Holding Positions

2019-03-29 Thread Brad Neuhauser
On Fri, Mar 29, 2019 at 2:14 PM Steven Estes  wrote:

> Sorry, I was confused.  It looks the tag format would be
> aeroway=holding_position:type=runway.
>

I think you have a typo here, in practice this would be two separate
key/value tags: aeroway=holding_position and holding_position:type=runway.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Runway Holding Positions

2019-03-29 Thread Steven Estes
Sorry, I was confused.  It looks the tag format would be
aeroway=holding_position:type=runway.  As found here...
https://taginfo.openstreetmap.org/keys/holding_position%3Atype

So, the water is a bit muddy for me.  I can use
aeroway=holding_position:type, but if there would be a reason to prefer a
different format, let me know.  In the meantime, I'll try to get a bit
smarter on the tagging system.

On Fri, Mar 29, 2019 at 2:29 PM Steven Estes  wrote:

> I posted my plan to the discussion page.  TOGA points out that :runway,
> :intermediate, and :ILS are already in use (about 1000 uses total).  Given
> this, would folks still recommend holding_position=runway, or would
> holding_position:runway be more appropriate?   Thanks much.
>
> On Fri, Mar 29, 2019 at 11:13 AM Paul Johnson  wrote:
>
>> Flightgear uses this for world generation.
>>
>> On Thu, Mar 28, 2019, 12:47 Mateusz Konieczny 
>> wrote:
>>
>>> "Inclusion of these markings will allow applications to warn the pilot
>>> prior to entering the
>>> runway safety area without permission from air traffic control. "
>>>
>>> I am pretty sure that OSM is not suitable source of data for maps used
>>> by pilots.
>>> Can you give examples of countries where it is OK to use OSM map data
>>> for such purpose?
>>>
>>> Mar 28, 2019, 6:27 PM by tapes...@gmail.com:
>>>
>>>
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/runway_holding_position
>>>
>>> Proposing the addition of runway holding position markings (commonly
>>> called hold lines). Runway holding position markings are painted markings
>>> on an airport surface that identify the runway safety area. At controlled
>>> airports, these markings indicate where an aircraft is to stop if the
>>> aircraft does not have permission to enter the runway. When exiting a
>>> runway, an aircraft is not considered clear of that runway until all parts
>>> of the aircraft have crossed the holding position marking. The runway
>>> holding position is painted across the runway or taxiway and consists of
>>> two solid lines on the side that is clear of the runway safety area and two
>>> dashed lines on the other side.
>>>
>>> Greatly appreciate any comments folks have.
>>>
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Runway Holding Positions

2019-03-29 Thread Steven Estes
I posted my plan to the discussion page.  TOGA points out that :runway,
:intermediate, and :ILS are already in use (about 1000 uses total).  Given
this, would folks still recommend holding_position=runway, or would
holding_position:runway be more appropriate?   Thanks much.

On Fri, Mar 29, 2019 at 11:13 AM Paul Johnson  wrote:

> Flightgear uses this for world generation.
>
> On Thu, Mar 28, 2019, 12:47 Mateusz Konieczny 
> wrote:
>
>> "Inclusion of these markings will allow applications to warn the pilot
>> prior to entering the
>> runway safety area without permission from air traffic control. "
>>
>> I am pretty sure that OSM is not suitable source of data for maps used by
>> pilots.
>> Can you give examples of countries where it is OK to use OSM map data for
>> such purpose?
>>
>> Mar 28, 2019, 6:27 PM by tapes...@gmail.com:
>>
>>
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/runway_holding_position
>>
>> Proposing the addition of runway holding position markings (commonly
>> called hold lines). Runway holding position markings are painted markings
>> on an airport surface that identify the runway safety area. At controlled
>> airports, these markings indicate where an aircraft is to stop if the
>> aircraft does not have permission to enter the runway. When exiting a
>> runway, an aircraft is not considered clear of that runway until all parts
>> of the aircraft have crossed the holding position marking. The runway
>> holding position is painted across the runway or taxiway and consists of
>> two solid lines on the side that is clear of the runway safety area and two
>> dashed lines on the other side.
>>
>> Greatly appreciate any comments folks have.
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Christoph Hormann
On Friday 29 March 2019, Martin Koppenhoefer wrote:
>
> > * 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".

That would not be a very sensible assumption since that would be 
impossible for any stairs where the upper and lower end are not 
equidistant across their whole length because then not all steps can 
have a constant depth.

But my point was a different one.  A polygon is by definition planar.  
If your modeling defines a non-planar outline (which it obviously does 
when you can have arbitrarily shaped upper and lower limits) then you 
need to make assumptions regarding how the shape derives from this 
outline.

> While I agree with you that for 3d you need height information (the
> area proposal has a suggestion for this), [...]

You need this for any rendering of the stairs that visualizes the 
individual steps in some form (because their form defines a 3d 
geometry - even if you don't render it in 3d).

> in the end, all areas can be represented as polygons [...]

Well - that depends on how you define "area" obviously.  A polygon is an 
attempt to describe a two dimensional planar entity through circular 
linestring representations of its edges.  Even for 2d entities where 
this is possible (i.e. that are planar and have a well defined inside 
and outside) it is often not the most efficient way of representing 
them.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Runway Holding Positions

2019-03-29 Thread Paul Johnson
Flightgear uses this for world generation.

On Thu, Mar 28, 2019, 12:47 Mateusz Konieczny 
wrote:

> "Inclusion of these markings will allow applications to warn the pilot
> prior to entering the
> runway safety area without permission from air traffic control. "
>
> I am pretty sure that OSM is not suitable source of data for maps used by
> pilots.
> Can you give examples of countries where it is OK to use OSM map data for
> such purpose?
>
> Mar 28, 2019, 6:27 PM by tapes...@gmail.com:
>
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/runway_holding_position
>
> Proposing the addition of runway holding position markings (commonly
> called hold lines). Runway holding position markings are painted markings
> on an airport surface that identify the runway safety area. At controlled
> airports, these markings indicate where an aircraft is to stop if the
> aircraft does not have permission to enter the runway. When exiting a
> runway, an aircraft is not considered clear of that runway until all parts
> of the aircraft have crossed the holding position marking. The runway
> holding position is painted across the runway or taxiway and consists of
> two solid lines on the side that is clear of the runway safety area and two
> dashed lines on the other side.
>
> Greatly appreciate any comments folks have.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Martin Koppenhoefer
Am Fr., 29. März 2019 um 12:43 Uhr schrieb Christoph Hormann :

>
> * 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
representation.




> 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.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Christoph Hormann
On Friday 29 March 2019, Warin wrote:
> Hi,
>
> This one has been sitting for a long while! Still not certain about
> some aspects of it.
>
> See what you make of it.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps

First agreement with Martin that you need to decide if you want to make 
a proposal for defining some polygon-like 3d surfaces in general of 
some sort or specifically to deal with steps only.  In the latter case 
this should be clear from the tagging, i.e. something like 
type=steps_area and nothing generic.

Two more general notes on the more fundamental underlying problem:  

* 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.

* 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.  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.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Martin Koppenhoefer
I believe the highway=steps running over steps that are also mapped as an
area, should be flagged in some way to facilitate their omission in
rendering. E.g. has_area_representation=yes (or something more concise). Or
they could be added to the area relations with a special role, e.g. "graph".

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Martin Koppenhoefer
Am Fr., 29. März 2019 um 08:28 Uhr schrieb Warin <61sundow...@gmail.com>:

> On 29/03/19 17:59, Martin Koppenhoefer wrote:
>
>
> can you explain how it relates to this proposal?
>
> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Area
>
>
> That proposal is very broad , it defines implicit areas of any kind,
> steps, ramps, flat bits . I think that is too much in one proposal to
> consider and detail.
>
>

As far as I see you proposed the same tagging for your proposal,
"type=area" for the relation, why so generic if the scope is reduced to
area steps? You are also including the same proposed roles and concepts for
the stairmodelling, "upper" and "lower". The main difference to the
original area relation proposal is that you didn't add the other
applications, like defining implicit or adding explicit barrier features
and punctual exceptions to these barriers.




>
> should the upper and lower ways be tagged with highway=footway so as to
> connect the two laterals?
> should the laterals be tagged with highway=steps
> That may aid editing, rendering and routing...
>


it would be in the tradition of pedestrian routing around the squares, now
also around steps ;-)
Seriously, I would not tag any of these with highway=steps, I would rather
draw another way for the routing, in the middle of the laterals (actually
the laterals may often not be needed at all, if they are just straight
lines between the upper and lower start and endpoints. They might be needed
for topology reasons if you want to connect other things explicitly, e.g.
retaining walls, buildings, etc.).

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Intermittently unprotected cycle track

2019-03-29 Thread Richard Fairhurst
Thanks everyone for the comments!

althio wrote:
> My preference would be to keep the geometry, map it as a continuous
> highway=cycleway.
> For the bits without divider, I don't like protected=no however.
> I would go with no additional tagging, and more geometry (as you said:
> crossings and junctions), and let the geometry speaks.

On balance I agree and I'll go for this solution.

Please send out a search party if I haven't returned in three days from the
maze of nested relations that is cycle routes in East London.

cheers
Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Warin

On 29/03/19 18:51, Mateusz Konieczny wrote:




Mar 29, 2019, 8:26 AM by 61sundow...@gmail.com:

On 29/03/19 17:59, Martin Koppenhoefer wrote:



sent from a phone

On 29. Mar 2019, at 07:05, Warin <61sundow...@gmail.com
> wrote:


This one has been sitting for a long while! Still not certain
about some aspects of it.

See what you make of it.

https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps


Discussion here for preference.



can you explain how it relates to this proposal?

https://wiki.openstreetmap.org/wiki/Relations/Proposed/Area



That proposal is very broad , it defines implicit areas of any
kind, steps, ramps, flat bits . I think that is too much in one
proposal to consider and detail.


This proposal only does steps. Just steps. It details how larger
step areas, > say 5 m width, can be mapped.

Consider in this proposal;
should the upper and lower ways be tagged with highway=footway so
as to connect the two laterals?
should the laterals be tagged with highway=steps
That may aid editing, rendering and routing...

It may be useful to mention relation to "area:highway=steps" tagging - 
is it a competing

incompatible, double tagging of the same feature or something else.


That fails in many ways;

does not detail upper/lower ways that may not be straight lines and 
could be inclined

does not detail laterals that may not be straight lines
cannot detail differing number of steps from side to side
cannot have handrails...

Thanks for pointing it out I'll add a link later.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Mateusz Konieczny



Mar 29, 2019, 8:26 AM by 61sundow...@gmail.com:

> On 29/03/19 17:59, Martin Koppenhoefer  wrote:
>
>>
>>
>> sent from a phone
>>
>> On 29. Mar 2019, at 07:05, Warin <>> 61sundow...@gmail.com 
>> >> >wrote:
>>  
>>
>>> This one has been sitting for a long while!Still not certain 
>>> about some aspects of it.
>>>  
>>>  >>> See what you make of it.
>>>  
>>>  >>> https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps 
>>> 
>>>  
>>>  
>>>  >>> Discussion here for preference.
>>>
>>
>>
>> can you explain how it relates to this proposal?
>>
>> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Area 
>> 
>>
>>
>
> That proposal is very broad , it defines implicit areas of any kind,
> steps, ramps, flat bits . I think that is too much in one proposalto 
> consider and detail.
>  
>  
>  This proposal only does steps. Just steps. It details how largerstep 
> areas, > say 5 m width, can be mapped. 
>  
>  Consider in this proposal;
>  should the upper and lower ways be tagged with highway=footway so asto 
> connect the two laterals? 
>  should the laterals be tagged with highway=steps 
>  That may aid editing, rendering and routing...  
>
It may be useful to mention relation to "area:highway=steps" tagging - is it a 
competing 
incompatible, double tagging of the same feature or something else.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Warin

On 29/03/19 17:59, Martin Koppenhoefer wrote:



sent from a phone

On 29. Mar 2019, at 07:05, Warin <61sundow...@gmail.com 
> wrote:


This one has been sitting for a long while! Still not certain about 
some aspects of it.


See what you make of it.

https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps


Discussion here for preference.



can you explain how it relates to this proposal?

https://wiki.openstreetmap.org/wiki/Relations/Proposed/Area



That proposal is very broad , it defines implicit areas of any kind, 
steps, ramps, flat bits . I think that is too much in one proposal to 
consider and detail.



This proposal only does steps. Just steps. It details how larger step 
areas, > say 5 m width, can be mapped.


Consider in this proposal;
should the upper and lower ways be tagged with highway=footway so as to 
connect the two laterals?

should the laterals be tagged with highway=steps
That may aid editing, rendering and routing...





___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Martin Koppenhoefer


sent from a phone

> On 29. Mar 2019, at 07:05, Warin <61sundow...@gmail.com> wrote:
> 
> This one has been sitting for a long while! Still not certain about some 
> aspects of it.
> 
> See what you make of it.
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps
> 
> 
> Discussion here for preference.


can you explain how it relates to this proposal?

https://wiki.openstreetmap.org/wiki/Relations/Proposed/Area


Cheers, Martin 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-03-29 Thread Warin

Hi,

This one has been sitting for a long while! Still not certain about some 
aspects of it.


See what you make of it.

https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps


Discussion here for preference.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging