Proposal talk:Advanced cycle barrier tagging

From OpenStreetMap Wiki
Jump to navigation Jump to search

Questions on organization

  1. *:type=* makes a meaningless suffix, when you are already using cycle_barrier=*. Indeed, there are more cycle_barrier=chicane and cycle_barrier=squeeze than others. The use of cycle_barrier:type=* is only for avoiding conflict, as copied from *_gate:type=*, which together with bollard=* should possibly be cleaned up too. I can't think of a cycle_barrier=* alternative in some use yet. For a new key, a general concept eg installation=* could be used for *=removable and *=fixed. cycle_barrier=* can then be left for any unspecified use.
  2. For width:*=*, width:carriageway=* is an outlier among sidewalk:wdith=*, cycleway:width=*, shoulder:width=*, etc. You are using overlap=*. When considered together with the above, you could change cycle_barrier:type=* to openings=*, then use openings:width=* instead of width:opening=*. Value format in words or numerals can be further debated.
  3. A particular downside is you have already proposed separation=* separately for cycleway:separation=*. Using *:separation=* for another meaning should really be avoided. It could be renamed to eg spacing=*.
  4. At first, I wanted to suggest changing *=angular to *=diagonal. But since you are already proposing other tags, can you make it as eg orientation=diagonal? This is similar to parking:orientation=*. Apparently according to key:orientation it is used for advertising=*.
  5. How to tag the angle if wanted? direction=*?
  6. Should *=single and *=squeeze be combined somehow? This can show the layout and structure separately.

Change summary:

  1. cycle_barrier=* --> installation=*
  2. cycle_barrier:type=* --> openings=*
  3. width:opening=* --> openings:width=*
  4. width:separation=* --> spacing=*
  5. cycle_barrier:type=angular --> orientation=diagonal (+ direction=*)
  6. cycle_barrier:type=squeeze --> ?

-- Kovposch (talk) 05:53, 13 July 2021 (UTC)

Hey, thanks for your many suggestions for a better organization of the tagging!
cycle_barrier --> installation: That's a good idea. However, I think it's too late for a change for other features like bollard=* or *_gate:type=*, since these have already become very widespread and experience unfortunately shows that changes of established schemes are hardly enforceable. But that doesn't mean that "installation" should be introduced here for cycle barriers! Does it make sense to use the namespace, cycle_barrier:installation=*?
width:separation --> spacing: This too is semantically better – I suggested width:separation=* mainly because it was suggested on the wiki a few years ago (see here on the cycle barrier talk page). But with only 64 uses in total at the moment, it's surely not too late to use a new value.
cycle_barrier:type --> openings: This suggestion has two weaknesses, in my opinion:
3 openings, 3 turns, type "triple"
3 openings, 2 turns, type "double"
  1. The categorization should be based on how the design affects passability. Therefore, it would probably be more important to use the number of "turns" instead of "openings" as a criterion. See, for example, the pictures on the right: Both have – in the literal sense – openings=3, but at the first one (so far type "double") I have to make only two turns, but at the second one (so far type "triple") three. For the passability especially with longer vehicles this is a fundamental difference. So you could use something like "turns" instead of "openings", but then width:opening=*/opening:width=* does not follow the semantics anymore. Of course, openings=* could be defined as the number of openings to be passed through, but it would be vulnerable for misinterpretation, and in case of special or improvised designs, as they often exist, this specification is probably not always clear.
  2. concerns "single" and "squeeze": If we just specify "turns"/"openings" instead of the type, these two types would automatically be combined (since they both have only one opening or are passed without a turn). However, it seems useful to me to distinguish "squeeze", since this type has different implications on passability than a barrier with a simple opening. Thus, in the future, one might consider specifying passage widths at different heights for "squeeze" (at ground level and about the height of a bicycle handlebar? I could make that part of this proposal). So here we see that the exact design is an interesting information, which in my opinion should not simply be replaced by "openings" or "turns".
So I still think it's better to keep the types suggested in the proposal – maybe just using "cycle_barrier" instead of cycle_barrier:type=* if it's free now after using "*installation". What do you think? (One could still add openings=* as additional information, of course, but I see little advantage right now).
cycle_barrier:type=angular --> orientation=diagonal + direction: Would you suggest to understand such a diagonal barrier as (using the previous categorization) type "double" with additional information about the angle (orientation and direction)? Or type "single", since it can be passed without a turn? Would it have one or two "openings"? I think to define this type of barrier via the "orientation" key would lead to misinterpretations, because the categorization should – as described above – be based on the effects on the passability and such an angled barrier can usually be passed without "sharp" turns. Regardless of whether "openings", "turns" or "single"/"double" are used: A diagonal barrier would always be a different category than a non-diagonal one. "direction" is nevertheless a good addition. One could add a comment like "Consider using direction=* to indicate the angle in (one of the two) travel directions at which the barrier is passed" to the description of this angled type. --Supaplex030 (talk) 07:54, 15 July 2021 (UTC)
Greetings over a detailed reply.
  1. If you aren't sure, I would want to leave installation=* out to avoid the unnecessary cycle_barrier:installation=* namespacing. Keep using cycle_barrier=* for now. This is not a critical part of this proposal.
  2. I missed Talk:Tag:barrier=cycle_barrier#Specific_width_for_bicycle_barriers! Good reminder.
  3. Yeah, I need to admit I didn't consider openings=* very carefully... Indeed, I only focused on the number of openings that has to be passed through. This is not as good as turns. But then, what about *=single? There's no turn involved. So I'm thinking how to handle this better together with the angular geometry.
How about this, concerning your "would always be a different category" comment:
---- Kovposch (talk) 13:06, 17 July 2021 (UTC)
At first I thought that is a very good idea and have just started to modify the proposal accordingly. But then I encountered some problems :)
  1. I am not sure if the naming of orientation=* is intuitively understandable, i.e. that it means the orientation of the driving line, and not that of the object itself (since single/double/triple cycle barriers look similar to the "inexperienced mapper" – they are usually all "somehow oriented perpendicularly" – but the driving line is fundamentally different). But: Is orientation=* necessary at all for single and multiple barriers? Wouldn't a indicator for corners/turn/bends be sufficient, and only for diagonal barriers we add an orientation=diagonal?
  2. Then I tried to apply the corners=* idea. One could replace any type with such a corners value – although I haven't understood yet why you want to avoid a term like bends=* (or turns/curves...), because that's what it would mean? As long as you define that it counts something like "hard, right-angled curves" (with effects on passability) and not "soft" ones like you may drive on diagonal barriers (with little or no effects on passability)?
3 openings, but only 2 turns (or 3 turns, if you count in 90 degrees steps) – originally a special form of type "triple"
Anyway: "single", "diagonal" or "squeeze" would have 0 corners/bends, "double" would have 2 and "triple" would have.... 3? Because the curve in the middle counts as one curve with 180 degrees? Or 4 corners, because 4 times 90 degrees? And whats with the example on the picture: Does is have 2 or 3 corners? If 2, then it's the same as "double", but it's not the same for passability :)
All in all, now I think again that it is too complicated to express this information in a number and that using simple type values would be sufficient for calculation and much more easier to map (and thus less prone to mistakes in mapping/counting)...
--Supaplex030 (talk) 11:02, 18 July 2021 (UTC)
Second thought: Now I think I understood why you preferred corners=* to bends/turns/curves, exactly to avoid this problem with the 90- and 180-degree angles. How about adding corners=* as an addition, but keeping the types, since they each imply a corners default? (single/diagonal/queeze: 0, double: 2, triple: 4). And special cases like that on the picture could be described more exactly (corners=3). But for "everyday" mapping the types would be sufficient.
But maybe I haven't understood your basic problem with the types yet ;)
--Supaplex030 (talk) 11:21, 18 July 2021 (UTC)
P.S.: For what a simple type description can be useful, see also below in the discussion on simplification/tagging level of details: It's important to have a possibility to capture this kind of information easily "on the fly" without having to look deeper into this tagging scheme. (But nevertheless, a special extension for "specialists", like corners=*, could be interesting.)
--Supaplex030 (talk) 14:19, 18 July 2021 (UTC)
Where numbers apply, choosing to use words can make typos more likely and difficult to see. In application it may be less straightforward to process and apply. If a table can be prepared for default situations, it's possible to use it directly to enter the numbers too.
If you want to keep it, let's settle here:
---- Kovposch (talk) 10:16, 19 July 2021 (UTC)
If orientation=* is not good, I can think of deflection=*, or deviation=*. Brings more attention to the resulting path. ---- Kovposch (talk) 10:27, 19 July 2021 (UTC)
I have now integrated many suggestions into the proposal, including the ones you mentioned here. However, I think it is very important to have a simple textual expression for the typical designs, so that the proposal remains usable for the "common mapper" (see below – roughly speaking: choose one of five values "on the fly" from a table with typical picture and don't think about numbers. This is also how OSM works in many other cases...).
Since the diagonal/angular/tilted design is "obviously different from the others" and has different implications for passability, I also think it is important to keep a specific "primary type" for them and not to work with special subtags that have to be evaluated/concerned separately. However, in order to describe the geometry or the angle of "angular" barriers better, I have also included deflection=*.
Is angular an obscure, incorrectly/badly translated term? Would tilted be better, or something else? I'm not a native speaker, as I'm sure you can guess from the text.
--Supaplex030 (talk) 22:04, 20 July 2021 (UTC)
Oh, tilt=* is a replacement for *=squeeze, to indicate the vertical angle of pitching (up or down). You can add this as well. I suggested cycle_barrier=diagonal to replace cycle_barrier=angular. ---- Kovposch (talk) 06:56, 21 July 2021 (UTC)

Very nice diagrams you have made. ---- Kovposch (talk) 06:58, 21 July 2021 (UTC)

Resolved: ---- Kovposch (talk) 09:22, 21 July 2021 (UTC)

Level of detail grades

This proposal should keep in mind that the level of detail won't be very welcoming to most mappers. There needs to be a balance between the work a mapper has to put into sourcing information and mapping a feature and its usefulness to data users. One way to facilitate this is to have different levels of detail that can be refined gradually. In some sense we already have that with a plain barrier=cycle_barrier and this new scheme. However, I think within this proposal we should also outline or at least think about the mapping process and how subsets or possible simplified variants could provide similar levels of usefulness without an immediate need for mapping with a tape measure and protractor. If we could find 1-2 tags that actually get mapped and provide the most essential information for users/routers then this would be more successful than having a complicated scheme that would fully define this feature but is almost never used. Please don't read this as critique to the existing values - the proposal and the values are absolutely respectable IMHO - but it is certainly not in anybody's interest to put effort into a scheme that then gets barely used because it is too complicated. To me the type and width seem to be the most important ones. I think with those two one can estimate pretty well if a long (cargo) bike or a trailer *could* be a problem and I think this is more important than defining an exact geometry where one can the calculate for any vehicle model if it would pass: If one plans a route and there is an obstacle the potentially is problematic it's often easier to just take another route even if in reality the bike would (barely) fit. It does not hurt to define more specific values but there should be a migration path and we should not expect that every mapper will use the whole scheme. --Stefanct (talk) 12:56, 18 July 2021 (UTC)

Yes, I'm aware of that and so far I had no idea how to simplify it (except to leave out all subtags and just use access tags like bicycle=* or cargo_bike=* – because the calculation of passability is very complex and depends on all the mentioned attributes). I even assumed that such an extended tagging would rather be used only by mappers who specifically want to make their city cargo-bike-routable or similar.
But I think you're right: the type and maybe the spacing/width:separation already gives a lot of information. If I would highlight in the proposal that this tag or these two tags are recommendable and all others are "nice to have", that might be less discouraging to the "common user". Or what do you think?
And I should mention the access tags: How about "If you can't or don't want to specify the dimensions of the cycle barrier, but it's obviously not passable for common bikes or cargo bikes, you can map this with bicycle=no or cargo_bike=no"?
(I've moved your comment into a new subsection - I hope that was okay?)
--Supaplex030 (talk) 13:24, 18 July 2021 (UTC)
All fine with me. I was just trying to give constructive feedback (and I did not want to give it too much weight by adding it as a new topic :)
JFYI, there is some controversy about access tags on barriers (some think it does not make sense to tag it *on* barriers as it specifies *legal* rights and not indicate passability) but I agree with you and it works very well with routers AFAIK.
I don't own any relevant bikes... It might be a good idea to talk to people that do, to find out what kind of information they deem essential.
--Stefanct (talk) 13:38, 18 July 2021 (UTC)
I have a cargo bike and from this perspective I would say that a single spacing value like spacing/width:separation alone is not telling a lot because the overlap is crucial. However, the overlap is similar in many cases (e.g. you could assume a default like 1.3 meters, see the usage on TagInfo...) or you could limit yourself to overlap=yes/no in the simplest case.
So I see more or less these levels of detail grades:
  1. barrier=cycle_barrier + cycle_barrier:type=*,
  2. width:separation=<estimated numeric value> + overlap=yes/no,
  3. all 3 dimensions in numeric values.
Next tuesday we have another meeting in our local OSM community with the focus on "Verkehrswende"/bicycle infrastructure and I will also ask the others - with whom this proposal has already been discussed - what they think about that. We will also have contact with routing specialists and I can ask for their opinion.
--Supaplex030 (talk) 14:12, 18 July 2021 (UTC)

Formatings

Interesting proposal and nice pictures for schematic illustration (https://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_cycle_barrier_tagging#Types_.2F_designs_of_cycle_barriers). By the way, it would be nice to see also pictures for removable / foldable / fixed.

Two minor formating change ideas:

  • changing the order of "tagging dimensions" and "classification of types" at https://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_cycle_barrier_tagging#Proposal. Starting with the types at the beginning and afterwards followed by the more detailed dimension and size parameter. I think this a also the order (from big to individual) which is done while tagging such an object.:
    • first: * a classification of different types / designs of cycle barriers:
    • second * a tagging for the dimensions of cycle barriers
  • adding all the new tags to the proposal box, currently the only tag barrier=cycle_barrier is there, maybe change it to this:

{{Proposal Page |name = |key = cycle_barrier=*, cycle_barrier:type=*, width:separation=*, width:opening=* and overlap=* |type = {{IconNode}} |definition = Type, design, size and width specifications for cycle barriers – i.e. barriers along a path that slows or prevents access for bicycle users. |taginfo = no }}

I know the proposal template box is currently not optimal designed for multiple tags/keys, but even if the link will not work, adding the new keys in the box it would show a better/faster initial overview about the entire proposal.--MalgiK (talk) 03:22, 19 July 2021 (UTC)

Thanks for your suggestions, which I have included.
When looking more closely at the "installation types", I realised that removable or foldable is often not the appropriate term, but rather something like openable is needed, so I explained this in more detail and added examples.
The format template was also very helpful!
--Supaplex030 (talk) 22:04, 20 July 2021 (UTC)
Welcome, thank you for including it. So the major part of the proposal (explaining types / designs of cycle barrier) could also mention in the proposal box definition description?
Current text: Size and width specifications for cycle barriers – i.e. barriers along a path that slows or prevents access for bicycle users.
Proposed text, something like: Type, design, size and width specifications for cycle barriers – i.e. barriers along a path that slows or prevents access for bicycle users.
I have no comments to the more generic openable instead the more detailed removable / foldable, feel free to use it. --MalgiK (talk) 23:35, 22 July 2021 (UTC)
Thanks, yes of course, that shouldn't be missed there.--Supaplex030 (talk) 10:59, 23 July 2021 (UTC)

what is a "cycle" barrier?

Another problem with the barrier=cycle_barrier tag is that it is not clear if it is a functional definition or a barrier-shape definition. The same structure can be a barrier on a footway against against bicycles or is it a barrier on a cycleway to slow down bicycles?

If I look at this barrier

Bhf Engelskirchen Umlaufgitter.JPG

it certainly is a barrier on a footway to keep out bicycles (or at least force the cyclists to dismount) and not a barrier on a cycleway to slow down cyclists

That was the reason why I use barrier=cycle_barrier barrier:type=chicane (and not cycle_barrier=chicane)for chicane-shaped barriers

--voschix (talk) 14:04, 20 July 2021 (UTC)

Yes, you address an interesting point. However, I think the basic problem is simply a poorly chosen term, rather than the definition itself (or do you know of an example where you are not sure if it is this kind of object or something else?). Another common term for this kind of object is "pedestrian chicane", but this again references a different user group, namely pedestrians. I think we have to live with the fact that we have this term with a "bicycle" reference in the name, but implying both meanings and both functional modes: slowing down bicyclists or preventing bicyclists from using a path. Because of course we also map "pedestrian chicanes", where no bicycles are allowed for miles around, with "cycle barrier" - don't we...?
--Supaplex030 (talk) 22:04, 20 July 2021 (UTC)

Partially removable barriers

While trying to map a cycle_barrier=double I noticed that only one of the two barriers was actually removable. Which value is appropriate for cycle_barrier:installation in this case? --Nw520 (talk) 14:51, 22 July 2021 (UTC)

Mhm, you should use fixed, because if you can't open/remove one of them, then presumably the entire barrier is not passable for larger vehicles (emergency services or similar)? --Supaplex030 (talk) 16:25, 22 July 2021 (UTC)
Or – if opening one of the two grids is sufficient to pass the barrier – openable/removable + maxwidth:physical:conditional=xyz @ motor_vehicle?--Supaplex030 (talk) 17:58, 22 July 2021 (UTC)
Thanks Supaplex030, in this case I'll stick to fixed since even if one barrier were to be removed the width would still be insufficient for PSV-vehicles. --Nw520 (talk) 12:20, 23 July 2021 (UTC)
Resolved: --Nw520 (talk) 12:20, 23 July 2021 (UTC)

Constructive critique on cycle_barrier:installation=*

I come here from https://github.com/streetcomplete/StreetComplete/issues/3151 , unfortunately a little bit late to the party...

Congratulations on this well-written proposal! I have a small, well-meaning critique on cycle_barrier:installation=*.

(For whom) is the distinction between cycle_barrier:installation=removable/openable/foldable important? Isn't the important part the information per se whether a barrier can be rendered ineffective for emergency services, etc? Should this maybe get tagged using two tags? One tag containing the information whether the barrier can be rendered ineffective and a second tag describing the exact mechanism (for those mappers/data consumers that are indeed interested in this information)? This would also facilitate cases where one looks at a picture of something like https://wiki.openstreetmap.org/wiki/File:Cycle_barrier_openable1.jpg and may recognize that the barrier is unlockable in some way but may be unable to determine the exact mechanism for doing so. Alternatively, we could define something like cycle_barrier:installation=unlockable as a general tagging, and have cycle_barrier:installation=removable/openable/foldable as specializations of the above. -- Skorbut (talk) 20:24, 11 August 2021 (UTC)

This is an interesting question of principle - but in OSM we often only use one key to make such classifications and I wouldn't like to differ from this practice... A direct comparison would be the very widespread bollard=* (with almost identical possible values). Those who use such keys for applications/routing algorithms etc. have to define a treatment for the most common values: e.g. bollard=removable, bollard=rising, bollard=foldable and bollard=flexible mean passing may be possible, and for all other values one can assume that passing is not possible. In over 99% of cases, this would be reliable.
--Supaplex030 (talk) 20:54, 11 August 2021 (UTC)
"unlockable" is not the same as *=openable. The former describe it is secured, which has locked=* already. The latter is a mechanism of moving (like a gate) together with *=foldable (collapses) and *=removable (whole thing taken out). It is possible to be locked=no + installation=removable, meaning anyone can freely move it without needing a key. ---- Kovposch (talk) 11:19, 12 August 2021 (UTC)

single vs squeeze

What is the defining difference between squeeze and single? @Supaplex030: Mateusz Konieczny (talk) 20:39, 15 October 2021 (UTC)

I'd say the tilt, which makes squeeze wider at the bottom than the top. Whereas single may, depending on height, still let bikes through, albeit carefully, squeeze seems to be designed to be impassable. --Ygramul (talk) 20:50, 15 October 2021 (UTC)
Exactly. cycle_barrier=squeeze are usually narrower and often a major obstacle for cyclists, while cycle_barrier=single, on the contrary, are usually only a minor obstacle. In individual cases, this can of course be different, which can be expressed with the geometric attributes. In general, however, routers could identify a relevant difference for passability just from this single category. --Supaplex030 (talk) 19:26, 17 October 2021 (UTC)
@Supaplex030: - so maybe tilted would be better? squeeze seems problematic as we will end with narrow single being tagged as squeeze. BTW I made some edits, see https://wiki.openstreetmap.org/w/index.php?title=Key%3Acycle_barrier&type=revision&diff=2209729&oldid=2197221 Mateusz Konieczny (talk) 20:14, 17 October 2021 (UTC)
Good point - I used "squeeze" because there were already some uses of that term before. At the moment, according to TagInfo, "squeeze" exists 48 times - is it worth changing? --Supaplex030 (talk) 20:47, 17 October 2021 (UTC)
@Supaplex030: - yes, 48 uses is basically nothing. And once https://github.com/streetcomplete/StreetComplete/issues/3361 will be deployed the tagging will likely become widely used Mateusz Konieczny (talk) 14:28, 18 October 2021 (UTC)
I would deprecate squeeze and introduce tilted "narrow passage, with tilted barrier narrowing toward top". Maybe as a new proposal? Mateusz Konieczny (talk) 14:32, 18 October 2021 (UTC)
Ok, but I wouldn't start a new proposal for that. Maybe just start a discussion on the Tagging Mailing List and if there are no vetos, just document the change on the Wiki pages? We also could check if there are some newer uses of "squeeze" (mapped since this proposal was approved) and inform the mappers about the change/change the usage there... --Supaplex030 (talk) 18:12, 18 October 2021 (UTC)
I posted to tagging mailing list Mateusz Konieczny (talk) 19:22, 18 October 2021 (UTC)
Disclaimer: while I encountered this tagging situation during development of StreetComplete funded by a grant, I am not paid to make tagging discussions. I would receive the same funding if I would implement it with originally approved tag name. Mateusz Konieczny (talk) 19:22, 18 October 2021 (UTC)

Offset single

@Supaplex030: How https://commons.wikimedia.org/wiki/File:Pozdawilk_2017(Pasewalk)_(4).jpg https://commons.wikimedia.org/wiki/File:Radweg.JPG should be marked? It is neither really diagonal nor single Mateusz Konieczny (talk) 19:06, 4 November 2021 (UTC)

Oh wait, that is double. Sorry. Mateusz Konieczny (talk) 19:07, 4 November 2021 (UTC)
Reminds me to find a better example image for double :) --Supaplex030 (talk) 20:21, 4 November 2021 (UTC)

StreetComplete quest

If anyone is interested, then https://github.com/streetcomplete/StreetComplete/pull/3487#issue-1045245640 implementing adding cycle_barrier=* was implemented and now is ready for review Mateusz Konieczny (talk) 22:03, 4 November 2021 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Advanced_cycle_barrier_tagging&oldid=2511661"