Talk:Tag:barrier=full-height turnstile
@ Dieterdreist There is no reason why it should apply to way. But osmcarto-rendering was certainly right. Please add that again.--geozeisig (talk) 07:11, 20 January 2019 (UTC)
- Sorry for the carto tags, it wasn’t my intention to remove them, it’s fixed now. Wrt the way: full height turnstiles tend to be oneway, and you cannot capture this with a node, so there are good reasons for tagging it on a way. —Dieterdreist (talk) 21:17, 20 January 2019 (UTC)
Undo of full-height turnstile [node-only]
@Dieterdreist: regarding edit "this can be tagged on a short strip of way, which can help to represent direction in a more stable way" Thanks for reviewing. So you are talking about these 3 objects (https://overpass-turbo.eu/s/ZSz) of currently 1.2k of all? I agree full-height turnstile lets the walkers only flow in one direction. But why the mappers could just cut the linear way (the walking path) twice for adding the oneway=yes tag, and put an additional node in the middle of the way segment for the barrier full-height turnstile object? This could be also explained a bit more detailed at the wiki article? Or would that be wrong tagging? Thus i still would change it back to node-only for barrier=full-height turnstile... --MalgiK (talk) 09:01, 9 November 2020 (UTC)
- Currently there are at least 17 objects which are mapped as ways: https://overpass-turbo.eu/s/ZSM (as the "oneway" tag does not apply to pedestrians, you have to look at foot:backward=no tags as well, and probably objects without any such tags often may simply be lacking the tag. When looking for problems, you should rather look at all those 1,2k full height turnstiles where it is not clear whether they can be used only in one direction, and which is this direction. Many people using an inappropriate representation does not imply that a rarely used better representation is wrong. --Dieterdreist (talk) 09:19, 9 November 2020 (UTC)
- Yes, counting the cases is no argument. Ah okay the foot:backward=no is actually mostly more interesting (as oneway=yes) for these kind of use-cases. So lets add the foot:backward=no information to the article page?
- Regarding node or way or both element usage, i'm still not really convinced to use the full-height_turnstile on linear way objects which represents an part of the walking-path-way. For me it makes no really sense to draw a point-shaped object as a line along the path for a function to block this path across. Linear objects might be okay for cases to demonstrate an across positioned barrier, (like this example) But then of course without foot:backward=no tag. I mean if it is a big turnstile and the mapper are doing detail tagging they might draw a circle (or rectangle) area for it, but this is still no real linear part which could be use for the path-way object. Maybe for this detail mapping scenario the path-way could be cut twice exactly there where the path-way is crossing twice the turnstile circle line. This inner middle cut path-way could be used for foot:backward=no tagging. So i would not recommend user to map this thing using the the scheme like this example and still i would further recommend to only using
and for detail mapping 
elements, while also showing this on the article page. --MalgiK (talk) 09:05, 10 November 2020 (UTC)
- While you could represent these as a node, they actually do have a "length">=0.6-1m (way inside the "box") because there must be room for a person to go inside, unlike for example bollards, gates, ropes, lift-gates and many more barriers, which only are very few centimeters long / thick. The node does not actually have advantages, only disadvantages, or am I misguided? --Dieterdreist (talk) 11:41, 10 November 2020 (UTC)
- For a usual road lets say app. 3m width we are mostly do a modeling from the area down to a way as the street center line. And the same happened here, the majority of mappers do this for the box of 1m, they model it down to a node. So the advantage for mapping it as a node object, is it takes much less time for mapping, and the is no big advantage if a detail mapper is tagging it as a area object, e.g. in regard of what a map would show a map consumer. Mapping as a node is also maybe mostly preferred especially if there are no high res aerial images available. Regarding the disadvantages I assume you have the in your mind, that you want block the traffic flow in one direction for routing. Of course this couldn't be done with tags on the node object, because of course a node has no real direction in regard to the corresponding way for routing. But what about, would/could maybe one for these Relation:restrictions solve this issue for routing? So that the tag barrier=full-height_turnstile and oneway/foot:backward doesn't need to be added to the path-way?--MalgiK (talk) 15:22, 10 November 2020 (UTC)
- I agree, it is less time. How much? Maybe 4 seconds (add one node more, select both nodes and split). While I do not believe that mapping them as nodes is a good representation (because direction is important here), I also do not remove the suggestion to do it from the wiki. Let's remind us we are discussing removing the "map on way" suggestion, although it is in use and there is nothing wrong with it. If you think it is too timeconsuming to map as way, keep on mapping them as nodes, but please, just keep the ways icon. --Dieterdreist (talk) 18:10, 10 November 2020 (UTC)
- The same objections you have for node (because of technical/logic direction tagging issue) i have for way along the path-way. Yes we talking about "removing the "map on way" suggestion", but you ask me before & and i did reply to "The node does not actually have advantages, only disadvantages, or am I misguided?" I didn't change it back and i wouldn't do it without your acceptance, that's why i talking here with you. So your main argument was the direction issue. I already agreed to it, but as said i would like to use another scheme for it. So better i open a new chapter for it see below. --MalgiK (talk) 01:00, 11 November 2020 (UTC)
- I agree, it is less time. How much? Maybe 4 seconds (add one node more, select both nodes and split). While I do not believe that mapping them as nodes is a good representation (because direction is important here), I also do not remove the suggestion to do it from the wiki. Let's remind us we are discussing removing the "map on way" suggestion, although it is in use and there is nothing wrong with it. If you think it is too timeconsuming to map as way, keep on mapping them as nodes, but please, just keep the ways icon. --Dieterdreist (talk) 18:10, 10 November 2020 (UTC)
- For a usual road lets say app. 3m width we are mostly do a modeling from the area down to a way as the street center line. And the same happened here, the majority of mappers do this for the box of 1m, they model it down to a node. So the advantage for mapping it as a node object, is it takes much less time for mapping, and the is no big advantage if a detail mapper is tagging it as a area object, e.g. in regard of what a map would show a map consumer. Mapping as a node is also maybe mostly preferred especially if there are no high res aerial images available. Regarding the disadvantages I assume you have the in your mind, that you want block the traffic flow in one direction for routing. Of course this couldn't be done with tags on the node object, because of course a node has no real direction in regard to the corresponding way for routing. But what about, would/could maybe one for these Relation:restrictions solve this issue for routing? So that the tag barrier=full-height_turnstile and oneway/foot:backward doesn't need to be added to the path-way?--MalgiK (talk) 15:22, 10 November 2020 (UTC)
- While you could represent these as a node, they actually do have a "length">=0.6-1m (way inside the "box") because there must be room for a person to go inside, unlike for example bollards, gates, ropes, lift-gates and many more barriers, which only are very few centimeters long / thick. The node does not actually have advantages, only disadvantages, or am I misguided? --Dieterdreist (talk) 11:41, 10 November 2020 (UTC)
direction flow tagging scheme
@Dieterdreist: Seems currently there are first attempts to add some direction control information for barrier full-height turnstiles objects. There are options to use a oneway=yes or a more specific tagging for transportation mode "foot" by using a tag like the foot:backward=no. This seems to work only for linear way objects, which are maybe located close to the barrier full-height turnstiles or the barrier full-height turnstiles definition is tagged on the same way-segment. I wonder if there might be a second alternative scheme for it to use a Relation:restriction with no_entry very similar to the implementation by this example, but here instead a bit more specific for the foot transportation mode. As reference i found this kind of proposed tagging scheme even from you in a talk about "pseudo" oneways in connection when traffic sign traffic_sign=DE:267 is involved. You did yourself mention it ones a while in the forum, see this post. So what would such kind of restriction made it for a "foot" direction blocker only? And c/would it work at all? --MalgiK (talk) 01:00, 11 November 2020 (UTC)
- Maybe a restriction relation could work (technically, you could restrict the direction, but from my understanding, the restriction relations are about legal restrictions, while here we are in front of physical restrictions (even if you wanted to do something illegal by walking through the turnstile in the wrong direction, you could not, this is the point why it is "full-height"). Additionally, if the reason to avoid a way is simplicity and time saving, a relation will not improve the situation (at least not if "simplicity" is intended as simple for mappers, rather than simple for a computer). --Dieterdreist (talk) 16:41, 13 November 2020 (UTC)
- Yes, there is a difference between legal and physical restriction. I think the physical aspect of the object is already described by barrier=full-height_turnstile. The purpose of such a (restriction) relation would be to only give same routing information to the router (tagging for the router). And for the router to create a route it makes no difference if it is physical or legal (in such case a restriction is a restriction). Yes, it's more complex as a simply oneway definition. Okay, i just wanted that this option is mentioned (at least here on the talk page), mapper can decide in which way they what to map it. --MalgiK (talk) 17:15, 13 November 2020 (UTC)