[Tagging] Feature Proposal - RFC - temperature

Warin 61sundowner at gmail.com
Wed Feb 4 21:05:23 UTC 2015


On 5/02/2015 1:02 AM, fly wrote:
> Am 04.02.2015 um 10:56 schrieb Kotya Karapetyan:
>> >
>> >1) I would discourage specification of the temperature without the
>> >scale indication. I have never lived in the US but I see from the Web
>> >that Americans like specifying temperature in degrees Fahrenheit
>> >without mentioning it (the same way as we in Europe use centigrade
>> >without underlying it). Taking into account the international nature
>> >of the OSM community, I foresee a significant risk that the map will
>> >get populated with invalid values. Warin is right about SI units, but
>> >SI is not even strictly followed in the technical and scientific
>> >community, not to mention the general public. Obviously, Americans in
>> >general ignore it by using inches, miles and degrees Fahrenheit:)  I
>> >am afraid many people will not have heard about SI guidelines and will
>> >not have read the wiki page in significant detail.
>> >
>> >Therefore, for the sake of clarity, I suggest always specifying "F" or
>> >"C" with the temperature value.
> +1
> Units for temperature are really wired and obviously Kelvin which I
> would suspect to be the default is not really used in real live as
> Celsius has the better scale for real life usage.

Matter of common use between C and K.
The default of height is metres .. not feet. Don't know if there is any 
confusion over that? I do take your point over the default.. insisting 
on the unit may be a good way of ensureing that F is not confused with 
C. But I'd like to see other people ideas on this .. are they prepared 
to enter the unit (even thought it is abbreviated) every time they enter 
a temperature?
>> >2) I suggest clarifying the verbal specification of the temperature.
>> >- Replace "chilled" with "cool" (by analogy with "warm") and also
>> >because "chilled" actually assumes that I know that the object was
>> >purportedly cooled down, which adds yet another uncertainty and is
>> >usually not very relevant;
>> >- remove the definition of "substantially colder" etc., because it
>> >doesn't add any clarity. I agree that it is important to distinguish
>> >between safe and unsafe situations, so let's just do that:
>> >
>> >freezing
>> >cold — may be unsafe to handle
>> >cool
>> >warm
>> >hot — may be unsafe to handle
>> >boiling
>> >adjustable — the object temperature can be changed by consumer/user
>> >variable — the object temperature can vary on its own
>> >ambient — the object always remains at ambient temperature (note that
>> >this may include the object being "cold" and "warm", including being
>> >unsafe to handle, depending on the ambient temperature; think about
>> >water in Siberia rivers in January)
> Only two values I could live with are cold and hot. Generally these
> values are too ambiguous and an estimated value is much better.

Chilled as in chilled water is in common use. The mapper may want to 
include it. I don't know how to render that to a map. What a mapper 
chooses to enter is up to them. I'm only rendering adjustable, hot and 
cold at this point anyway.
>
>> >3) For the numeric specification, I suggest adding:
>> >- "above"/"below" options
>> >- "approximate" value
>> >- range of temperatures (using above/below)
>> >
>> >E.g.
>> >temperature:circa = 80 C
>> >temperature:above[:circa] = 300 C
>> >temperature:below[:circa] = 1000 C
> I would add this in the value like:
>
> temperature = < 10 C
> temperature = > 300 C
>
> We still can use source:temperature=estimated

No .. you'd have a conflict e.g.
temperature = 45
temperature = estimated

? which 'value' is 'correct' '

Might be better as

temperature = 45
temperature:accuracy = estimated



>
> 4) How do we tag a shower with cold and hot water ?
>
> temperature=4 C;80 C ?
>
> Does this depend on the hose, e.g. one separate for each temperature or
> a mix-batterie ?
>
temperature=adjustable .. that is what it is for ... may be an e.g. 
after the description?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150205/4836062b/attachment.html>


More information about the Tagging mailing list