Feature Proposal - Voting - highway=scramble

Matija_Nalis · December 19, 2022, 1:59am

Here is my analysis of 35 rejections and 5 abstains (note that this adds to more than 40, because while few have not given a reason, more than few had multiple concerns). Also, take it with grain of salt, as it is impossible to put myriad of opinions in just a few generic categories.

It should provide some rough outline, though:

21 feel than currently existing tags are enough (e.g. highway=path+sac_scale=* and others)
11 feel that new supplementary tag (e.g. scramble=yes) would be OK-ish, but are against new highway=* value
11 would be OK with new highway=value, but think that it should be something more generic and not so narrowly scoped (e.g. highway=demanding_path + demanding_path=scramble)
11 feel that there are Verifiability issues (i.e. too subject and/or not clearly defined, corner cases, etc.)
14 (and more, as sac_scale as well as scramble=yes might count here too) seem to miss the point why is was proposed as separate highway=* value (because it is according to current experience very near impossible to get renderers/routers to correctly parse secondary tags too).

So, the majority feels that sac_scale=* and other existing tags are good enough.
If you still disagree with that @Hungerburg, I would suggest:

take more time to prepare it. Explain clearly but in short why separate highway=* value is wanted, and exactly why secondary tags like sac_scale=* and scramble=yes don’t cut it (x out of y renderers/routers mislead unsuspecting people on such technical trails, c.f. via_ferrata how it helped). It should fit in one paragraph of about 5 (not too long) sentences. Also provide link to a post with more detailed evaluations if needed. That should take care of point (5), as well as much of (1) and (2).
go with something more generic like highway=demanding_path + demanding_path=scramble. Give 3-4 more popular options for other demanding_path=* values besides scramble as examples to demonstrate why it is preferred to a secondary key, but be clear you’re not trying to get approval for them in that proposal at that time. That should take care of whole point (3) as well as majority (if not all) of point (2), as well as some of the point (5) too.
also, be more clear about what is and what isn’t scramble. Give more then few examples, with explanations how they differ from others, and pictures, and all tags that might be used (or explanations why they wouldn’t/shouldn’t be used. e.g. sac_scale, trail_visibility, incline, surface, smoothness …). Especially give extra examples about corner cases. It does not need to be definitions of scramble that everybody would think of, but it needs to be as verifiable as possible. Take smoothness=* as inspiration. E.g. smoothness=intermediate would mean a million different things, but when you have table with example pictures, what vehicles it is usable for, how big each crack (or how deep a rut) may be in cm, how much average car may be slowed on such road etc it becomes more verifiable. Still somewhat subjective, but much less so. If you needs several types of scramble, define then. I think table like used in smoothness=* is good and readable way to go. That should take care of point (4).
use this thread (or a new linked one) to have other people help with suggest better wordings, clearer explanations, and good examples before doing the proposal (i.e. only do a proposal when it looks to be final production version). You want to have something which is short and easily readable (not confusing, vague or open to interpretation in any part) followed by table of several examples showing what would be demanding_path=scramble (and how/why it would be tagged), and several examples showing what would not be (again with explanation why; and how it should be tagged instead).

I do agree that is a significant amount of work, but hopefully others would help (especially if asked. I would), and to make significant and good and long lasting changes, some extra effort will always be required.