[Tagging] Feature Proposal - RFC - temperature
61sundowner at gmail.com
Thu Feb 5 20:14:00 UTC 2015
On 5/02/2015 1:02 AM, fly wrote:
> Am 04.02.2015 um 10:56 schrieb Kotya Karapetyan:
>> +1 for the proposal as such.
>> I have suggestions for some parts of the proposal though.
>> 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.
> 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.
I'm inclined to drop the Kelvin. Unlikely to be used, anyone using the
Kelvin can easily convert it to degrees Celsius.
>> 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:
I put that in to cover the 'chilled water' that some might have or come
across. Maybe more of a hot climate thing? I think the users may include
it anyway so I covered it in the documentation.
>> cold — may be unsafe to handle
>> hot — may be unsafe to handle
>> 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.
I think I said this .. but here it is again with some more thoughts?
The proposal only tags 3 conditions;
adjustable - box outline around the originally rendered symbol - red at
the top fading to blue at the bottom
hot - box outline around the originally rendered symbol - red
c*old -*box outline around the originally rendered symbol - blue
For the numerical data rendered as above for hot if over 55 C and blue
if under 0 C ??
>> 3) For the numeric specification, I suggest adding:
>> - "above"/"below" options
>> - "approximate" value
>> - range of temperatures (using above/below)
>> 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
Nice idea. But;
How many object in OSM need that kind of information? If the usage is
low then it probably wont be rendered.
How many data entry people will know the max/mins for an OSM object?
And how would it be rendered?
Possibly a better tag for this would be temperature_maximum= and
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging