Closed Nick-Tallguy closed 2 months ago
I'm currently researching Kotlin and Android with a view to attempting to create a suitable pull request, should this quest request be considered suitable.
I'm not ready yet though!
Would it be better to close this issue at present, with a view to opening a new issue, or reopening this one, when I am better prepared?
Issues are not only for things people are willing implement themself, so it can stay.
Though for implementing things: it is best to wait for idea to be reviewed by @westnordost (or me, which in many cases is also working well - though @westnordost can override me). Once this happens (and can be recognised by @westnordost commenting or labelling issue) it will mean that idea itself was accepted and was not rejected. So it is best to wait with coding until this happens.
I will leave this one as measurement thing is not running on my phone at all.
I'm currently researching Kotlin and Android with a view to attempting to create a suitable pull request
That's great to hear, new contributors are always welcome! Did you already see CONTRIBUTING_A_NEW_QUEST.md ? It contains very useful information for those embarking on such journey! One might even contribute simpler quests without learning much (or even any!) Kotlin, just by copy/pasting existing quests and modifying them by using those instructions.
Would it be better to close this issue at present, with a view to opening a new issue, or reopening this one, when I am better prepared?
I'd leave the issue open, so people can read it and submit feedback. It often takes at least a few days / a week for that to happen (e.g. some people have more time on weekends etc).
Issues are generally closed only if they are implemented, or if they are deemed not suitable (in which case you might also get suggestions about alternatives; e.g. there exist SCEE [StreetComplete "Expert Edition" fork] which is accepting many quest that are not suitable for regular StreetComplete, so your learning process won't be wasted!)
There is also barrier=entrance
to which this quest should also apply. Maybe more, e.g. also turnstile
? Turnstile in particular seems to be a good example that the question must be phrased carefully, as just asking for the "width" would be ambiguous in this case:
Barriers are that explicitly tagged as access=private
, no
and similar should not be asked about.
Also, one issue I see with this suggestion is that there are loads of gates mapped, and many are not actually public. The gates however are often not marked as access=private
or similar because people often only map the access
tag on streets, footways etc., but not on nodes such as entrances or gates. This can be solved by only asking for gates that are vertices of footways, paths etc. (AddRailwayCrossingBarrier
does something similar.)
But in any case, I think this is a useful addition for a quest!
I had wondered about another quest to establish the access of the barrier, and only those not tagged as private would go on to the question about width, but your answer is much better.
I find the subject of barriers quite complex, and decided to try to keep it simple and deal with one item for the quest request. However, very similar, and perhaps could be included within this, could be;
I haven't included cycle_barrier=double or cycle barrier=triple, because I think they will need dealing with individually with diagrams and wording to individually suit. cycle_barrier=tilted is difficult because you need to define at what height(s) to take the width measurement.
or perhaps keep it simple, deal with barrier=gate and then deal with each of the others, one at a time, with diagrams and text individual to the particular barrier?
barrier=wicket_gate
barrier=sliding_gate
- these two are effectively barrier=gate
synonyms (or more specifically, these are typically tagged as barrier=gate
)
I've read the guide to contributing a quest and I would like to work on this quest. Let me know if this would cause problems, thanks.
Cool, go ahead!
I've started working on this, but am unsure if I should, at this stage, just deal with barrier=gate,, and add subsequent quests to deal with bollards, blocks, cycle_barriers. Just dealing with barrier=gate means one icon, and one set of strings etc, which may be the sensible approach at the moment.
I have been trying to combine bollards, blocks, and some cycle_barriers, but think that the filters, strings and icons may be very confusing.
As the type of element is already written below the question, the question should be worded generically, like "What's the maximum width here" or something. Maybe could even use the same string as for the street-maxwidth quest.
The icon can be the same for gates, etc, e.g. a wall with an entrance or a gate plus a ruler.
Regarding other elements, let's go with barrier=gate
, barrier=entrance
and similar things first. I didn't understand how this quest could possibly work for barrier=bollard
, block
etc.
The icon could also be the wheelchair icon with a ruler, hinting at for whom this information might be useful and thus which width to use if there are different widths depending on the height. (I.e. take the minimum width, don't assume that people can wiggle through)
"What is the available opening through this gateway" To be applied to barrier=gate tag to be added maxwidth:physical=
Checklist
Checklist for quest suggestions (see guidelines):
[x] 🚧 To be added tag is established and has a useful purpose barrier=gate is common with over 5,000,000 instances https://taginfo.openstreetmap.org/tags/barrier=gate#overview
maxwidth:physical= has just over 2,800 instances https://taginfo.openstreetmap.org/keys/maxwidth:physical#overview. It's possible that mappers have used other tags such as maxwidth= ( the legal restriction on size ) with 50,000 uses https://taginfo.openstreetmap.org/keys/maxwidth#overview or width= with over 3,000,000 uses - not sure how many of these would refer to gates. But even with these figures there are many gates / gateways with no tag showing their available opening. Without an indication of the gap available it's difficult to know if a particular item will fit through - this could be too narrow for a pram / pushchair to fit through or so wide that two buses can pass through together.
Adding a measurement of the available opening makes it possible to start to create navigation for such vehicles as electric wheelchairs, tricycles, hand powered cycles, larger electric vehicles for disabled users such as the Tramper mobility scooter https://www.tramper.co.uk/products/tramper
[x] 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one) Once the tag maxwidth:physical= is applied to the barrier=gate node or way, this particular quest is complete and should not show for other surveyors.
[x] 🐿️ Easily answerable by any pedestrian from the outside but a survey is necessary
A similar screen to that which appears for users solving the road width quest would be suitable - I've tested the StreetMeasure app using a tape measure, and with care measurements of 0.5 metres can be obtained quite accurately.
[x] 💤 Not an overwhelming percentage of quests have the same answer (No spam)
There's a lot of variations in gates!
[x] 🕓 Applies to a reasonable number of map data (Worth the effort) Worldwide potential for over 5,000,000 items.
Notes
There appear to be many nodes and ways which have been tagged as 'barrier=gate', but there is actually more than one gate present - double gates are common across driveways, agricultural premises, and many other instances. To avoid confusion I suggest that the question refers to the gateway rather than the gate. The term 'opening' is easier for a non-mapper to understand, and indeed the maxwidth, width and maxwidth:physical descriptions seem to confuse many experienced mappers.
It may be that the gate already has a width= or maxwidth= tag - I leave it up to discussion as to how the quest should be filtered. Personally I'm happy to believe that a mapper who tagged width or maxwidth= means the width of the opening, and that is acceptable to me.
Within the er...... section there should be an option to show that the gate is no longer present.