Re: [Tagging] Feature Proposal - RFC - temperature (mark 2)
On 26/03/2015 11:03 AM, Warin wrote: Hi, I have moved this proposal back into the Comments phase, where ideas and comments can be dealt with, rather than the Voting phase where a change makes the previous votes invalid. Changes? More verbose. A very small sample from the OSM data base. Maximum and Minimum limits. Seasonal/time entry. A reduction in values. Forgot the link ! https://wiki.openstreetmap.org/wiki/Proposed_features/Temperature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
Added 'mild' with note. Changed the order to reflect what I think will be the more frequent use. Tried to add separation horizontal bar to the table for clarity. On 12/02/2015 5:38 PM, johnw wrote: tepid and mild are synonyms, so tepid should cover mild in that way. usually tepid is for liquids, and mild is for air / weather, when it comes to temperature, AFAIK. I think having some human scale values is important - and weather that is a mechanically / chemically / or naturally occurring temperature should be left up to the subtag values. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 12/02/2015 5:38 PM, johnw wrote: tepid and mild are synonyms, so tepid should cover mild in that way. usually tepid is for liquids, and mild is for air / weather, when it comes to temperature, AFAIK. Is ambient is for the ambient air/weather, ambient ground temp, or ambient material temperature? the ambient temperature of the air at the beach is 30-40C.the water’s ambient temp from the shower nozzle is much lower, thanks to it being underground (15-20C?). Underground temperatures change depending on where you are .. permafrost areas are below 0, deserts may be above 26 C. I think having some human scale values is important - and weather that is a mechanically / chemically / or naturally occurring temperature should be left up to the subtag values. Yep. After all it is how we humans asses things. As a 'general guide' most 'westerners' sense 21 C as a desirable temperature.. Those living in the tropics would like a warmer temperature, I'm thinking of Darwin, Australia where the daily maximum is around 32 C .. any season. The residents do get use to that temperature, they put jumpers on at 25 C. Javbw I'll put in the 'dangerous' ones ... another subjective level either side of ambient but reasonably easy to explain .. but mild defies me for the moment. Should I remove tepid .. I don't think many would know it or use it considering the definition I've given for the 'cold water' tap. I've put up the dangerously_hot/cold values .. used the word dangerously as that is more a description. Not certain about 'mild' .. need more time to think about it? II have separated out the 'associated tags' into the complimentary and additional types of tags ... I think that is better than lumping them together as it may confuse where this tag can be added, and then what tags can be added to this tag. Perhaps these words need to be looked at .. and added to the proposal page? I do think the information is usefull. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
Why is a node needed? Here some samples.. Do you have any examples where a specific temperature is measurable? Do you imagine these tags getting used for buildings like motel rooms, huts and caves: and if so what's the suggested tagging scheme for the typical cases? -- Often found in *amenity=drinking_water* taps with* bottle=yes* is the ability to heat the water anywhere from ambient to boiling. How is that addressed by the proposal? *temperature=adjustable* Alone does not capture it, as the typical adjustable range won't include boiling. Perhaps: *temperature:range=ambient-boiling* -- The wiki suggests testing, e.g. by throwing water at the object to determine the temperature. Should that have a survey_date: *natural=rock* *temperature=hot* *temperature:**survey_date=20150101* *temperature:**survey_date:comment=Threw water on the rocks here, and it boiled away within seconds.* *note=Geothermal area* See http://wiki.openstreetmap.org/wiki/Key:check_date ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 12/02/2015 9:43 PM, Bryce Nesbitt wrote: Why is a node needed? Here some samples.. Do you have any examples where a specific temperature is measurable? Do you imagine these tags getting used for buildings like motel rooms, huts and caves: and if so what's the suggested tagging scheme for the typical cases? -- Often found in *amenity=drinking_water* taps with*bottle=yes* is the ability to heat the water anywhere from ambient to boiling. How is that addressed by the proposal? *temperature=adjustable* Alone does not capture it, as the typical adjustable range won't include boiling. Perhaps: *temperature:range=ambient-boiling* Too much detail? How would it be rendered. I think therr is little point in adding information that no one would ever use. Additional tags such as temperature:range can be proposed and discussed after the temperature= tag is passed or rejected.. no point in discussing them if temperature= tag is rejected. -- The wiki suggests testing, e.g. by throwing water at the object to determine the temperature. Should that have a survey_date: as in the source= tag? There are many additional tags that could apply to a single node with a temperature tag ... e.g. name= operator= stating them all ? Why? I'd think that confuses the merit or otherwise of the temperature tag. *natural=rock* *temperature=hot* *temperature:**survey_date=20150101* *temperature:**survey_date:comment=Threw water on the rocks here, and it boiled away within seconds.* *note=Geothermal area* I'd do source:temperature= not temperature:survey_date:comment=Threw water on the rocks here, and it boiled away within seconds. Again .. adds nothing to the discussion on the temperature= tag. Cannot dates be had from the history? See http://wiki.openstreetmap.org/wiki/Key:check_date ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 12/02/2015 7:30 PM, Bryce Nesbitt wrote: On Wed, Feb 11, 2015 at 11:51 PM, Warin 61sundow...@gmail.com wrote: I'd add the tag to any node where I thought the temperature important, significant and I knew the temperature .. even if only subjective .. such as hot. If the temperature changes .. then I'd leave the temperature tag off until sub tags are available for that. Right. Could you illustrate the intention with some specific node numbers? Some specific examples might help clarify the tagging needs, and point out missing values. Why is a node needed? Here some samples.. A shower node 3345445913 in this case amenity=shower temperature=adjustable A number of taps I've added e.g. man_made=water_tap temperature=ambient Nodes? node 3300039448, node 3345450446 one drinking the other not. Want more samples .. why not make them up? amenity=shower temperature=ambient man_made=water_tap temperature=hot man_made=water_tap temperature=boiling man_made=water_tap temperature=chilled ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On Wed, Feb 11, 2015 at 11:51 PM, Warin 61sundow...@gmail.com wrote: I'd add the tag to any node where I thought the temperature important, significant and I knew the temperature .. even if only subjective .. such as hot. If the temperature changes .. then I'd leave the temperature tag off until sub tags are available for that. Right. Could you illustrate the intention with some specific node numbers? Some specific examples might help clarify the tagging needs, and point out missing values. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On Tue, Feb 10, 2015 at 9:04 PM, Warin 61sundow...@gmail.com wrote: A hotel room that has air conditioning may be both heated or cooled depending on the desired temperature and the ambient temperature (and the air conditioner). It usually supplies a measure of fresh air too. I think that this should be considered as part of the building .. and a sub tag developed for that? In fact I think this is the key interesting characteristic to map: does it have a chiller or heater at all? The specific temperature is likely set by the user, or varies by the season, and thus is a poor choice for a database key value. Either the substance is supplied at local ambient, or a facility is made to raise or lower the temperature: heated=yes cooled=no A heated pool would be warm, cooled would be cool? Same with spars and taps.. If adjustable, e.g. as most showers are, then the tag 'temperature=adjustable' is part of this proposal... Frequently it's adjustable just one way. For example we have water heaters for showers, but a water chiller is exceptionally rare. 'temperature=adjustable' does not capture it really. A hotel room with a heater but no cooler for example is adjustable, but not a good place to go when it's 100F and humid. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 12/02/2015 3:45 AM, Bryce Nesbitt wrote: On Tue, Feb 10, 2015 at 9:04 PM, Warin 61sundow...@gmail.com mailto:61sundow...@gmail.com wrote: A hotel room that has air conditioning may be both heated or cooled depending on the desired temperature and the ambient temperature (and the air conditioner). It usually supplies a measure of fresh air too. I think that this should be considered as part of the building .. and a sub tag developed for that? In fact I think this is the key interesting characteristic to map: does it have a chiller or heater at all? The specific temperature is likely set by the user, or varies by the season, and thus is a poor choice for a database key value. Either the substance is supplied at local ambient, or a facility is made to raise or lower the temperature: heated=yes cooled=no Most air conditioners here have the ability to both heat and cool at least here and in the UK. The temperature in large offices, hotels here are usually set centrally .. not by the guest or local worker. Why do you consider heated and cooled an 'interesting characteristic' and how do you see it being rendered on to a map? Is it more 'important/significant' than the suggested temperature values? If so .. why has it not been proposed? I'd think that the vast majority will be interested in; showers that are 'adjustable' in the conventional sense (yet to come across a chilled water facility on a shower), the temperature of water that comes out of a tap (hot, 'cold' or boiling). Note thta boiling is different to hot, boiling can be used to make tea/coffee, hot is not good for making tea/coffee. A heated pool would be warm, cooled would be cool? Same with spars and taps.. If adjustable, e.g. as most showers are, then the tag 'temperature=adjustable' is part of this proposal... Frequently it's adjustable just one way. For example we have water heaters for showers, but a water chiller is exceptionally rare. 'temperature=adjustable' does not capture it really. A hotel room with a heater but no cooler for example is adjustable, but not a good place to go when it's 100F and humid. Usually the adjustably provides for local conditions .. it would be rare to want to reduce a showers temperature below the ambient. In some parts of Asia the locals don't use showers for this reason - they use a scoop of water to wet the body, the interval between scoops provide a time where water evaporates thus providing cooling. Cheap, effective and efficient. Would you label this 'cooled=yes'?I note that OSM does not have a tag for this kind of washing facility. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 11 February 2015 at 17:45, Bryce Nesbitt bry...@obviously.com wrote: On Tue, Feb 10, 2015 at 9:04 PM, Warin 61sundow...@gmail.com wrote: A hotel room that has air conditioning may be both heated or cooled depending on the desired temperature and the ambient temperature (and the air conditioner). It usually supplies a measure of fresh air too. I think that this should be considered as part of the building .. and a sub tag developed for that? In fact I think this is the key interesting characteristic to map: does it have a chiller or heater at all? The specific temperature is likely set by the user, or varies by the season, and thus is a poor choice for a database key value. Either the substance is supplied at local ambient, or a facility is made to raise or lower the temperature: heated=yes cooled=no +1 As first-level tagging the temperature control is the most important feature: ambient=yes/no and/or heating=yes/no and/or cooling=yes/no. The actual temperature or temperature range (either numeric value or descriptive like freezing/boiling) could optionally come after as complementary tag. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On February 11, 2015 3:59:45 PM CST, Warin 61sundow...@gmail.com wrote: On 12/02/2015 3:45 AM, Bryce Nesbitt wrote: Most air conditioners here have the ability to both heat and cool at least here and in the UK. Technically, a unit that can either cool a building, or heat it by cooling outdoor air and transferring heat to indoor air, is a heat pump rather than an air conditioner. Heat pumps are significantly more expensive up-front than air conditioners, due to their greater mechanical complexity, and are only cost-effective as a heating method as long as the temperature to which the outdoor air is chilled is above freezing. As the temperature of the outdoor condenser approaches freezing, the heat pump changes over to using a resistive heating element to heat the indoor air, requiring more electrical power. This means that, in some climates, it is more cost-effective to use a heat source such as an oil-burning or gas-burning furnace as the winter heat source. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. -- Martin Luther King, Jr. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On Wed, Feb 11, 2015 at 1:59 PM, Warin 61sundow...@gmail.com wrote: Why do you consider heated and cooled an 'interesting characteristic' and how do you see it being rendered on to a map? Is it more 'important/significant' than the suggested temperature values? If so .. why has it not been proposed? It's been proposed. If you're in a developing country, the difference between a motel with and without A/C could be significant to you. It's up to the rendering to decide how to represent that key, if at all. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 12/02/2015 10:25 AM, John F. Eldredge wrote: On February 11, 2015 3:59:45 PM CST, Warin 61sundow...@gmail.com wrote: On 12/02/2015 3:45 AM, Bryce Nesbitt wrote: Most air conditioners here have the ability to both heat and cool at least here and in the UK. Technically, a unit that can either cool a building, or heat it by cooling outdoor air and transferring heat to indoor air, is a heat pump rather than an air conditioner. And the common use term is 'air conditioner'. Some cooling only units are heat pumps - they work in humid environments where evaporative coolers fail. Places in deserts or near deserts use the evaporative coolers (Alice Springs, Australia) while those in tropical areas use heat pumps (Darwin, Australia)... what suits the circumstance gets used. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
Hi all, I wonder: shouldn't we separate a conditioned room air in a hotel and an object temperature? I get the feeling that this discussion on a useful tag (how to denote the temperature of an object where it is needed) is slowly drifting away to defining about everything related to temperature. I would concentrate on a set of specific examples (where are mappers/data users likely to want to tag/know the temperature?) and just define the set of the tag values for them. The cases that are not explicitly temperature-related shouldn't be covered by this tag in my opinion. An air-conditioned hotel room is a good counter-example for this tag. It's the comfort level rather than the temperature that is the goal. A temperature of the room is the secondary parameter here. Everyone would understand what an air-conditioned hotel is, but I would struggle to know whether +25 °C in July is comfortable for South Korea or not if I see it in the map. On the other hand, there may be a good exception. The American consulate in Moscow is notoriously known for overusing air conditioning and causing severe colds. People are advised to take pullovers and scarves with them in summer. I've experienced the same in McDonald's in Hungary. +20 °C may be a comfortable temperature but not when it's +35 °C outside and the conditioner is blowing like hell onto your head to keep the temperature down. For such cases, one could tag the place as AC-ed and cold. Summary: I suggest to use this tag (and discuss the recommended values for it) only for the temperature specific cases, not for the whole set of objects having some temperature. Cheers, Kotya On Wed, Feb 11, 2015 at 10:59 PM, Warin 61sundow...@gmail.com wrote: On 12/02/2015 3:45 AM, Bryce Nesbitt wrote: On Tue, Feb 10, 2015 at 9:04 PM, Warin 61sundow...@gmail.com wrote: A hotel room that has air conditioning may be both heated or cooled depending on the desired temperature and the ambient temperature (and the air conditioner). It usually supplies a measure of fresh air too. I think that this should be considered as part of the building .. and a sub tag developed for that? In fact I think this is the key interesting characteristic to map: does it have a chiller or heater at all? The specific temperature is likely set by the user, or varies by the season, and thus is a poor choice for a database key value. Either the substance is supplied at local ambient, or a facility is made to raise or lower the temperature: heated=yes cooled=no Most air conditioners here have the ability to both heat and cool at least here and in the UK. The temperature in large offices, hotels here are usually set centrally .. not by the guest or local worker. Why do you consider heated and cooled an 'interesting characteristic' and how do you see it being rendered on to a map? Is it more 'important/significant' than the suggested temperature values? If so .. why has it not been proposed? I'd think that the vast majority will be interested in; showers that are 'adjustable' in the conventional sense (yet to come across a chilled water facility on a shower), the temperature of water that comes out of a tap (hot, 'cold' or boiling). Note thta boiling is different to hot, boiling can be used to make tea/coffee, hot is not good for making tea/coffee. A heated pool would be warm, cooled would be cool? Same with spars and taps.. If adjustable, e.g. as most showers are, then the tag 'temperature=adjustable' is part of this proposal... Frequently it's adjustable just one way. For example we have water heaters for showers, but a water chiller is exceptionally rare. 'temperature=adjustable' does not capture it really. A hotel room with a heater but no cooler for example is adjustable, but not a good place to go when it's 100F and humid. Usually the adjustably provides for local conditions .. it would be rare to want to reduce a showers temperature below the ambient. In some parts of Asia the locals don't use showers for this reason - they use a scoop of water to wet the body, the interval between scoops provide a time where water evaporates thus providing cooling. Cheap, effective and efficient. Would you label this 'cooled=yes'? I note that OSM does not have a tag for this kind of washing facility. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 12/02/2015 9:57 AM, Bryce Nesbitt wrote: On Wed, Feb 11, 2015 at 1:59 PM, Warin 61sundow...@gmail.com mailto:61sundow...@gmail.com wrote: Why do you consider heated and cooled an 'interesting characteristic' and how do you see it being rendered on to a map? Is it more 'important/significant' than the suggested temperature values? If so .. why has it not been proposed? It's been proposed. Link? A google gets http://wiki.openstreetmap.org/wiki/Tag:craft%3Dhvac and that says all of Workplace or office of an HVAC system designer (*H*eating, *V*entilating, and *A*ir *C*onditioning) Hardly an explanation of what the tag is ... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
Getting further and further away from tag:temperature= On 12/02/2015 12:37 PM, John F. Eldredge wrote: On February 11, 2015 6:16:39 PM CST, Warin 61sundow...@gmail.com wrote: On 12/02/2015 10:25 AM, John F. Eldredge wrote: On February 11, 2015 3:59:45 PM CST, Warin 61sundow...@gmail.com wrote: On 12/02/2015 3:45 AM, Bryce Nesbitt wrote: Most air conditioners here have the ability to both heat and cool at least here and in the UK. Technically, a unit that can either cool a building, or heat it by cooling outdoor air and transferring heat to indoor air, is a heat pump rather than an air conditioner. And the common use term is 'air conditioner'. Some cooling only units are heat pumps - they work in humid environments where evaporative coolers fail. Places in deserts or near deserts use the evaporative coolers (Alice Springs, Australia) while those in tropical areas use heat pumps (Darwin, Australia)... what suits the circumstance gets used. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging If you buy a unit marketed as an air conditioner, rather than as a heat pump, and expect to use it for heating as well as cooling, you are likely to be disappointed. In the USA, at least, heat pump is the standard marketing term for the units that can pump heat in either direction, and air conditioner is the standard marketing term for the units that only pump heat from indoors to outdoors. Not in Australia... and in the UK? http://www.daikin.co.uk/air-conditioning/ On 12/02/2015 9:57 AM, Bryce Nesbitt wrote: On Wed, Feb 11, 2015 at 1:59 PM, Warin 61sundow...@gmail.com mailto:61sundow...@gmail.com wrote: Why do you consider heated and cooled an 'interesting characteristic' and how do you see it being rendered on to a map? Is it more 'important/significant' than the suggested temperature values? If so .. why has it not been proposed? It's been proposed. Where is the link to the past proposal for air conditioning or heat pump or heated or cooled ? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On February 11, 2015 6:16:39 PM CST, Warin 61sundow...@gmail.com wrote: On 12/02/2015 10:25 AM, John F. Eldredge wrote: On February 11, 2015 3:59:45 PM CST, Warin 61sundow...@gmail.com wrote: On 12/02/2015 3:45 AM, Bryce Nesbitt wrote: Most air conditioners here have the ability to both heat and cool at least here and in the UK. Technically, a unit that can either cool a building, or heat it by cooling outdoor air and transferring heat to indoor air, is a heat pump rather than an air conditioner. And the common use term is 'air conditioner'. Some cooling only units are heat pumps - they work in humid environments where evaporative coolers fail. Places in deserts or near deserts use the evaporative coolers (Alice Springs, Australia) while those in tropical areas use heat pumps (Darwin, Australia)... what suits the circumstance gets used. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging If you buy a unit marketed as an air conditioner, rather than as a heat pump, and expect to use it for heating as well as cooling, you are likely to be disappointed. In the USA, at least, heat pump is the standard marketing term for the units that can pump heat in either direction, and air conditioner is the standard marketing term for the units that only pump heat from indoors to outdoors. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. -- Martin Luther King, Jr. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On Feb 6, 2015, at 8:03 PM, Kotya Karapetyan kotya.li...@gmail.com wrote: 1) +1 to drop Kelvins. 2) heated/cooled is a nice idea, but I wouldn't like seeing too many top level tags. Danger-cold cold cool mild warm hot danger-hot I don’t think is unreasonable if we’re going to have qualitative tags, to have 7 values. there needs to be a distinction between something that is uncomfortably hot and dangerously hot. (AKA a hot springs and a steam pipe). You can’t have “cold mild hot” as the only qualitative/ subjective tags, because the extremes and values in between are common descriptions of items in a qualatiative sense = “That steam pipe is dangerously hot” that desert cave is mild inside” “The mountain hut is warm inside That hot springs is hot but enjoyable” They may be qualitative, but is verifiable to some degree, and useful if there is no exact temperature known, or it varies in a predictable range (hot springs water is often “danger-hot”, though the temperature goes up and down with earthquakes and other geologic activity - but 90C and 95C water is still dangerous. also, my stab at method: temperature:method=mechanical / fire / natural / material or inherent temperature:range=cooled / heated / controlled / variable / adjustable If further detail is needed, then temperature:mechanical= forced_air_heater / swamp_cooler / freon_AC / freon_freezer / tankless_heater etc temperature:fire=fire_pit / fireplace / kerosene_heater / wood_stove mechanical: whatever method (HVAC, refrigerator unit, oil heater, etc) is used to heat the item or the air inside the item. fire: directly burning wood or a material to receive heat (AKA a fireplace, gas fire pit, stove). natural: the place is in a situation where it is naturally different from the ambient temperature of the area (AKA caves in the desert are mild, esp. compared to right outside the entrance - both during the hot day and cold nights. (I think natural is the smallest category of use) material: the material being moved or the item itself is inherently that temperature (unnaturally) at that current state - AKA a steam pipe, an exhaust pipe, a heat exchanger, a refrigerant line. if we want to get into semantics that a shower could be a cold shower, a warm shower, and a hot shower, usually, marking “hot” for the temperature means hot water is available to mix, so it would be: amenity=showers temperature=hot Additional info: temperature:range=adjustable temperature:method=mechanical temperature:mechanical=tankless_electric_heater but a beach shower, for washing off the sand is amenity=showers temperature=cool additional info: temperature:range=variable temperature:method=material (the water being transported is inherently cool). anyways, those are my ideas Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 12/02/2015 1:23 PM, johnw wrote: On Feb 6, 2015, at 8:03 PM, Kotya Karapetyan kotya.li...@gmail.com wrote: 1) +1 to drop Kelvins. 2) heated/cooled is a nice idea, but I wouldn't like seeing too many top level tags. Danger-cold cold cool mild warm hot danger-hot I don’t think is unreasonable if we’re going to have qualitative tags, to have 7 values. there needs to be a distinction between something that is uncomfortably hot and dangerously hot. (AKA a hot springs and a steam pipe). You can’t have “cold mild hot” as the only qualitative/ subjective tags, because the extremes and values in between are common descriptions of items in a qualatiative sense = “That steam pipe is dangerously hot” that desert cave is mild inside” “The mountain hut is warm inside That hot springs is hot but enjoyable” They may be qualitative, but is verifiable to some degree, and useful if there is no exact temperature known, or it varies in a predictable range (hot springs water is often “danger-hot”, though the temperature goes up and down with earthquakes and other geologic activity - but 90C and 95C water is still dangerous. also, my stab at method: temperature:method=mechanical / fire / natural / material or inherent temperature:range=cooled / heated / controlled / variable / adjustable If further detail is needed, then temperature:mechanical= forced_air_heater / swamp_cooler / freon_AC / freon_freezer / tankless_heater etc temperature:fire=fire_pit / fireplace / kerosene_heater / wood_stove mechanical: whatever method (HVAC, refrigerator unit, oil heater, etc) is used to heat the item or the air inside the item. fire: directly burning wood or a material to receive heat (AKA a fireplace, gas fire pit, stove). natural: the place is in a situation where it is naturally different from the ambient temperature of the area (AKA caves in the desert are mild, esp. compared to right outside the entrance - both during the hot day and cold nights. (I think natural is the smallest category of use) material: the material being moved or the item itself is inherently that temperature (unnaturally) at that current state - AKA a steam pipe, an exhaust pipe, a heat exchanger, a refrigerant line. if we want to get into semantics that a shower could be a cold shower, a warm shower, and a hot shower, usually, marking “hot” for the temperature means hot water is available to mix, so it would be: amenity=showers temperature=hot Additional info: temperature:range=adjustable temperature:method=mechanical temperature:mechanical=tankless_electric_heater but a beach shower, for washing off the sand is amenity=showers temperature=cool additional info: temperature:range=variable temperature:method=material (the water being transported is inherently cool). anyways, those are my ideas Javbw Nice ideas... But first the tag temperature= has to be accepted. Then consideration could be given to other things like the methods used to achieve the temperature. You could have lots of things. Such as amenity=shower temperature=adjustable temperature:range=ambient_to_hot temperature:method=mixed_ambient_and_heated - where heated to hot water is mixed with ambient water to the users setting. First temperature .. then the sub tags for those interested in them .. even temperature:method=mixed_ambient_and_heated-electic+solar But first temperature= But first temperature= ... the rest can come later as required. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
Danger-cold cold cool mild warm hot danger-hot But first temperature= But first temperature= ... the rest can come later as required. gotcha - those 7 qualitative tags should be included, besides numerical values expressed in C. You are correct, the method, variability, and adjustable nature can be expressed separately. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
tepid and mild are synonyms, so tepid should cover mild in that way. usually tepid is for liquids, and mild is for air / weather, when it comes to temperature, AFAIK. Is ambient is for the ambient air/weather, ambient ground temp, or ambient material temperature? the ambient temperature of the air at the beach is 30-40C.the water’s ambient temp from the shower nozzle is much lower, thanks to it being underground (15-20C?). Ambient requires knowledge of the surrounding area - but we are trying to use qualitative words based on human range. If I stick your hand in a pot of water, and it is tepid - is that the ambient temperature of where I got the water? how is that expressed? the fact that it is tepid/mild says nothing about the ambient temperature of where it came from. again - this is subjective or qualitative. a “tepid” 25C cave is quite nice in a 50C desert. Trying to match qualitative words to C values would be difficult - and impossible if it is for different mediums (air water, metal, etc). or is that the exercise? to match qualitative words to known C value ranges for the purpose of the Wiki? I think having some human scale values is important - and weather that is a mechanically / chemically / or naturally occurring temperature should be left up to the subtag values. Javbw I'll put in the 'dangerous' ones ... another subjective level either side of ambient but reasonably easy to explain .. but mild defies me for the moment. Should I remove tepid .. I don't think many would know it or use it considering the definition I've given for the 'cold water' tap. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 12/02/2015 6:08 PM, Bryce Nesbitt wrote: On Wed, Feb 11, 2015 at 8:51 PM, johnw jo...@mac.com mailto:jo...@mac.com wrote: Danger-cold cold cool mild warm hot danger-hot What are some example nodes, where this proposed tag may apply, and how you might suggest tagging. I'd add the tag to any node where I thought the temperature important, significant and I knew the temperature .. even if only subjective .. such as hot. If the temperature changes .. then I'd leave the temperature tag off until sub tags are available for that. Here are a few possible nodes I thought of: -- And for: http://www.themresort.com/dining/32draft.html Should the entire bar be tagged: temperature=32 F No, the bar is not 32 F? Or perhaps just the taps for each beer type? Yes. Each tap could be tagged with the temperature .. and I hope you include the names of each beer ... (Irrelevant factoid: On the Isle of Man there are over 100 beers on tap.) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 12/02/2015 3:51 PM, johnw wrote: Danger-cold cold cool mild warm hot danger-hot But first temperature= But first temperature= ... the rest can come later as required. gotcha - those 7 qualitative tags should be included, besides numerical values expressed in C. You are correct, the method, variability, and adjustable nature can be expressed separately. Javbw _ Ummm What does a 'mild temperature' mean? http://forum.wordreference.com/showthread.php?t=1062358 says closer to umm 21 C... so if the predicted or normal temperature is cold then it is less cold, but if the predicted or normal temperature is hot then it is less hot? I think that is hard to render... let alone convey to someone with a good English knowledge. I'll put in the 'dangerous' ones ... another subjective level either side of ambient but reasonably easy to explain .. but mild defies me for the moment. Should I remove tepid .. I don't think many would know it or use it considering the definition I've given for the 'cold water' tap. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On Wed, Feb 11, 2015 at 8:51 PM, johnw jo...@mac.com wrote: Danger-cold cold cool mild warm hot danger-hot What are some example nodes, where this proposed tag may apply, and how you might suggest tagging. Here are a few possible nodes I thought of: --- For example near: http://www.openstreetmap.org/node/2131603829 as documented at http://www.tripadvisor.com/LocationPhotoDirectLink-g60791-d126799-i77634556-Hot_Creek-Mammoth_Lakes_California.html Would one tag: http://www.openstreetmap.org/node/2131603829 With temperature=danger-hot --- For https://www.openstreetmap.org/relation/3667357 Would that be: temperature=cold source=survey on 2014 august, when it was very cold inside --- For https://www.openstreetmap.org/node/262877905 temperature=boiling - And for: http://www.themresort.com/dining/32draft.html Should the entire bar be tagged: temperature=32 F Or perhaps just the taps for each beer type? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 6/02/2015 11:22 AM, Bryce Nesbitt wrote: There are cases where an approximate temperature is more useful than a single scalar number. For example a drinking fountain may be chilled, but not operating at a single fixed temperature. Similarly there's a big difference in a tropical climate between a building with A/C and one without. And a mountain hut with a fireplace, compared to one without. Neither can be expressed well as a temperature=. In many cases what matters is the ability to warm or cool from ambient. A/C give you the ability to make a room cooler than ambient, but not hotter. A fireplace the opposite. Thus perhaps instead: heated=yes cooled=no Could apply to pools, spas, hotel rooms, water taps. A hotel room that has air conditioning may be both heated or cooled depending on the desired temperature and the ambient temperature (and the air conditioner). It usually supplies a measure of fresh air too. I think that this should be considered as part of the building .. and a sub tag developed for that? A heated pool would be warm, cooled would be cool? Same with spars and taps.. If adjustable, e.g. as most showers are, then the tag 'temperature=adjustable' is part of this proposal... I have done a number of changes ... A) Removed the Kelvin as a unit for data entry. B) The water tap labelled 'cold' issue. For tagging I think this should be labelled 'ambient'. I have added a note about it, and added words that cold means colder that ambient .. similar words have been added for the other subjective terms. Should examples of the relevant subjective values be added to aid there use? C) Removed the safety references. Boiling water of 0.5 gram would do little harm to the palm of the hand, a 1kg bit of metal at 75 C would cause burns... so the safety is not all about temperature. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
If we're going to have a temperature key - there should be some qualitative values in human understandable ranges. Yes, they are subjective. Cool/ cold / frozen / danger-cold Warm / hot / boiling / danger-hot Mild (human range comfortable, both hot and cold) This allows tagging for objects / pipes / buildings with unexpected temperatures. there are refrigerators (cold) sub-zero freezers (danger-cold) and exposed steam pipes (Danger-hot) which have very different temperatures from their ambient environment - and knowing the exact temp of the freezer, or the range it operates in is not so useful, but knowing that it is someplace where if you stayed there, it could kill you is very useful. There could also be a sublet value to define class of method, if the object itself isn't the source of the temperature (aka a steam pipe is inherently hot, but a room is made hot by a device or method) temperature=mild temperature:hvac=controlled (heatedcooled) temperature=warm temperature:hvac=heated temperature=warm temperature:fire=heated temperature=danger-cold temperature:hvac=cooled temperature=-20 (c) temperature:hvac=cooled (freezer warehouse where the value is constant and known) Filing all the different man made heating options (radiator, electric heater, oil boiler) it all gets filed under HVAC (heating ventilation air conditioning), as method might be very hard to determine how something is kept warm, but it could be filed in the hvac subkey. Temperature:hvac=kerosene_heater Temperature:fire=wood_fireplace Just my ideas, not sure how well they fit - but having some kinds of qualitative values is important, as the range is more useful than the exact number most of the time. Javbw On Feb 6, 2015, at 9:22 AM, Bryce Nesbitt bry...@obviously.com wrote: There are cases where an approximate temperature is more useful than a single scalar number. For example a drinking fountain may be chilled, but not operating at a single fixed temperature. Similarly there's a big difference in a tropical climate between a building with A/C and one without. And a mountain hut with a fireplace, compared to one without. Neither can be expressed well as a temperature=. In many cases what matters is the ability to warm or cool from ambient. A/C give you the ability to make a room cooler than ambient, but not hotter. A fireplace the opposite. Thus perhaps instead: heated=yes cooled=no Could apply to pools, spas, hotel rooms, water taps. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
1) +1 to drop Kelvins. 2) heated/cooled is a nice idea, but I wouldn't like seeing too many top level tags. temperature=heated temperature=cooled 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 temperature=heated temperature:heated=fireplace|HVAC 3) +1 for having mild added. It is not the same as ambient and is useful. Cheers, Kotya On Thu, Feb 5, 2015 at 9:14 PM, Warin 61sundow...@gmail.com wrote: On 5/02/2015 1:02 AM, fly wrote: Am 04.02.2015 um 10:56 schrieb Kotya Karapetyan: Hi, +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. +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. 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. 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. 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) 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 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 temperature_minimum= ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
Just a nitpicking detail, using 'degree' with the Kelvin scale was deprecated in 1968 by the 13th General Conference on Weights and Measures. See http://en.wikipedia.org/wiki/Kelvin#Usage_conventions Lukas Sommer wrote on 2015-02-05 08:50: I suppose that in most countries of the world, °C is the common unit for temperature in daily normal live. °F is only used in very few countries. °K is only used in the scientific world, but not in daily normal live. Dave Swarthout wrote on 2015-02-05 01:53: For clarification, the Kelvin temperature scale is almost never used outside of a chemistry or physics lab. Absolute zero, the lowest possible temperature, is defined as 0 degrees Kelvin. That is approximately equal to minus 272 C and minus 460 F. Nobody working on OSM is likely to be specifying temperatures in degrees K. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
begin rant I also think Americans, and I am one, need to get over the use of degrees F and the old inch/foot/mile system. It's stupid and anachronistic to base the units of length on the length of the king's thumb, or whatever. Continuing to make exceptions for them is only perpetuating their intransigence. end rant +1 Although many americans enjoy F for their daily lives (and I like the finer gradation in temperature in the “comfortable human zone (~50-100) “ - Americans are used to seeing and using C in scientific settings and international projects - so as long as the tag has proper documentation (and a proper label for the search term in the renderers), then there should be no confusion in using Celsius. Even university libraries are switching to A4 paper to deal with international of documents (rather than relying on letter or legal). - An American adapting to Celsius in Japan Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
There are cases where an approximate temperature is more useful than a single scalar number. For example a drinking fountain may be chilled, but not operating at a single fixed temperature. Similarly there's a big difference in a tropical climate between a building with A/C and one without. And a mountain hut with a fireplace, compared to one without. Neither can be expressed well as a temperature=. In many cases what matters is the ability to warm or cool from ambient. A/C give you the ability to make a room cooler than ambient, but not hotter. A fireplace the opposite. Thus perhaps instead: heated=yes cooled=no Could apply to pools, spas, hotel rooms, water taps. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
On 5/02/2015 1:02 AM, fly wrote: Am 04.02.2015 um 10:56 schrieb Kotya Karapetyan: Hi, +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. +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. 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. 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. 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) 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 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 temperature_minimum= ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
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? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - temperature
If we look how other units are treated in OSM (http://wiki.openstreetmap.org/wiki/Map_Features/Units) than the keys have always default units. Which one is the default unit differs from key to key. For example, the default unit for width=* is “meter”, while the default unit for distance=* is “km”. So the default unit is not based on SI units, but on the commonly used unit for this pourpose. I suppose that in most countries of the world, °C is the common unit for temperature in daily normal live. °F is only used in very few countries. °K is only used in the scientific world, but not in daily normal live. So I think it’s important to have a clearly defined default unit, and this default unit should be °C. Nevertheless, I think it is a good idea to encourage people to tag “with” the unit. Lukas Sommer 2015-02-05 0:53 GMT+00:00 Dave Swarthout daveswarth...@gmail.com: For clarification, the Kelvin temperature scale is almost never used outside of a chemistry or physics lab. Absolute zero, the lowest possible temperature, is defined as 0 degrees Kelvin. That is approximately equal to minus 272 C and minus 460 F. Nobody working on OSM is likely to be specifying temperatures in degrees K. begin rant I also think Americans, and I am one, need to get over the use of degrees F and the old inch/foot/mile system. It's stupid and anachronistic to base the units of length on the length of the king's thumb, or whatever. Continuing to make exceptions for them is only perpetuating their intransigence. end rant This specification is getting quite complex, don't you think? I'm betting we will never see most of these fine gradations in temperature rendered on a map. my 2 cents On Thu, Feb 5, 2015 at 4:05 AM, Warin 61sundow...@gmail.com wrote: 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
Re: [Tagging] Feature Proposal - RFC - temperature
Am 04.02.2015 um 10:56 schrieb Kotya Karapetyan: Hi, +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. +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. 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. 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 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 ? cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
