Talk:Key:obstacle

From OpenStreetMap Wiki
Jump to navigation Jump to search

@Grin

Please take a break and rethink your edits. This page should document actual usage only. Don't copy the proposal contents to this page, because the proposed tags and descriptions may change, and some of the proposed tags are not really in use. Take into account that the whole proposal may get rejected by voting. By the way: Your table looks ugly, because the column widths don't relate to the content lengths. --Fkv (talk) 08:57, 17 June 2015 (UTC)

@Fkv: I understand what you suggest, however, OSM wiki documents tag usage and advices and not just a mirror of taginfo statistics. I suggest you to correlate forming your opinion with the date of a proposal: do you really suggest that there may be a voting now on a 2012 proposal? Or ever? Go around and see proposals and the ratio of voted proposals versus proposals lingering and in use. You are guessing wrong: I do not worry about its voting or rejection, I do not expect it to happen soon (unless someone want to play fun on others, but as you may be well aware a rejected proposal would not mean the revocation of the tagging, so in practice it would not change anything at all).
It's up to the proponent to decide when to start voting. If he never starts voting, his tags and definitions will never be approved. It is true that many proposals were never voted on. Most of them were just silently abandoned because they flawed or unnecessary, or someone came up with a better solution. Some proposals were never voted on because the proponent forgot about it, or because he attempted to bypass the voting procedure. In that case, the actual usage often differs from proposed usage. obstacle=* is an excellent example. The top values (bridge, lock, line) are not part of the proposal, and most of the proposed tags did not get in use. --Fkv (talk) 16:31, 17 June 2015 (UTC)
You have described the proposal structure correctly. At the end you unfortunately mix up the proposal with the usage. --grin 17:47, 17 June 2015 (UTC)
It's you who mixes these up. You documented subtags that are proposed but not in use. These include obstacle=heap (only 10 uses, that's even less than barrier=heap which has 21 uses), obstacle=hole (10 uses, man_made=hole: 42, hazard=hole: 51, accident=hole: 50, man_made=pit: 43), obstacle:horse=* (0 uses), obstacle:hgv=* (0 uses), etc. --Fkv (talk) 21:40, 17 June 2015 (UTC)
Documenting usage for "in use" tagging is important because without it there will be an uncontrollable mess. As you see all my values expansion items were actually in use, I only expanded the table of some random guy [ :-) ] creating the table itself doing a pointless copy of taginfo. Additionally I expanded the page with proposed use to prevent a mess forming, as in my experience people actually check wiki about usage, be that voted or not, and we here around do use this tagging scheme which have no alternatives. (You may debate it; Hungarian community have discussed it for quite a long time and the result is partly the formed opinion.)
The hungarian community is not the right place to discuss worldwide tags.
Technically any way is good to discuss anything about OSM, be that tagging or else. OSM is an open-structure database, and communities are often disjunct. --grin 17:47, 17 June 2015 (UTC)
You may talk about tags wherever you like, but when it comes to a decision making process, you cannot bypass the majority. Other communties have made the same mistake, e.g. official_status=* (Russians) vs. name_prefix (Germans) vs. designation (Brits), which are all used for the same thing because they did not discuss that internationally. --Fkv (talk) 21:40, 17 June 2015 (UTC)
You are absolutely right about decision process, and I do not intend to bypass, or even engage in it. I go forward and document the use and advised use instead of waiting for a 3 year old process to finish in the not-foreseeable future. I do not block the Proposal, it can smoothly go wherever it want to go, and if or when it gets voted the wiki page will surely reflect that. Until then we are mapping, instead of holding the breath and being unable to map what needs to be mapped. And we do it in sync instead of ad-hoc tagging. Call it forward documentation and frown upon it, still it works much better than using completely undocumented tagging schemas. --grin 18:45, 18 June 2015 (UTC)
You claim that you do not intend to bypass the process, and that you just document the use. This is wrong. See the examples in the first of my comments dated 21:40, 17 June 2015. None of the subtags is in use, they are all just copied from the proposal. --Fkv (talk) 19:28, 20 June 2015 (UTC)
These discussions need to take place in the (international) Tagging mailing list and/or in the Wiki (English language pages).
Yes. As soon as I would like to make a proposal I will probably go there and run the process. I may not, since last few times Ive met with zero interest and feedback, and the process went nowhere. --grin 17:47, 17 June 2015 (UTC)
BTDT. Lack of feedback is better than negative feedback. When people are satisfied, they don't argue. Wait a few months, then start voting. The obstacle=* proposal, however, got plenty of feedback. It proves more valuable than backdoor discussions within a local community. --Fkv (talk) 21:40, 17 June 2015 (UTC)
It is not my proposal. I have read every discussion back then when I have started local discussions and didn't seen any progress for years. I will not stir the water, we can use it regardless. I cannot stop anyone from pushing it forward though. --grin 18:45, 18 June 2015 (UTC)
Your additions to the table did not add any information. You just replaced links with the linked contents (e.g. fallen_tree: "There is a big..."), and made up some definitions on your own. This is not right. When you don't know what other mappers mean by a tag, leave the definition empty. Note that KonfrareAlbert did add information (concerning OpenSeaMap) to the table, whereas you did not.
Unfortunately you mix up the proposal with the key description page. I have not changed the proposal page, or if I did, apologies, it was not intentional. The key description page have technically "nothing" to do about the proposal, I was documenting actual use. I dare say I do know what other mappers mean by the tag and I am open to these open mappers to accept their inputs if they would believe their intended use differs from my documentation, may it ever happen (most probably not). I would kindly ask you not to be a speaker for an imaginary faceless mass, let them speak for themselves. --grin 17:47, 17 June 2015 (UTC)
I did not accuse you that you had changed the proposal page. What you did was adding definitions to the feature page which are either just unnecessary copies from the proposal, or made up by yourself. In case of the proposed values, I don't speak for a "faceless mass", as I am one of the faces. A good part of the obstacle=vegetation tags in OSM were set by me. Concerning the OpenSeaMap values, there seems to be a "faceless mass" indeed. I cannot speak for them, but you can't either. It's up to those who use the tags to tell what they mean. Given that they did not care about the wiki in the past, they will feel even less desire to fiddle with a long and complicated page. So if you want to add reasonable descriptions, find out who the OpenSeaMap guys are, and contact them. Don't make up your own definitions. --Fkv (talk) 21:40, 17 June 2015 (UTC)
I have read the proposal and used it as a base. I did not "change" the proposal, I have created the whole page, using several sources, including the proposal, I never have stated otherwise.
Moreover yes, you're one of the faces, with your personal opinion which I accept. I don't intend to act on it though since my opinion is just as good as yours. :-) I will reach out to OpenSeaMap editors as you have suggested. --grin 18:45, 18 June 2015 (UTC)
Speaking of "in use" tagging, none of the subtags (obstacle:horse etc.) is really in use. You should omit the whole section. Generally, the feature page should be kept concise as long as fundamental issues of the main tags (such as the difference between barrier=* and obstacle=* on nodes) are still being discussed in the proposal. By overdocumenting doubtful and unused tags you are brewing up the mess you want to avoid. --Fkv (talk) 16:31, 17 June 2015 (UTC)
If you would like to open a discussion, just do that. I see no fundamental issue about obstacle and barrier as far as I know it's already documented: obstacle means hindering movement and barrier means denying it. Obstacle is a property of way environment and barrier is an object itself. --grin 17:47, 17 June 2015 (UTC)
I don't want to open a discussion. The issue was already raised, and it is (or at least was) discussed in the talk page of the proposal. This is where the discussion should proceed. Duplicating the discussion is a very bad thing. Issues would be raised multiple times, messages would be overlooked, and people would get lost in the discussions. --Fkv (talk) 21:40, 17 June 2015 (UTC)
Agreed. --grin 18:45, 18 June 2015 (UTC)
About your comment of the table: it was not created by my but by some random guy: if it's ugly its ugly because of him. I only fixed it up. If you mean the typo in the table (calling the whole table "ugly", which is not quite a nice way to voice your opinion) thank you, I have fixed it. You could have done it without calling it "ugly" in my face, by the way.
It was you who started the nice/ugly table thing with your revision comment at 10:17, 2015 June 17. I would not even have looked at your changes if you had not claimed my table to be wrong. Concerning your version of the table, I already hinted you to the column width. You overlooked that, because you immediately raised the disussion to a personal level. Of course I could have corrected it on my own, but be aware that when it's up to me to correct the page, there will be little left of your changes. --Fkv (talk) 16:31, 17 June 2015 (UTC)
Oh, my. Sorry, you have misinterpreted my comment then. It was not about the looks of the table, it was about its data content, which was severely lacking already documented information. You may be aware that key wiki pages are referenced from several places automagically, including taginfo, so these pages should be self-contained and ready for use by the mappers. You have created a placeholder lacking information and illustration. I see that your reason was based on your belief that I wanted to document the proposal, but I was not. My comment was not intended as an offese, my apologies if it looked like one. --grin 17:47, 17 June 2015 (UTC)
The table did not lack any documented information. It contained all the relevant links. Every wiki user is capable of clicking a link. A link is better than a copy, because the link avoids inconsistencies. When you copy a definition, and either the original or the copy changes, we end up with contradicting definitions.
Taginfo only makes use of the parameters to the KeyDescription and ValueDescription templates. Any other content, such as the table with value definitions, is ignored. --Fkv (talk) 21:40, 17 June 2015 (UTC)
Taginfo links to the wikipage if the page indeed exists. --grin 18:45, 18 June 2015 (UTC)
So how does that relate to the table contents? Your recent changes did not improve on the existence of the page. --Fkv (talk) 19:28, 20 June 2015 (UTC)
All in all: in case you've worried that people will believe it is a voted feature, I have inserted a boilerplate for you. However other communities actually use and rely on the page (see overpass turbo or taginfo for usage details) and I do not create pages here for fun but to direct people to use the tag properly. I appreciate your care but try to form your opinion a little less offensive way. And of course all your cooperative or forward-looking comments are welcome. --grin 10:48, 17 June 2015 (UTC)
The links that you deleted did direct people to the proposed definitions, and these are the only definitions we have. Again, don't make up definitions on your own. The boilerplate is an insufficient substitute, because it does not make clear which of the definitions come from the proposal, and which are made up by you. Apart from that, the boiler plate should contain a link to the proposal. The one remaining link essentially became invisible due to the bunch of additions. --Fkv (talk) 16:31, 17 June 2015 (UTC)
The link to the proposal on which the real-world usage was based on was still there at the top of the tagging table, but I have inserted into the ambox above. Let me repeat: this is not the proposal page, this is the usage documentation, and it may be related to the proposal but not inherited from it. I accept that you would like to have the proposal voted on, I cannot help it (and, honestly, based on my experience with tagging-l I don't intend to), but I intend to keep documenting usage and adviced usage. I believe I have inserted everything at the top not to suggest that it has been a voted-on feature, I kindly ask you to accept that and move on. If you meet anyone having a clashing real-world usage, direct him/her here or to me, and I'll see how it can be resolved. Please refrain from removing information from the page, if possible. Thank you. --grin 17:47, 17 June 2015 (UTC)
I don't mind whether the proposal is voted on. I do mind if you swindle proposed values that are not in use into the feature page, trying to bypass the proposal process. You are obviously keen to get the proposal approved, but lost hope that ConfrareAlbert proceeds with it. Why don't you contact him and urge him? I am sure that he will either proceed or explain his reasons for hesitating. --Fkv (talk) 21:40, 17 June 2015 (UTC)
You should be aware that "making up" and "swindle" are very impolite (borderline of offending) way of phrasing your opinion. I would very much prefer if you would use "created" and "invented" or "proposed" instead. I am not keen to have the proposal approved, I am instead keen to have the tag use and possible use well documented to prevent people to use it differently and making it impossible to render and use properly. I (and all in the cases you may read well "we" instead) use the tagging scheme for hiking routes but you may already have seen that in overpass-turbo and it is my interest to have it used consistently. I have researched the alternatives, I have checked the proposals, and I have decided, myself, what I intend to use, and after a discussion the community (at least that part which was taking part) was agreed on the use. I will not urge @KonfrareAlbert:, he's a grownup, he can decide what he wants to do, but I will contact him and notify about this discussion.
Let us finish here, I suggest, we both said everything important here. If KonfrareAlbert want to start a voting, be it. If not, we use this scheme anyway. If he updates the Proposal based on my page (which was incorporating some ideas from the discussions, btw) it's great. If not, it's okay. If people update the page by their usage, great. If not, oh well. Have a nice day! --grin 18:45, 18 June 2015 (UTC)
It's not the right time to stop here. The page still documents tons of tags that are not in use. See the examples far above. --Fkv (talk) 19:28, 20 June 2015 (UTC)

Recommend deprecation - objective obstacle values duplicate barrier=*

The key barrier=* can be used for all of the objective obstacles mentioned. Most are already documented, e.g.: barrier=log, barrier=block, barrier=debris, barrier=ditch. I would recommend using that approved and much more common key for these features. The other values here are subjective problems with the road which can better be tagged in specific way with surface=* (e.g. grass) or smoothness=* or tracktype=*, if they are mapped at all. --Jeisenbe (talk) 02:44, 11 January 2020 (UTC)

It should be deprecated (in favour of barrier=* for all obstacles ACROSS the way. But it is a very useful key for all obstacles ALONG the way. I use obstacle=vegetation a lot and sometimes obstacle=fallen_trees (notice the plural, whereas I use barrier=log for single trees). Unfortunately, the current usage is a mess, because there were the openseemap values that apparently were imported without any discussion, and then there was a bad proposal that disregarded that usage and failed to define a clear distinction to barrier=*, and then somebody created the feature page incorporating some of the proposed values that were neither in use nor useful.
No, obstacle=vegetation (think of Rubus fruticosus and Urtica sp.) and obstacle=fallen_trees cannot be replaced by surface=grass.
--Fkv (talk) 04:19, 11 January 2020 (UTC)
You can also use barrier=* with new values. And barrier=vegetation has already been used 5 times, plus there are over 400 uses of barrier=dry_bush. https://taginfo.openstreetmap.org/keys/barrier#values.
No, I can't use barrier=* on a way for that purpose, because it would mean that the way is a barrier (same as a barrier=hedge). --Fkv (talk) 05:48, 11 January 2020 (UTC)
If there are multiple fallen logs, it would be best to map each one individually. --Jeisenbe (talk) 05:25, 11 January 2020 (UTC)
You can also map a forest by mapping each tree individually. It's a matter of effort as well as of micromapping vs. generalization. --Fkv (talk) 05:48, 11 January 2020 (UTC)

barrier=* is a specific object, a thing, often part of the way. The obstacle=* is never part of the way, it is the environment effecting the usability of the way. Think of summer vegetation, falling rocks and similar transient environmental attributes: they are the environment changing the usability of the way, and they are effective on a large length of the way, often the whole of it. It is also quite connected to unmaintained paths and tracks, which may be intermittently or seasonally obstructed. --grin 14:29, 20 May 2021 (UTC)

Seasonal

Rather than use seasonal:obstacle=yes why not use Conditional restrictions to give any seasonal information? Warin61 (talk) 02:32, 15 June 2020 (UTC)

Deprecation needed (obstacle=bridge)

At the moment about 25% of the objects that use this key are obstacle=bridge. Right is man_made=bridge.

Most of the objects that use obstacle=* can be mapped differently and should be mapped as it is documented here in the Wiki.

This key and this page is harmfull for OSM as it suggest to use rubbish tags instead of pointing the people into the right direction.

--EinKonstanzer (talk) 20:49, 12 September 2020 (UTC)

Can you explain a bit more detailed why you believe the values are rubbish? --Dieterdreist (talk) 22:52, 16 September 2020 (UTC)
The page expressively state that obstacle=bridge is obsolete use, and the wiki (and the current page) does not have anything to do with that usage.
Also you should notice that apart from this obstacle=vegetation is the most often used combination.
Also you neglected to mention what "different" mapping you had on your mind, since obstacle=* tells the environment's effect on the usability of the road.
I do not think your opinion has merit. --grin 14:37, 20 May 2021 (UTC)
Note that obstacle=bridge is used on the way/node below of the bridge not for the bridge itsself! --chris66 (talk) 13:53, 13 October 2022 (UTC)
@Chris66: please don't just remove things from the wiki page! If you believe the key is not obsolete please describe it with enough detail to be unambiguous. Thanks! --grin 09:35, 14 October 2022 (UTC)