Proposal:Temperature
| temperature | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | Warin61 |
| Tagging: | temperature=* |
| Applies to: | node/way/area |
| Definition: | A comparative measure of hot and cold. |
| Statistics: |
|
| Draft started: | 2015-01-31 |
Temperature is defined in http://en.wikipedia.org/wiki/Temperature.
Proposal
Temperature is an important property of many things. The tag would be used to describe the temperature of a feature, usually water related within OSM. Similar to height=*, width=*, length=*, distance=*, and tracktype=* keys.
Rationale
On beaches there are public showers, most of these are 'cold' (or more correctly 'ambient'). While a 'cold' shower is good in summer it is less than welcome in winter where a shower that is adjustable to something warmer is preferred.
Where a natural=hot_spring empties into a pool, the pool may be tagged with its' temperature.
A few water objects on the OSM data base have temperature or temperature related tags. There are ~370 temperature related tags on the OSM data base (March 2015) Taginfo temperature. Most, if not all, of these are water related things. Most of these values are subjective (non numerical). Very few have limits (maximum, minimum) fewer again have time constraints.
Most, if not all, OSM features using the temperature key are water related features.
Usage
Stating a numerical temperature means the mapper has to be able to determine it and that it remains stable. This may not be practical nor necessary as the subjective observation may be all that is required. A hot spring is simply that .. hot! The numerical temperature is not required for some situations.
Where the numerical temperature is known, by preference, it should be used. In most real world case the temperature may simply be stated in subjective terms with a full transfer of necessary information.
Values
Temperature is usually measured on a scale from cold to hot. Day to day people talk of hot, warm, cold - subjective terms that have soft definitions and are relative to the then air temperature (or 'ambient temperature'). I call this the 'human temperature scale'. Other units used are the Kelvin, the Celsius and Fahrenheit, these are numerical and objective, and are preferred if available.
Subjective
If the objective (numerical) temperature is not known, a subjective statement can be made. In the 'real world' subjective temperature objects are used every day (example; the 'cold' water tap) and make 'human' sense. While subjective values are not 'liked' in OSM they are used e.g. tracktype=* uses a subjective assessment.
These have the distinct advantage of being relative to the ambient temperature! Something that is 'hot' is hot relative to the then ambient temperature, if the ambient temperature changes then so too may the temperature of the object thus it remains 'hot'.
The following are suggested values listed in order of increasing temperature;
| key=value | explanation |
|---|---|
temperature=freezing
|
Having a temperature where waters freezes. |
temperature=cold
|
Having a temperature colder than chilled. |
temperature=chilled
|
Having a temperature colder than ambient. |
temperature=ambient
|
Having a temperature the same as the external air temperature. |
temperature=warm
|
Having a higher temperature than ambient. |
temperature=hot
|
Having a higher temperature than warm. |
temperature=boiling
|
The temperature of boiling water. |
Format. All subjective values are to be lower case.
Note 'Cold Water Tap'
Tap water is generally labeled 'Cold' but it actually near 'ambient' even though as it comes out a buried pipe its' temperature may be some what different from the ambient air temperature. Here its' temperature would be tagged 'ambient' not 'cold'.
Strange examples; Dalhousie in South Australia. A natural spring provides hot water to a stream that provides water to a pond where the temperature is warm. Dalhousie Spring OSM map
There is a proposal for natural=hot_spring, why not use natural=spring with the tag temperature=hot!
Rendered as a line forming a square - red for hot, blue for cold.
Objective
Where an objective temperature is known it should be stated (as a number).
SI units. Degrees Celsius. Note that the word “degrees” may be left out for ease of data entry. As is the OSM practice (as shown by the default values of width and height) the default unit is degrees Celsius. The use of the Kelvin scale is not common and has been dropped, those who use the Kelvin can easily convert to Celsius and would have both the knowledge and experience to do so with little possibility for error.
Imperial units. The degree Fahrenheit is in common use in North America. Provision for non SI units within OSM has been made in the keys height and width and should be followed here. Conversion by a North American mapper from Fahrenheit to Celsius is not something most are practiced in, leading to a probably high chance of errors. Where used they are to be indicated by using the upper case letter F.
Default unit options;
a) values would be interpreted as degrees Celsius.
b) values would interpreted by region. Most of the world would be Celsius, USA would be Fahrenheit.
c) No default unit. All entries would require a declaration of the units used.
Some are worried that, for example, Americans will enter a number without specifying that it is in Fahrenheit, as is their normal practice. I hope mappers are more aware of the international nature of OSM. There would be similar concerns with minspeed=* and maxspeed=* yet these both accept world wide SI defaults.
For renders and others using the OSM data base the use of Fahrenheit could be detected by the presence of the upper case letter F.
Format. The leading character of the unit is to be upper case. The decimal point is the full stop not the comma, again this follows standard practice (within OSM). The standard practice (within OSM, scientific papers, and as specified by ISO standards and style guides) is to have a white space between numerical values and the unit. The use of the degree symbol is optional, as is the white space.
| key=value | explanation |
|---|---|
temperature=5
|
The object has a temperature of 5 °C. |
temperature=10
|
The object has a temperature of 10 °C. |
temperature=15.5
|
The object has a temperature of 15.5 °C. |
temperature=20
|
The object has a temperature of 20 °C. |
temperature=20 C
|
The object has a temperature of 20 °C. |
temperature=68 F
|
The object has a temperature of 68 °F (equal to 20 °C). |
Rendered as a number followed by °C or °F as appropriate at the top right corner of the relevant symbol.
Example: Hot Tub in OSM.
Seasonal
Follow the values used by seasonal=*, place these after the temperature value and a following '@' symbol.
e.g. temperature= * @ dry_season
Please refer to seasonal=* for current values, March 2015 values are spring, summer, autumn, winter, dry_season, wet_season.
Example: Swimming Pool in OSM
Time
Following the method of opening_hours=*, place these after the temperature value and a following '@' symbol.
e.g. temperature = * @ Mo-Fr 9:00-18:00
Maximum and Minimum limits
Place the limit name after the key, separated by a full colon and before the equal sign e.g.
temperature:maximum= *
temperature:minimum= *
Combinations
Seasonal and time could be combined thus;
temperature= * @ spring Mo-Fr 9:00-18:00; summer Mo 10:00-16:00
Seasonal/time could be combined with the limits using the above system, thus;
temperature:maximum= * @ winter Mo-Fr 9:00-18:00
Adjustable
Where the temperature is adjustable by the user, the maximum and minimum temperatures may be specified (see above limits) and it can be specified as 'adjustable' using the value adjustable thus:
temperature=adjustable
An example of this are showers. Some of these are 'adjustable'.
Use;
amenity=shower
temperature=adjustable
temperature:maximum=hot
temperature:minimum=ambient
One strange example of an adjustable water temperature is Purnie Bore in South Australia. A hot bore can provide hot water to a pond. If you need to increase the temperature the bore is turned on. Convention is to leaved it turned off so it is more convent for future travelers (it takes a long while to cool). Purnie Bore OSM map
Associated Tags
This is a property tag so it must go with a related tag; e.g.,
- amenity=public_bath
- amenity=shower
- leisure=swimming_pool
- amenity=sauna
- man_made=water_tap
- amenity=drinking_water
- natural=spring
- man_made=kiln
There may be more. Please add any that are not present.
Incorrect Values
The following table contains examples of incorrect tags and their correct notation.
| Incorrect | Explanation | Correct |
|---|---|---|
temperature=0,5
|
The comma should not be used as a decimal separator. | temperature=0.5 |
temperature=44°c
|
The 'c' must be in upper case. | temperature=44 °C |
temperature=54 °fahrenheit
|
Fahrenheit must have a leading upper case. | temperature=54 F |
temperature=HOT
|
Subjective values are to be in lower case only. | temperature=hot |
Voting
Instructions for voting.
Log in to the wiki - top right corner of the page -scroll up.
Then scroll down to voting and click on 'edit'.
Copy and paste for
yes - {{vote|yes}} ~~~~
no - {{vote|no}} ~~~~ Please state your reason/s for opposition! This may help a new proposal better fit your requirements.
The ~~~~ automatically inserts your OSM name and the date and time in UTC format.
The voting has been segregated into sections. This means you can vote out a section you object to and vote in those you support, as indicated by comments in the past voting. May indicate which things are the most acceptable.
Vote for/against the proposal temperature=. A vote for/against the general tag of temperature.
Vote for/against the values temperature=subjective. A for/against for the temperature values that are subjective (non numeric).
Vote for/against the values temperature=objective. A vote for/against the temperature values that are objective ( numeric).
Vote for/against the season temperature=* @ (season). A vote for/against the temperature seasonal input.
Vote for/against the time temperature=* @ (time). A vote for/against the temperature time input.
Vote for/against the limits temperature:limits. A vote for/against the temperature limits (maximum/minimum).
Vote for/against the value temperature=adjustable. A for/against for the temperature value of "adjustable".
Past Vote
StartDate= 2015-02-25 EndDate= 2015-03-26
Summary: Fails. Reasons ?
temperature is not for OSM - 2
degree symbol
Fahrenheit
Non numeric values.
I oppose this proposal. - Will need to reluctantly vote no here, the subjectivity of these measures is a poor match for a map. Instead this tag could have talked about the equipment which is more objective. Hot and cold taps are measurable. Huts with with or without fans and air conditioning are measurable. The core temperature tag is fine for swimming pools with a given temperature like this series of saunas: https://www.openstreetmap.org/way/216794906/ but the proposal misses for features like https://www.openstreetmap.org/way/258295736/ with seasons. A very common case is adjustable temperature either heat, cool or both. The tag needs more development to clearly and readily represent those cases. The proposal did not incorporate the discussion on these points (see the discussion tab and mailing lists). "adjustable" is particularly poor, as it does not capture the real world (which sometimes can only be adjusted hotter or colder but not both ways). Brycenesbitt (talk) 22:07, 24 February 2015 (UTC)
I approve this proposal. a good set of qualitative tag values Javbw (talk) 22:01, 24 February 2015 (UTC)- I oppose this proposal. The proposal isn't bad, but it could be better if feedback from the unfinished talk page discussions had been taken into account. In particular, we should spell the units correctly (°C instead of C), and should not support omitting them. --Tordanik 22:10, 24 February 2015 (UTC)
- I believe requiring a degree symbol will not help to improve the quality, I see the risk of several similar looking symbols being used, e.g. ° º ˚ ⁰ --Dieterdreist (talk) 10:42, 12 March 2015 (UTC)
- The degree symbol is simply something many users of the Celsius scale are used to (and thought in school). So it seems a lot more natural than than not using it, imo. I don't expect a huge variety in symbols either, as the others are practically unused. Besides, iD now supports unit dropdowns, eliminating any spelling issues from iD users. --Tordanik 14:13, 14 March 2015 (UTC)
- I approve this proposal. AlaskaDave (talk) 23:18, 24 February 2015 (UTC)
- I approve this proposal. a good set for almost all practical purposes --Jan van Bekkum (talk) 06:52, 25 February 2015 (UTC)
- I approve this proposal. Guttorm Flatabø (talk) 08:12, 25 February 2015 (UTC)
- I approve this proposal. although it seems a bit rigid to impose precise decimal separators and to require whitespace, I think this can work, especially with the generalized verbose values.Dieterdreist (talk) 09:48, 25 February 2015 (UTC)
- I oppose this proposal. I am ok with the proposal if you drop all non-numeric values. They are subjective and hence useless. What's hot for you may be cold for me. Even "dangerously" hot/cold temperature depends on exposure time, clothing, personal constitution etc. If you can't measure the temperature, estimate it. Most values (and coordinates too) in OSM are estimations. I'd also suggest to extend the syntax to ranges, e.g. temperature=10-20, to reflect diurnal or seasonal variations. And I think that you should make the whitespace and the "°" optional because mapper's won't care anyway. Taginfo already lists various combinations of these characters. --Fkv (talk) 14:21, 25 February 2015 (UTC)
- I approve this proposal. Hwoehrle (talk) 15:29, 25 February 2015 (UTC) I think the proposal works well for swimmingpools, saunas etc and therefore hasn't to be absolutly exact nor is there a danger to misunderstood a cold swimmingpool as an ice skating place ;-)
- I oppose this proposal. I support the idea to introduce this tag. However as others already commented, the discussion on non-numeric values has not been finished in the mailing list. Also, as this page clearly states, there are still open questions. With these issues in place, it is not clear what we are voting for. I propose to extend the discussion period and close all open questions. Once it's done, we could have a better defined new tag, for which everyone would happily vote. --Kotya (talk) 09:23, 26 February 2015 (UTC)
- I oppose this proposal. It's an interesting idea, but with such a general tag that can be applied to literally anything, I think it needs better guidelines on suggested usage. I'd prefer infrequent use of this tag, just for permanent objects where temperature is an essential property, the temperature is somewhat constant and not wide ranging, and it doesn't vary by the season or time of day. Seattlefyi (talk) 03:31, 27 February 2015 (UTC)
- I oppose this proposal. Against allowing degree Fahrenheit as a valid value. Also, I see no example of a valid usage. "This is an essential property of many things: water, food, air, ovens, refrigerators." - temperature of water and air is not mappable as it changes too often. Food itself is not mappable therefore attributes of it are also unmappable. Value of mapping ovens and refrigerators seems at the best dubious. Mateusz Konieczny (talk) 11:57, 27 February 2015 (UTC)
- I approve this proposal. RoGer6 (Rogehm) 08:47, 03 March 2015 (UTC)
- I oppose this proposal. +1 to Tordanik and Kotya--Slhh (talk) 23:28, 5 March 2015 (UTC)
- I oppose this proposal. Errt (talk) 20:56, 11 March 2015 (UTC) I'm not against the tag, but the non-numerical values seem strange. Especially defining them in terms of ambient temperature. A swimming pool of 20°C might be cooler than ambient in summer while it is warmer than ambient in winter. Also the extremes are not differentiated well. I hardly can imagine something being dangerously_cold without it being freezing and vice versa. The same, though not to the same extent, applies to boiling and dangerously_hot.
- I oppose this proposal. Noframe (talk) 06:52, 12 March 2015 (UTC) I do not like values someone "feels".
- I oppose this proposal. Bikingtom (talk) 07:43, 12 March 2015 (UTC) 1. IMHO temperatures have no relation to a geographical DB 2. it's not possible to maintain "actual" temperatures when they're changing 3. "felt" values aren't a good idea. We need verifiable/objective data.
- I oppose this proposal. Rza31 (talk) 07:48, 12 March 2015 (UTC)
- I oppose this proposal. Ngt (talk) 07:50, 12 March 2015 (UTC) Some vague values somebody feels are nonsense! Also temperature is likely to be changed often.
- I oppose this proposal. Is not something that is appliable to a lot of objects, see Mateusz Konieczny. --Gormo (talk) 08:22, 12 March 2015 (UTC)
- I oppose this proposal. Another rush to voting. You really need to give tags (a lot) more time to evolve. --Imagic (talk) 08:28, 12 March 2015 (UTC)
- I oppose this proposal. This doesn't belong into a geographical DB. Zimba (talk) 14:50, 12 March 2015 (UTC)
- I oppose this proposal. User 5359 (talk) 15:45, 12 March 2015 (UTC)
- I oppose this proposal. Temperature is not only a property of the examples in the proposal (water, food, air, ovens, refrigerators), it a property of all things. The given examples are poor since we neither tag air or food and I have not seen fridges in OSM yet. Temperature is highly volatile thus tagging absolute values is inappropriate. For certain objects, the level of human intervention is more interesting than the achieved result, e.g. motel with airconditioned=yes or pool with heated=no. --Polarbear w (talk) 21:11, 12 March 2015 (UTC)
- +1, well said Brycenesbitt (talk) 00:00, 14 March 2015 (UTC)
- I oppose this proposal. Foxxi59 (talk) 13:19, 13 March 2015 (UTC)
- I oppose this proposal. (1) If this tag is applied for temperature of the air, it always changes. Using average is also non-sense: a place -15°C (in winter) to 35°C (in summer) and a place 0°C (in winter) to 20°C (in summer) are both written as 10 C, but they are quite different. (2) If a public bath facility has a sauna (80°C), a public bath (40°C), a lower-temperature bath (38°C) and a swimming pool (30°C) in the same building, which temperature should this tag describe? And if there is already this tag such as temperature=40 C, which temperature does the tag describes? Mfuji (talk) 17:14, 14 March 2015 (UTC)
- I oppose this proposal. I think that temperatures is nothing for OSM Mike-001 (talk) 14:11, 18 March 2015 (UTC)
- I oppose this proposal. too vague, no practical example. Measured or expected temp. ? etc. What's the next proposal after colour and temperature ? "smell" or "odour" ? --Pieren (talk) 17:40, 26 March 2015 (UTC)