Barrier=gate - What is the available opening about streetcomplete HOT 11 OPEN

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.

from streetcomplete.

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.

from streetcomplete.

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!)

from streetcomplete.

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!

from streetcomplete.

barrier=wicket_gate barrier=sliding_gate - these two are effectively barrier=gate synonyms (or more specifically, these are typically tagged as barrier=gate)

from streetcomplete.

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)

from streetcomplete.

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?

from streetcomplete.

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;

• barrier=entrance
• barrier=bollard
• barrier=block
• barrier=sliding_gate
• barrier=swing_gate
• barrier=wicket_gate
• barrier=cycle_barrier & cycle_barrier=single
• barrier=cycle_barrier & cycle_barrier=diagonal

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?

from streetcomplete.

Cool, go ahead!

from streetcomplete.

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.

from streetcomplete.

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.

from streetcomplete.