Re: [Tagging] Water collection points (in french "Borne de puisage")
Hi Vincent, Please, what do you thing as a good way to tag it : - emergency=fire_hydrant and usage=* - amenity=hydrant and hydrant:type=* - amenity=water_point I would not go for anything like emergency=fire_hydrant or amenity=hydrant. This would make people confuse these bornes with real fire hydrants sooner or later. As fire departments already use emergency=fire_hydrant it's to risky. Also the wiki clearly states[0]: A fire hydrant in OSM is defined as a device to take water for firefightening purposes and it can be pressurized or not. I would use man_made=standpipe colour=green water_source=main The wikipedia[1] indicates that standpipe is the proper term for this thing. According to taginfo[2] it is already in use (434x). Moritz [0]: https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_hydrant [1]: https://en.wikipedia.org/wiki/Standpipe_(street) [2]: https://taginfo.openstreetmap.org/tags/man_made=standpipe#overview ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Urbex
+1 for Michal's thoughts. Thus not mapping it explicitly. Whoever wants to find spots suitable for Urbex should look for ruins/abandoned etc. Regards Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))
Hi François, Am 2017-12-20 19:00, schrieb François Lacombe: 2017-12-20 12:21 GMT+01:00 Moritz <o...@moritzmueller.ee>: I disagree, that would make the proposal useless. Then only wrench and check_date would be left. That wasn't my point. pump=yes can stay in the proposal I misunderstood that. But pumps tagging is far more complex than values you propose. Facts are it's difficult to change established values and I'm not so keen on voting them without further thinking. I agree. But adding the tags like Viking proposed pump=yes|powered pump:driven_by=electricity|water. would not change the any established tags, only add some additional keys. I don't want to open a new proposal process for pumps just for having better hydrants tags. If we would change establiched values it would make sense. But for now it would only add overhead. Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))
Hi Viking, Am 2017-12-21 10:20, schrieb Viking: Hi all. First of all I invite to put comments also on discussion page [0], because it remains a trace useful for voting decisions. We don't need a detailed description for pumps, we need to know only if there is a pump connected (or inside) the water reserve and if it is electrical or water driven. +1 All other pump details can be developed in a separate proposal by someone else if he/she has reasons to do that. +1 Key pump already exists for water wells: [1], [2] Values for our use can be pump=yes or pump=powered. Also pump:type already exists, but if you think it is too generic, we can introduce pump:driven_by=electricity/water. Could be. or pump:powered_by=electricity|water pump:power_medium sounds less clear to me: what do you think? Yes, not the best option. Moritz [0] https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_Extensions_(part_3) [1] https://wiki.openstreetmap.org/wiki/Key:pump [2] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_well ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))
Hi, It depends on what characteristics are important to you. "water driven" is power transfer medium so pump:power_medium=water. This is not the energy source! It doesn't say if the water has potential/kinetic energy due to gravity, or if it itself is being pressurised by a powered pump (e.g. hydrostatic drive) "integrated" is to distinguish from something else? What would be alternatives to a pump being "integrated"? "bilge pump" is about its function, so something like "pump:function=bilge" "in a well" is about its location so "pump:location=bottom_of_well"? How about the type of pump? Centrifugal? Reciprocating? And the medium that is being pumped? In this context it is probably water but in general a pump could be used for all sorts of stuff. Let me explain, what the idea of adding pump tags to hydrants in the proposal is: In Germany we have fire water wells whose geodetic suction head is > 7.5 m (in theory water can be pumped up to a suction head up to 10.3 m (1013 mbar pressure, water temp 4 °C, but due to losses real level is lower). To allow the fire engines to pump water from those wells, one of two types of pumps are integrated into the well: * Electric pumps * Bilge pumps Maybe bilge pump is not the right word for it, but dictionaries proposed it ;) For running electric pumps you have to bring a power source. The bilge pumps are driven by water. So you have a second set of couplings to pump water to the pump and get it back into the fire engine's tank. This water will drive the pump. The well has a third coupling which outputs the pumped water. The idea is now to add this information to the hydrants/wells that the firefighters/whichever data consumers can easily see if they have to setup an additional power source (generator or fire engine) before getting water. If this is the case I personally would evaluate if there is a hydrant or well nearby where the water is more easy to access. What about pump=yes|electric|water_driven This will need a whole proposal to get a comprehensive description for pumps. I think we should only use pump=yes for now and wait for a more complete document to be written. I disagree, that would make the proposal useless. Then only wrench and check_date would be left. Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))
Hi Colin, Am 2017-12-19 16:29, schrieb Colin Smale: Please don't use "pump:type" as it invites people to use it for loads of different things. You are actually doing it yourself. A "bilge pump" is functional and says nothing about the construction or power source (even if there is such a thing as a typical bilge pump). And "electric_pump" is about the power source, and says nothing about the function or construction. What is your suggestion for proper tagging a * water driven bilge pump which is integrated in the well * an electric pump integrated in the well? Moritz On 2017-12-19 16:20, François Lacombe wrote: Hi Viking, Thank you for your work on this additional part I'd be in favor of grouping pump et pump:type in on "pump" key. Valid values would be yes, bilge_pump or electric_pum. Yes would be used only if pump technology is unknown. There is no need of 2 keys. All the best François FRANÇOIS LACOMBE fl dot infosreseaux At gmail dot com www.infos-reseaux.com [3] @InfosReseaux [4] 2017-12-19 10:40 GMT+01:00 Viking <vikin...@tin.it>: I removed all "useful combination" on hydrants wiki, because all optional tags could be added to this list and it would become unnecessarily long. Best regards Alberto --- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus [1] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [2] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging Links: -- [1] https://www.avast.com/antivirus [2] https://lists.openstreetmap.org/listinfo/tagging [3] http://www.infos-reseaux.com [4] http://www.twitter.com/InfosReseaux ___ 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 - Voting - (Fire Hydrant Extensions (part 2)
Alberto, thanks for your effort. I've updated fire hydrant page [1]. Can you check it, and improve it, if necessary? Will check it and try to translate for the German version. Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions (part 2))
After many revisions to fire hydrant proposal, I request you to vote the new version of this proposal [1]. [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_2) Thanks a lot for your effort Alberto. There is already a map which implements the scheme: User wambacher provides the Emergency Map[0]. And has he thinks the proposal will pass he implemented the new scheme here[1] Examples [2][3][4] O means obsolete, may be changed to U for undefined. Original post in the German forum[5]: Die Hydranten mit fire_hydrant:type=pond, dry_pillar und suction_point sind in dieser Version hinfällig und werden mit einem großen O für "obsolet" dargestellt. Wem da ein anderes Icon besser gefällt, gerne her damit. Evtl nehme ich auch ein U für "undefined". Das Fragezeichen bleibt weiterhin für Hydranten ohne fire_hydrant:type. [...] Da es noch kein Proposal für emergency=suction_point gibt, stelle ich die derzeit auch nicht dar. which translates to The hydrants fire_hydrant:type=pond, dry_pillar and suction_point are deprecated in this version and will be shown with a "O" (obsolete). If anyone has a better idea for an icon feel free to send. Maybe I will use an "U" undefined. The question mark indicates hydrants without fire_hydrant:type. [...] As there is no proposal for emergency=suction_point yet, I'm not displaying them at the moment. Moritz [0]: https://wambachers-osm.website/emergency/ [1]: https://wambachers-osm.website/emergency/idx033.jsp [2]: https://wambachers-osm.website/emergency/idx033.jsp#zoom=17=48.72454=11.14784=Mapbox%20Streets=FFFTF [3]: https://wambachers-osm.website/emergency/idx033.jsp#zoom=15=42.84884=-73.88817=Mapbox%20Streets=FFFTF [4]: https://wambachers-osm.website/emergency/idx033.jsp#zoom=19=50.786488=17.053026=Mapbox%20Streets=FFFTF [5]: https://forum.openstreetmap.org/viewtopic.php?pid=672476#p672476 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Sinkholes refinement
Am 2017-11-14 20:31, schrieb Yuri Astrakhan: Hi David, you do have a point. Perhaps it should be altered after the voting? Unless if no one has voted yet one way or the other? Awaiting other opinions. On Tue, Nov 14, 2017 at 1:34 PM, David Marchal <pene...@live.fr> wrote: Hi, Yuri. Though I understand your request and find it relevant, I’m unsure about altering a proposal page after the vote had started; AFAIK, I’m supposed to let it as is, apart from the vote section. Could you show me if my assumption is wrong, or can someone on the ML confirm or infirm that? Awaiting your answers, Regards. Le 12 nov. 2017 à 21:17, Yuri Astrakhan <yuriastrak...@gmail.com> a écrit : David, hi, just an thought - could you combine the rationale and examples sections? The way you have it now is first you describe each concept, and afterwards you have the same concept but with a picture. I think it would be better to list each variant with the picture right away. Hi David, Yuri, as far as I understand the voting phase passed and it was approved. I would not change the proposal anymore. Then it is also in the future clear what the voting was about. I think the combination of examples and rationale can be put into the feature page in which the proposal results in. The proposal process[0] page also states for the voting phase "At this point there must be only one proposal on the page, which should not be changed anymore, so it's clear what is being voted on." Cheers Moritz [0]: https://wiki.openstreetmap.org/wiki/Proposal_process#Voting ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 2)
Nakaner just commented on his user page So, wie es aussieht, ist es jetzt deutlich besser. Die verbleibenden Tagänderungen sind in meinen Augen ausreichend gut begründet Which translates to How it looks like now is way better. The remaining changes of tags are to my mind sufficiently explained. So I think, we are good to go. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 2)
Am 2017-11-09 18:12, schrieb Viking: About the split, if someone wants to go in that direction, he can start a new proposal focused on that point. I think that we all agree, don't we? You are right, I think there is still the part 3 of the proposal and afterwards we can think about a new one. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 2))
Moritz, did you contact individually people who opposed the previous proposal? Yes, I left a comment on every discussion page. It seems that at least some of them commented on the new proposal. One feedback I got via mail was that we should split hydrants and suction_points, as they are in Germany different things ;) But apart from that we can go for voting. Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions)
No, I didn't concact them individually yet. Moritz, can you do it?\ Will do. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions) (Moritz)
The new proposal sounds reasonable for me. Have you already contacted anybody who opposed the previous proposal? I'm still thinking it would make sense to ask them individually but don't want to annoy them by to much contact requests. Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions)
Me too. Can anyone check if the proposal [1] is consistent and error-free? Feel free to add better descriptions. I will read over it on the weekend. And then can we go directly to vote it, or have we to call a RFC again? I would start a (possible shorter) RFC again and explicitly ask the people who opposed it if they have any more concerns. I hope that we can work it out in beforehand and that not any new opposer pop up suddenly. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions)
Thanks for the effort you put in this proposal and splitting it again. Regarding your last question how to proceed: I would aim for the proposals to get approved (even if it only means that there are some people on the tagging list how voted for it and it is not related to all the other mappers out there). Because having the proposals approved it is easier to argue with the projects using the hydrants data to adapt the new scheme. Apart from that the recent proposal split makes sense for me and I see a chance that part 2 and 3 will be approved. If not: Propose. Discuss. Vote. Repeat. ;) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants split
As nobody reacted on my last post on splitting it in a different way, just let us go for voting and see what will happen. Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants split
Am 2017-09-16 19:19, schrieb Viking: Thank you for splitting it. I think it is worth to think about splitting the two proposals in a different way: One for adding new keys (like flow_rate, water_source) and the other one for migrating the fire_hydrant:* keys to something else. I see two main reasons for it: 1. Migration According to the huge number of affected nodes (~300k for fire_hydrant:position=*) [1] I'm afraid that a lot of voters will oppose the proposal due to the huge impact of it. In this case we would also not have the well discussed new tags and need to start a new proposal. 2. The part 2 proposal works only if part is agreed on. At least for pump and suction_head keys. So a rejected part 1 proposal makes the second more or less useless. So I would put the changes from part 2 (pump, suction_head, wrench) in part 1 and move the whole migration issues from part 1 to part 2 Since we are using colon ( : ) in many tags, I'm wondering if we should switch back to: couplings_type -> couplings:type couplings_diameters -> couplings:diameters +1 Cheers Moritz [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions#Values_to_be_replaced ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
Hi Marc, if you want to group unlimited sources, it seems best to use water_volume instead of creating an "artificial" value for the tag water_source I want to group natural water sources. That these are unlimited is just a side effect. And waterbody is not artificial. What is the advantage of clarifying the source to stream, lake, river etc? For me it makes the key water_source more complex without an advantage. I think it is easy and a better quality to put the type of source in water_source and the volume in water_volume instead of having the volume that influences the source value. Why should we add another key (water_volume) to an unlimited source where the information "unlimited" is implicitly given by the water_source=waterbody key? Again this would add more complexity. Cheers Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
Am 2017-09-14 12:46, schrieb marc marc: With that scheme it is clear, that the amount of water is unlimited (waterbody) or limited (pond, together with the volume key) would not it be easier to keep the 2 separate info? water_source for the source (stream, river, lake, ocean, sea) water_volume=x m3 or illimited (or something like that) I'm afraid that I'm not understanding you right. What do you mean with would not it be easier to keep the 2 separate info? I would group unlimited, natural sources (stream, river, lake, ocean, sea) under water_source=waterbody Artificially created pond as water_source=pond and where the volume is known (pond, swimming_pool) add the water_volume key. For hydrants it makes no sense to distinguish between river, lake etc. The important information is that it is one of the unlimited sources. And to minimize the amount of values waterbody should be enough. Therefore we don't need water_volume=unlimited in this case. Maybe water_volume=unlimited should be optional and the default value? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
In a water well, the initial water level corresponds to min_suction_head=# because it is the highest level that water can reach. Then water level will drop and suction head will increase. If you can't measure max_suction_head, simply leave the tag empty. You are right ;) Maybe we should find a better suitable value for water_source=stream which reflects also lakes. What about water_source=waterbody instead of stream? So pond, stream, river, lake go in waterbody? For me it is ok. I would go for stream, river, lake, ocean, sea -> water_source=waterbody pond if it is a natural pond also -> water_source=waterbody if it is an artificial created pond then it should be water_source=pond and get the water_volume key. With that scheme it is clear, that the amount of water is unlimited (waterbody) or limited (pond, together with the volume key) Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
Am 2017-09-08 00:51, schrieb Viking: For these cases and for ponds or rivers where the water level may vary, we can use: min_scution_head=# (meters) when water level is high and the distance from ground level is to the minimum max_suction_head=# (meters) ) when water level is low and the distance from ground level is to the maximum For water wells min and max_suction_head is not suitable. There we should introduce suction_head=# I know, that the water level will drop if you suck a lot of water out of a well. But it will not be practical to reflect those level changes (how to measure, after which time etc). You are right, m^3 is shorter. But I don't mind if it's 75000 l or 75m^3. Small, medium, large don't have to be, because it is not as well defined as a absolute value. I think it depends on the country, so the applications using this information can convert from l to m^3 or small|medium|large +1 The default unit should be m^3 because if you have a pond with 1000m^3 1000 is better to use then 100 l. Maybe we should find a better suitable value for water_source=stream which reflects also lakes. What about water_source=waterbody instead of stream? Cheers Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire_hydrant: tagging namespace documentation
Am 2017-09-12 23:16, schrieb Viking: I've found that in man_made=water_well [0], pump=* and pump:type=* are already in use. I think we can use the same tags for hydrants connected to fire water wells. Don't we? +1 If we add new values like bilge_pump and electric_pump to the pump:type key. Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire_hydrant: check_date
what can a operational_status be net specific enough for a hydrant ? if you test that water is going out the hydrant, I didn't see what is not specific enough to call it "a functional check" +1 Let's say if the hydrant meets the requirements in terms of pressure/flow rate it status is ok. Just a check if water comes out is not enough. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire_hydrant: tagging namespace documentation
In the discussion page [0] someone says that check_date=* is a synonymous of survey:date=* in common usage. Is this correct? Should we use another tag functional_check=* ? But I don't like to introduce a new tag. +1 for not introducing a new tag. But I think we need two different types of date tags. First the survey date, aka a local mapper mapped the hydrant and saw it on the ground. Second the check date, which should contain the date where the last functional check was done. We should not complicate the functional checks. As first approach a general functional check is sufficient. If we divide the functional check into flow, accessibility etc. we will have a never ending story with this proposal. If e.g. it was a check for the flow, then a change in the flow_rate should indicate the check. What further information do we gain if we separate different checks? operational_status is not an official tag, but widely used [1]. So I would add it to the proposal to reflect different status of the hydrant. [1]: https://taginfo.openstreetmap.org/keys/operational_status#values ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
And there seems to be a consensus for grouping all things where firefighters can attach their pump under emergency=fire_hydrant. Where there is a dedicated pipe/hydrant. Where there is a 'Static Water Supply' then there are usually no formal fittings of any description. 'Static Water Supply' you mean a place near a pond/lake/stream where no prebuilt pipe is available and it is just a place where to park the fire engine to get easy access to the water by using there own hoses? As far as I understood that will be the emergency=suction_point But I think there are some issues left: # Fire Water wells A pipe connected not to a pond but to the groundwater. Should be water_source=groundwater How to tag the water level (distance between water level and ground level)? water_level=6 (in meters) ? Also there are water wells which have a water level below approx 8 m and due to physics there is an additional pump needed. This pump is integrated in the water well at water level and is either driven by electricity or external applied water pressure. Humm water level is usually taken as the height reached by the water, from the bottom of a well/dam/tank. If you are sucking then you might get to the bottom .. so you would need equipment to get to the very base of the water. Must be a better term for this parameter? You want the dimension from the pump point to the minimum (most distant height) water level. You are right. I mean the distance between the ground level and the water level. E.g. the water is 3 m below ground. Does anybody have a better idea then water_level? Background is: the lower the vertical distance between water level and pump the easier it is to suck the water to the pump. Depending on the pump and hoses (small airgaps at the hose connections etc) it can be difficult to get water from vert. distances > 6/7m. For firefighters this information is important, because if they have more then one well to choose from they can use the one with the smaller vert. distance. water_volume=# (numeric value in m^3). Around me capacity is stated in litres? So this could be a optional unit. I'd rather not see a small|medium|large value. You are right, m^3 is shorter. But I don't mind if it's 75000 l or 75m^3. Small, medium, large don't have to be, because it is not as well defined as a absolute value. I think it depends on the country, so the applications using this information can convert from l to m^3 or small|medium|large Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
Hi all. I'm back from vacation and see that there was a huge progress in the proposal. And there seems to be a consensus for grouping all things where firefighters can attach their pump under emergency=fire_hydrant. But I think there are some issues left: # Fire Water wells A pipe connected not to a pond but to the groundwater. Should be water_source=groundwater How to tag the water level (distance between water level and ground level)? water_level=6 (in meters) ? Also there are water wells which have a water level below approx 8 m and due to physics there is an additional pump needed. This pump is integrated in the water well at water level and is either driven by electricity or external applied water pressure. The pressure tag is not suitable for it as the water does not need to be sucked out and the pressure is not known. But the information is important for fire fighters to know which additional equipment they need. pump_type=bilge_pump|electric_pump|none ? # Water tanks water_source=water_tank The capacity of the water_tank should also be attached to the hydrant. water_volume=small|medium|large|# (small 75–150 m^3, medium) 150–300 m^3 and large>300 m^3 or numeric value). # Fire water pond water_volume=# (numeric value in m^3). # fire_hydrant:class=* Should be clarified what AA, A, B, C means. Cheers Moritz Am 2017-09-06 00:24, schrieb Viking: Hi all. @Marc and is this tag well used? I am not able to judge whether values are realistic Well, as in every tag, there are wrong values. But now, with a more clear description on the wiki, there will be less errors and future corrections will be possible. Anyway all values of fire_hydrant:diameter=# should go in the new tag diameter=#, or whatever else we choose. what do others think? if somebody find it is not appropriate, I think that it would be desirable to split out the "meaning change" to validate the rest of the proposal. At this point, after the discussion of pros and cons, I think that the "meaning change" has no more sense. @Francois: fire_hydrant:count=# --> devices=# +1 I'm against grouping more than one hydrant one a node, but if we want to keep this possibility, devices=# for me is better. A pressurized hydrant : emergency=fire_hydrant + optional water_source=network + even more optional pressure=* A pillar connected to a water tank where water can be pumped from : emergency=fire_hydrant + water_source=water_tank + pressure=0 A pipe going permanently in a river or a pond where water can be pumped from : emergency=fire_hydrant + water_source=pond + pressure=0 +1 @Martin: unfortunately this is not yet defined unambiguously In hydraulics in general, the diameter is the nominal one [0] that is related but not equal to the inner diameter. On hydrants in particular, the number that is die-casted on them, is the nominal diameter of the undergound junction towards the water network. Also couplings diameters are always nominal diameters of the threads [1]. Maybe it is enough to document on the wiki that when diameter=* is used for hydrants, it is referred to nominal diameter? Not sure about pressure=0 though, shouldn't that be 1? The wiki mentions also "suction" for dry hydrants In hydraulics, pressure normally is measured relatively to atmospheric pressure. So 0 is correct. However, to avoid misunderstandings, we can keep pressure=suction for these cases. Best regards, Alberto [0] https://en.wikipedia.org/wiki/Nominal_Pipe_Size [1] https://en.wikipedia.org/wiki/ISO_metric_screw_thread --- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus ___ 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] Fire hydrants vs suction_point
Hi Richard, I've also no idea what a proper English word for that could be. But as suction point is widely used in this case I would stick on em=suction_point. Moritz On 18 August 2017 23:05:57 CEST, Richard Welty <rwe...@averillpark.net> wrote: >On 8/18/17 4:33 PM, Moritz wrote: >> >> Hi Richard >>> in actual real world usage, however, they are called dry hydrants by >>> their >>> users (the fire departments). they are even signed as "dry hydrants" >in >>> many >>> cases. there's such a sign not far from me, i can go take a picture >of >>> it. >> I think it's a language issue here. >> Here in Germany these dry hydrants are called suction point (actually >the German word for it) with proper signs. >normal practice in these cases is to fall back on british practice. >i have no idea what that might be. > >richard > >-- >rwe...@averillpark.net > Averill Park Networking - GIS & IT Consulting > OpenStreetMap - PostgreSQL - Linux > Java - Web Applications - Search > > >___ >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] Fire hydrants vs suction_point
Just one more thing: Dry and wet barrel hydrants are both pillar type hydrants. What about tagging both as fire_hydrant:type=pillar and something like pillar:type=dry_barrel|wet_barrel So the people who are just interested in the type of hydrants (underground, wall, pillar...) can evaluate fh:type tag. When somebody wants to know it in more detail he can check for pillar:type. Moritz -- von unterwegs...___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
>For suction point another proposal of refinement is needed. +1 I'm currently on vacation but will do something when I'm back in two weeks. So will be more quiet from my side until then. Cheers Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
Hi Richard >in actual real world usage, however, they are called dry hydrants by >their >users (the fire departments). they are even signed as "dry hydrants" in >many >cases. there's such a sign not far from me, i can go take a picture of >it. I think it's a language issue here. Here in Germany these dry hydrants are called suction point (actually the German word for it) with proper signs. Moritz ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
Hi Mark, the hydrant (by the meaning of the word) is something connected to the water main ;) If I read the previous wikipedia link, there are pressurized hydrant and not-pressurized hydrant. If wikipedia use the word hydrant for both, maybe the "by the meaning of the world" is that. I would rely on the Collins English Dictionary in this point rather then on wikipedia [1] (General Engineering) an outlet from a water main, usually consisting of an upright pipe with a valve attached, from which water can be tapped for fighting fires. See also fire hydrant According to this definition a dry hydrant is not a hydrant because of the lack of connection to the water main. Regards Moritz [1]: http://www.thefreedictionary.com/hydrant ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
Hi all and thank you for those interesting developments
My point is all about semantics and ease the mappers' work
Like everyone, I agree to distinguish pressurized fire hydrants, and
"dry"
hydrants like ones where a pump is required to get water.
But not in favor of an additional value of emergency key.
This will lead to extra large and cluttered like
emergency=big_yellow_fire_hydrant and
emergency=small_cap_covering_underground_valve
It's really interesting both from mapper and consumer view to use
several
keys to give pieces of information.
Ok, my understanding is you want to have only to categories:
* Pressurized water sources (fire hydrants)
* "dry" hydrants where a pump has to be brought to get water ("dry"
hydrants or suction points or whatever tag it will be)
Pressurized or not, there are connectorized pipes wich allow
firefighters
to get water which have a given appearance on ground (barrel,
underground,
pipe...)
Even if it's not always pressurized, the design of such things is done
as
to allow the water to flow under pressure (gravity, pumped or whatever)
and
that's why I like to think "dry" and "pressurized" "hydrants" are all
members of the same set of feature.
Then we should not call it hydrant, because the hydrant (by the meaning
of the word) is something connected
to the water main ;)
Otherwise, you have ponds, wells, which are open field water sources
But "dry" hydrants are always connected to other water sources like
ponds, wells, water_tanks.
They are not isolated things on the field. So you have the "dry" hydrant
which is next to a pond/lake/etc. and
connected to it.
When I'm understanding you right, you propose to put dry hydrants into
same category like real hydrants.
Because the mappers can't distinguish between real and dry hydrants.
But then the problem what to do with the other variants of suction
points (e.g. wells) persists.
Here in Germany there are wells which can look like dry hydrants. So the
unexperienced mappers would put them
also in the hydrants category, according to your above statement.
This leads to no or little value of these information for the
firefighters. When I have to decide where to get water
for the fire engine, I try to avoid using wells, ponds, lakes in first
place. Just because the hazzle to get water
quickly is much bigger than just connecting the hose to the hydrant.
In a second time, i respectably disagree (without shortening the good
work
done) to namespaces keys suction_point:, fire_hydrant: and so on...
In some cases they are redundant and don't ease the key name typing in
editors without pressets.
It may be great to don't encourage them, please.
You mean you disagree on on using something like suction_point:source=*
and suction_point:position=* to further describe
the features of a given suction point/dry hydrant?
How would you attach the additional attributes to such a
dry_hydrant/suction point when you just have 2 categories for more then
2 items to be distinguished?
But I agree that we will somehow end up improving the tagging of
hydrants/dry hydrants and stuff ;)
Cheers
Moritz
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
Suction point is probably not the right word in English. I haven't found any specific idiomatic usage of this phrase, so it seems to just mean "point where suction is present/applied". I think it suction_point is just a word by word translation of German word for it (point where to suck water). Probably some German guy started to tag dry hydrants as suction_points first so we are now have the term suction_points Dry Hydrant seems a better fit for what you are discussing, do you agree? http://www.nfpa.org/assets/gallery/firewise/operationWater/step3.htm https://en.wikipedia.org/wiki/Fire_hydrant#Non-pressurized_.28dry.29_hydrants From the language point of view I agree. But from the technical point I would not call it dry hydrant. Because: when there is the word hydrant in it there will be people saying Hey a dry hydrant is a subset of a hydrant. Which it is not. Because there will not be pressurized water from the dry hydrant and the dry hydrant is not connected to the water main. And what about the fire water wells, how would you tag them? They are no dry hydrants. And I got the feedback that another tag for fire water wells are not needed because we can enhance the emergency=suction_point. With the emergency=suction_point we can group every point where firefighters can obtain non pressurized water (ponds, rivers, wells) by attaching a pump together. Maybe suction_point is not the right word for it. But I have no better idea at the moment ;) Dry hydrants would only cover a few of them and we would need another tag for them. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fire hydrants vs suction_point
use as water_tanks are usually hidden under ground they are not as visible as suction points. So I assume they will be not mapped as often as suction points. Other point: to get the volume information of the suction point you have also to check the next water_tank. Seems inconvenient. For the special case hydrants on commercial area sourced from pumps or water_tanks I would go for hydrant. Because the whole thing behaves more like a hydrant then a suction point (at least as long the tank is not empty or the wells are not exhausted). Why is a water well with an integrated pump not a hydrant: Special case of water well. And firefighters expect from a hydrant that they just have to connect there hose and get water easily. With the well with integrated pump you have to keep in mind that you have to bring a pump or a generator. I would suggest, that we discuss all stuff here, not on the wiki discussion page as long as no new participant shows up. Mailinglist is easier to use. Cheers, Moritz [1] https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_Extensions [2] https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_water_well [3] https://forum.openstreetmap.org/viewtopic.php?id=59352 [4] http://www.feuerwehr-satow.de/typo3/uploads/pics/30012011_saugstelle.jpg [5] http://home.teleos-web.de/fschubert4/gfx/Bild%20Saugstelle2.jpg [6] https://wiki.openstreetmap.org/wiki/File:French_hydrant_water_pond.jpg [7] http://www.infranken.de/storage/image/5/9/2/8/2498295_cms2image-fixedwidth-900x0_1pbCVs_61CvXH.jpg [8] https://upload.wikimedia.org/wikipedia/commons/thumb/e/e3/Zufahrt_zur_Saugstelle_der_Feuerwehr_in_Herbstein%2C_Vogelsberg%2C_Hessen_-_1.jpeg/1200px-Zufahrt_zur_Saugstelle_der_Feuerwehr_in_Herbstein%2C_Vogelsberg%2C_Hessen_-_1.jpeg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
