Proposal talk:Clock

Further attributes

it would also be nice to have an attribute to indicate, if the clock is indipendent or remote-controlled. Dieterdreist 11:56, 21 January 2009 (UTC)

Barometers measure atmospheric pressure, not humidity - not sure what the name of a humidity measurer is. Chillly 12:33, 21 January 2009 (UTC)

Hygrometer - - http://en.wikipedia.org/wiki/Hygrometer

Hygrometer was added. --Avatar 14:10, 21 January 2009 (UTC)

What about...?

I know a number of such public clocks that no longer go, for whatever reason. Do you need to tag these with something like

time=probably_wrong

in these cases?

This was mentioned by at least two other people I spoke with ("offset", "broken"). I'm not yet sure about this because typically broken clocks will be fixed sooner or later and should not stay out of order permanently. So a note via note=* would perhaps be good enough? --Avatar 12:23, 21 January 2009 (UTC)

Perhaps disused=yes or abandoned=yes would apply in many circumstances where clocks aren't working? Frankie Roberto 22:40, 21 January 2009 (UTC)

I think disused=yes would match - the only problem I can think about is a broken clock on the ground (sundial without pole?) big enough to walk on it. disused=yes implies access=no :-) --Avatar 08:16, 4 February 2009 (UTC)

Usefulness

I believe the situations when this would be useful are restricted by the fact that the map in most cases is on some digital device that also has a clock. The only time I can think of is when you need a clock and happen to have a printed map (with rendered clocks) over the area available. --Erik Lundin 22:59, 21 January 2009 (UTC)

In this cases you still can use the mapped clocks as navigation points. --Avatar 23:46, 21 January 2009 (UTC)

'unorthodox' display mode

All other display modes than the one proposed shouldn't be tagged as display=unorthodox. It would be better to specify analog/digital/sundial and leave the rest to the users & tagwatch. --Ævar Arnfjörð Bjarmason 17:21, 22 January 2009 (UTC)

I'm not really sure about this. The tagging as display=unorthodox allows easy filtering for "interesting" clocks worth visiting. Otherwise you would have to filter for empty keys and mistyped keys. Because I assume that there would be very few unorthodox clocks I'm not sure if we're able to extract further useful display keys out of tagwatch. But you are right: If we use unorthodox we do have a loss of information if the "unorthodox method" isn't included into another field like e.g. the name=* tag. --Avatar 08:22, 4 February 2009 (UTC)

Sundials

As a big fan of sundials, I am happy to see this proposal include them. I am note sure, though, if sundials would not justify their own top-level tag. You introduced the clock tags as something that is useful for telling the time, and as a landmark. You would probably not tell the time from a sundial--they have more of a historic/attraction aspect to them.

There are sundial societies in many countries. To enable the experts (mathematicians, historians, daylighting professionals) to use OSM for mapping sundials all over the world, a few extra tags would be nice to have:

http://www.sundials.co.uk/types.htm

http://en.wikipedia.org/wiki/Sundial

orientation=S|SE|multiple|... (There is a dial in the heart of London called 'Seven dials'. It actually has seven dials on it.)

material=steel|stone|brass|unknown, or even

material:gnomon and material:face

Also: please add support=plinth

--Blumpsy 19:02, 2 February 2009 (UTC)

I think these tags are rather special and mostly interesting for sundials. Right now I don't plan to include them into this "more general" proposal. But I do think that proposing a seperate "top-level" tag for sundials would be a good idea. --Avatar 08:27, 4 February 2009 (UTC)

clock=yes vs amenity=clock

In Norway, the most common usage of these public clocks are on amenity=place_of_worship and amenity=bus_station, and amenity=clock would then conflict with the other purposes of the tag. If the clock is standing alone on a simple pole, why not just tag a node with clock=yes? Does it really have to be an amenity? As far as I know, there are few clocks that are only a clock, so most of them can be tagged as something else with clock=*. Besides, we already have a tag for amenity=signpost (Though nobody have written the page, but it is present on Map Features). In other words, there is an amenity for the item where you put the lone clock. Please use clock=yes instead. --Skippern 19:09, 8 February 2009 (UTC)

I think we can go further than this, and put the clock's display type (which I see as its most important property) into the value of our hypothetical clock=* tag. See below. I'd suggest removing display=* from this proposal, and inventing clock=* (meaning "... has a clock [of type...]") to do this --achadwick 11:43, 9 February 2009 (UTC)

Yes, clock=* with any other value than false or no would indicate there is a clock present, and therefor clock=digital would be a better choice than clock=yes + display=digital. But my point in raising this issue is that amenity=clock conflicts with its usage in most cases, such as church towers (amenity=place_of_worship), bus and train stations (amenity=bus_station), signposts and poles (amenity=signpost, yes it exists) and so on. This proposal should be turned down, rewritten and put for another vote. --Skippern 21:18, 10 February 2009 (UTC)

clock=<display-value>, anyone?

There are many buildings around here that have clocks on their sides, without actually being a clock in themselves. They might have amenity=something-else already, and as you can see people hate that notion. If it's OK, I'd like to do away with display=<display-value> and suggest people use clock=<display-value> instead. This should keep both crowds happy, and it also fits with the a=b|b=c|c=d pattern of refinement commonly used elsewhere. --achadwick 11:40, 9 February 2009 (UTC)

Where <display-value> is one of {digital, analog[ue], unorthodox, yes, no, <user-defined>}, to clarify. --achadwick

Arguably some of the other auxiliary tags are a bit much for a situation such as the one described above. Could we perhaps suggest a clock: prefix for them, at least as an alternative for when the object is primarily something else? --achadwick 11:40, 9 February 2009 (UTC)

If the proposal is turned down, we might be able to rewrite it to be more logical, I fully disagree with using amenity=* on it, only clock=* and any true value will indicate that there is a clock there, so unless anybody decides that no or false is types of clocks, any other value will be true. --Skippern 14:04, 12 February 2009 (UTC)

I fully agree with amenity=clock for standalone clocks, so I'll leave that in place. Minispec for what I want to do --achadwick 12:09, 19 February 2009 (UTC)

Clock display types done as clock=* minispec

Key	Value	Use/Meaning	Image
amenity	clock	Primary tag. A stand-alone clock which is part of no other notable structure. Just a clock on its own, sitting there and showing the time; could be built into a plain wall, most are found on fancy poles or frames. Only use for clocks that are an amenity in their own right. Rule of thumb: if it's primarily a stand-alone clock (perhaps with a company name on it as early advertising, but nevertheless primarily a clock), then tag it as `amenity=clock`. Otherwise it's probably an `amenity=<something-else>`. Either way, add in one of the attributes below to further refine or describe it.
clock	analogue TODO: en_US or en_GB spelling?	Auxiliary tag, for use with amenity=clock or any other feature. The feature has (or is) a publicly-visible analogue clock.
clock	digital	Auxiliary tag, for use with amenity=clock or any other feature. The feature has (or is) a publicly-visible digital clock.
clock	unorthodox	Auxiliary tag, for use with amenity=clock or any other feature. The feature has (or is) a publicly-visible unorthodox clock, and the fact that it's unorthodox is worthy of note.
clock	sundial	Auxiliary tag, for use with amenity=clock or any other feature. The feature has (or is) publicly-visible sundial.	FIXME: image needed
clock	yes / no / <user-defined>	Auxiliary tag, for use with amenity=clock or any other feature. The feature has (or is) a publicly-visible clock of some other kind. no means that there's no clock (face) where you'd normally expect there to be one	FIXME: images needed?

Top one can be tagged amenity=signpost with clock=true--Skippern 12:55, 19 February 2009 (UTC)
- Fixed --achadwick 21:20, 19 February 2009 (UTC)
The building on example 2 might be an amenity, clock=analog is definitely a good tag.
- Should we use American or British spelling though? What does the rest of the project do? Arguably it should be the most widely taught flavo(u)r of English that we use... --achadwick 21:20, 19 February 2009 (UTC)
  - Use the british way of spelling. Because OSM has started in Great Brittain, not in the USA. S.A.L. 10:46, 12 May 2009 (UTC)
This can be amenity=signpost with clock=digital
- I don't think signposts meet a basic requirement of permanence or notability for mapping. Mind you, it was probably a bad example anyway for the reasons mentioned: fixed with a little help from flickr. --achadwick 21:20, 19 February 2009 (UTC)
Sundail should be tourist=attraction or similar with clock=sundail
- A sundial in a garden probably wouldn't be notable enough to be a tourist attraction, though grand Indian astrological ones certainly are. Sometimes it's just a (standalone) clock, and amenity=clock fits the bill fine. --achadwick 21:20, 19 February 2009 (UTC)

Hope this clearify WHY amenity shouldn't be used, only clock=* --Skippern 12:55, 19 February 2009 (UTC)

Sorry, I still see a need for amenity=clock for genuinely standalone clocks like the one pictured (for all that you can also hang flowers off it too). Do you deny that they benefit or beautify the places they're in, that they provide a public good? I normally hate pollution of amenity=* with random junk and stuff that falls better under other defined categories, but in this case there's a case for standalone clocks being an amenity in their own right, and a case for being able to say that other features - which can be amenitys or not - have clocks. --achadwick 21:20, 19 February 2009 (UTC)
- As I see it, 99% of the cases clock can be combined with other amenity tags, so amenity=clock is just for odd cases. If that is so, than it is better to isolate it to just a clock=* tag, and let the renderer eventually have one rule for clocks. If you have it your way than we can see a lot of instances such as amenity=place_of_worship;clock amenity=signpost;clock and so on. It would be a much cleaner approach if we only needed to look for clock=* with a true value, besides if we only want a specific type of clock (digital?) we could only look for clock=digital. If you want other amenities to be tagged with clock=* in addition to its other amenity purpose, while clocks that are not part of other amenity to be tagged as an amenity, than you will have a lot of strange tagging going on. --Skippern 12:18, 20 February 2009 (UTC)
  - Agreed that it would be wholly wrong to do the semicolon trick here: it implies that the clock-ness is as important as the place_of_worship-ness, which would probably be incorrect. It's still quite useful to be able to say unambiguously for your "1%" (which I suspect in practice will be around 25%-75% depending on how many people bother to tag churches with clocks) that an object is just a clock and nothing else. That way the data consumer doesn't have to worry about counting up other tags, checking for amenity=*, shop=*, *=* and having a load of extra funky logic in there to distinguish the standalones from the non-standalones. Merely test for the presence of amenity=clock. --achadwick 14:27, 20 February 2009 (UTC)
  - I do intend to make it crystal clear that what was voted on is representing a standalone public clock with amenity=clock, and that while clock=* can be used to further refine the description of one, having clock=* by itself doesn't make something a standalone clock. --achadwick 14:27, 20 February 2009 (UTC)
  - Probably just easier to accept this proposal and modify it on Sunday to be a bit more logical and expressive. Not much of an argument, I know; but a good compromise. The minispec/patch above is deliberately backwards-compatible with the proposal as it stands. --achadwick 14:27, 20 February 2009 (UTC)
  - BTW, you describe a wider problem when you bring up what taggers sometimes do inappropriately with semicolons. We probably need to state on the amenity=* page that it doesn't support semicolon-separation and emphasize that the convention used for ref=* isn't a general convention that one can just assume works for all keys. It's a shame that the FAQ entry about semicolons is written in a way that suggest that one can: want to fix it? --achadwick 14:27, 20 February 2009 (UTC)

Corner cases

While flickring for suitably-licensed images, I came across a photo of a digital sundial: and googling shows that various models are available for sale. Interesting: how to tag that? I guess as digital rather than a specific type of clock "dial" --achadwick 21:20, 19 February 2009 (UTC)

clock: prefix, anyone?

Continuing my bad-boy stance regarding display=*, would anybody be up for moving all the other "useful keys" describing clocks into a clock: namespace prefix, rather like people might do for amenity=fuel|fuel=*? I'd like to be able to say:

amenity=clock | clock=digital | clock:date=yes

Or, for a church which happens to have a clock on top of it and some bells:

amenity=place_of_worship | clock=analogue |clock:support=tower | clock:bells=yes

I think this would be a flexible, extensible, and clash-free scheme. --achadwick 21:39, 19 February 2009 (UTC)

accessibility for blind persons

How about clock:sound=speaking/60/15 (speaking: telling the time on demand, numbers: Intervall in minutes, how often the clock rings the bells) to have it routing software for the blind or in tactile maps? --Lulu-Ann 13:18, 10 March 2009 (UTC)

Cool idea. Perhaps clock:speaking=yes/(language code...?)/no for a speaking clock. Since clock:bells=yes is mentioned above, perhaps say something about how the bell strikes the hours and quarters (or whatever else). Searching Wikipedia, I find that striking clocks that sound the sequence Westminster Quarters are quite usable by blind persons, albeit usable only four times an hour. Ship's bells is another striking pattern.
How to express possible bell striking patterns? Perhaps using the value part of clock:bells=*?
Are there any other sorts of clocks that are usable by blind people? Braille springs to mind, as do repeater mechanisms. --achadwick 18:06, 11 March 2009 (UTC)

Time zone

It shall be mentioned which time the clock shows, the time_zone ist needed.

Move this from amenity to information

As there are thermometers without clocks, I would rather see these features at information=clock/thermometer/hygrometer.

information isn't a stand-alone key. It should only be used to add details to tourism=information, and I don't think that clocks (or thermometers/hygrometers) should be marked with tourism=information. --Tordanik 13:23, 13 January 2010 (UTC)

I agree that information is until now only used with tourism, but to reflect reality: Information has not only to do with tourism.--Lulu-Ann 10:59, 15 January 2010 (UTC)

The word "information" isn't limited to tourism, but the OSM key currently is. And so far, no one has provided any practical reason for not using amenity=clock. I don't really understand how using information=clock/thermometer/hygrometer is supposed to make it easier to tag those features than amenity=clock/thermometer/hygrometer. --Tordanik 11:24, 15 January 2010 (UTC)

Proposal talk:Clock

Contents

Category

Further attributes

What about...?

Usefulness

'unorthodox' display mode

Sundials

clock=yes vs amenity=clock

clock=<display-value>, anyone?

Clock display types done as clock=* minispec

Corner cases

clock: prefix, anyone?

accessibility for blind persons

Time zone

Move this from amenity to information

Navigation menu

Proposal talk:Clock

Category

Further attributes

What about...?

Usefulness

'unorthodox' display mode

Sundials

clock=yes vs amenity=clock

clock=<display-value>, anyone?

Clock display types done as clock=* minispec

Corner cases

clock: prefix, anyone?

accessibility for blind persons

Time zone

Move this from amenity to information

Navigation menu

Search