amenity=clock can have several good values for StreetComplete users:
As these are quite a lot values, I think, it would make sense to not only split it into two quests or so, but rather simplify the ones we can group together. I mean we can just ask for the "type of the clock" and then provide typical clocks using an image selection as usual.
The 3 wiki examples are already good. They are:
Additionally, I'd say we need:
Maybe we can also group the clocks to analog and digital versions, as the wall-mounted and maybe also the billboard clocks can both be digital or analog.
A further quest could ask for all digital clocks whether they have a thermometer and/or date display (I doubt analog clocks can display the date).
And yet another quest could ask about the visibility.
So all in all we could cover all these tags above with 3 quests, where only 2 quests are shown for analog clocks.
The clock tag is used in Wikidata, OsmAnd, Josm, Vespucci, iD and others…
I doubt analog clocks can display the date
Many analog wrist watches can.
Eh, yeah but these are not mapped on OSM. 😜
Nevertheless I understand your thought, but have you ever seen such a clock in the wild?
Public clocks with a date seems to be extremly rare (i only found one on the web).
Even with digital clocks a temperature is much more common.
Additionally date is not defined to be yes/no but a time in history combined with other tags. Only clocks use yes/no
Not sure if this is clear yet, perhaps I should write it down somewhere if it isn't. Generally:
There are countless things that _could_ be collected, such as the color of the cycleway, the brightness of street lamps, etc. etc.. There is no shortage of that, and I guess there will always be some people who think up a tagging schema for that and put it in the wiki. That doesn't mean it makes sense to collect it.
Yes, of course. See https://wiki.openstreetmap.org/wiki/Proposed_features/Clock. This is the proposal and it lists another use case and all tags of the clock were approved.
Note that approved is not the same as established.
Also, regarding the importance (and thus priority in implementation) of any one quest, you can make a very simple calculation: Count the number of elements this would reasonably apply to, subtract the number of elements that are already tagged this way and you got the total number of elements for which this quest would be shown.
For the surface quest, this number is around 87 million plus minus a few millions. How much is it for clock support?
Of course it'll never reach the surface quests, as nearly every street needs it and there are many streets, so this comparison will never match. I think, it is however really interesting to see how many elements still have this tag missing.
I'll have to look that up.
So: Only 50% of the clock tags have a "support" tag. support=pole is BTW most common, 23% of all clocks. And about "display" (analog/digital for us here) I am not sure as it is never displayed in the combinations tab for amenity=clock. However there are about 11000 clocks tagged and 5000 are analog/digital, so maybe it is about 50% too. (Or something else is tagged as analog/digital, but I think this would be strange...).
Data from taginfo.
I agree that I don't quite see the need for this. Maybe rugk would give an example of when this is useful information for people to have?
Generally, knowing the time is always a good thing. :)
See the proposal, there the user had no other time (maybe GSM clock unclear), etc.
Also I think this is really easy to tag, a nice thing to find and can be used for orientation (you'll always see it).
And only having an "amenity=clock" on the map alone, is not very specific, as there is a big difference between a wall clock and this big "poled" 4-faced clock.
Also don't question every tag on OSM. They surely had their reason to add it, which is to map what is there in reality. And here, that's case, I don't see any reason not to add it.
Visibility can be used by a renderer to deside when to start rendering
https://github.com/gravitystorm/openstreetmap-carto/pull/2218 (rejected for this multi purpose map)
Is it analogue or digital?
Can you give example of use of this data that would justify time spent on collecting this data and implementation of the quest?
Yes, that's the thing I was wondering the most. Not why collect data on where there are clocks, but why collect data on whether it's on a wall or not, if it's digital or not etc
Okay, so:
amenity=clock but about adding these extra properties to it@rugk, please put more thought into how meaningful this quest would be, it's quite a waste of time to discuss this everything here. It's not that there is a shortage of ideas what data could be collected with this app. If I searched for ideas, I would simply look into the presets of the iD editor. But ideas are really not the bottleneck of this project, but development time.
I don't see how presets would help. Only some tags are mentioned there and even if, this is a huge list of presets, which does not help.
please put more thought into how meaningful this quest would be, it's quite a waste of time to discuss this everything here.
I disagree. It is needed to discuss this and your time spent on this is actually quite small as the discussion unfolds itself and other people answer. And as you see, there are a lot points in favor and against such a thing.
So whatever you do: Issues are for discussion, discussion is necessary as some ideas need input. I mean that's the whole purpose of GitHub, so please don't always imply discussing things would be bad. If you would not want an open discussion you can always make closed-source software…
Also BTW it does help to discuss some things first and finish them. When the same quest arises later, you can just close it as a dupe. So some things would have to be discussed anyway at some point of time…
I know development is better, but discussions are the first step to get contributors. E.g. leave an issue open, where you are not sure about and do not want to implement yourself, and tag it with "help wanted" (or a custom tag, such a "contribution task").
In any case, please don't suggest issue creators would not think about their issues. Your project is just complicated and it needs some triage in order to evaluate whether/how something can be useful or how the other criteria for a quest are meet. To get a bit more specific, e.g., I, of course, did think about this quest and include more or and more details and reasoning, and you said by yourself first you were "Not sure" about this issue. Now you are implying this issue was worthless from the start, which is just _not true_. Discussion is needed, and yes, it is time-consuming, but it is an essential part of open-source software.
I can always suggest the GitHub open-source guides. (Although I do not want to imply you are missing something there.)
But enough meta-talk…
Thinking about it, it is maybe indeed not that important whether it is digital/analog or so, but more where it stands.
I was originally driven to open this issue, because I saw these tags and thought: "Hey there are these nice tags and they are easy to answer and a very good case for StreetComplete."
As always one can use them for data-mining or so, but in this case I also saw the potential for seeing on a map how a thing looks like.
But yeah, maybe it's not a priority, although I'd say, if I were you, I would still accept PRs on this.
I don't see how presets would help. Only some tags are mentioned there and even if, this is a huge list of presets, which does not help.
Tag not appearing in presets either should be added there or is utterly unimportant.
What you are doing for example with proposing to make quest to tag whatever clock had digital display is not better that slowly copying presets onto issue tracker.
For later part: tldr
Most helpful comment
Not sure if this is clear yet, perhaps I should write it down somewhere if it isn't. Generally:
There are countless things that _could_ be collected, such as the color of the cycleway, the brightness of street lamps, etc. etc.. There is no shortage of that, and I guess there will always be some people who think up a tagging schema for that and put it in the wiki. That doesn't mean it makes sense to collect it.