[Tagging] Feature Proposal - RFC - temperature
kotya.lists at gmail.com
Fri Feb 6 11:03:35 UTC 2015
1) +1 to drop Kelvins.
2) heated/cooled is a nice idea, but I wouldn't like seeing too many
top level tags.
would be my preferred way to go.
I don't like :hvac too much either, because then what do I do if I
have AC + fireplace + central heating and use all of them for heating?
I would rather, if needed, use
3) +1 for having "mild" added. It is not the same as "ambient" and is useful.
On Thu, Feb 5, 2015 at 9:14 PM, Warin <61sundowner at gmail.com> wrote:
> 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
> cold -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
> Tagging mailing list
> Tagging at openstreetmap.org
More information about the Tagging