Re: [Tagging] Clarification of fire_hydrant:diameter

I've fixed fire_hydrant:diameter legend on wiki page. > If you ever need pictures of those signs, please contact me, I have plenty of > them, but I have to look them up. Marc, and anyone that has pictures of these signs, can you give them to us, to insert them on wiki page? Thank you, Alberto

Re: [Tagging] Clarification of fire_hydrant:diameter

Sorry for multiple emails... Anyway, the situation is this: 1) The water main diameter going along the street and (among other things) feed hydrants => fire_hydrant:diameter, according to the original meaning of this tag. It is generally acquired from signboards. 2) The water connecting pipe

[Tagging] R: Tagging Digest, Vol 112, Issue 180

Ok, so the situation is this: 1) The water main diameter going along the street and (among other things) feed hydrants => fire_hydrant:diameter, according to the original meaning of this tag. It is generally acquired from signboards. 2) The water connecting pipe between the water main and the

Re: [Tagging] Clarification of fire_hydrant:diameter

--- 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] Clarification of fire_hydrant:diameter

Hello, as pointed out here [1], we need to clarify the meaning of fire_hydrant:diameter=*. We need to know which was the original meaning of this tag, because we probably misunderstood it when we rewrote fire hydrant page. In Italy fire hydrant signboard doesn't report any diameter: the only

Re: [Tagging] hydrants

Bkill, at least in Italy hydrants are strong enough that it is impossible to brake them using only its key and human force. Anyway, if you think this tag is usefull, ok, map it. I'm sure that also in Hungary OSM could help firefighters if hydrants mapping will become capillar. We in Italy have

Re: [Tagging] hydrants

Bkill, you added fire_hydrant:opening to wiki page [0], but you should have discussed it here and/or in discussion page before. We did many efforts to widely discuss fire hydrant extensions [1] and finally approve them: you should at least discuss your proposal with people who spent so much

Re: [Tagging] hydrants

> How would we verify check date, surely that is a record kept by the fire > brigade? > > Phil (trigpoint) Hi Phil, well, operational_status:date can be inserted directly by firefighters. I am a firfighter and we are interested in having this information online, expecially when we are sent to

Re: [Tagging] hydrants

>Hi Alberto, >Nice to see you back there :) >Regarding check_date, I'd go in favor of operational_status:date. >working:* is too specific to fully functional hydrants, what about disused or >dry ones? >Then operational_status is a more complete solution to give state and >associated date. >All

[Tagging] hydrants

Hello, I would like to continue with fire hydrants' new tags [1]. Instead of the contested check_date=*, what do you think of working:test_date=* [2] or working_test:date=* [3], both already in use? Which syntax do you prefer? [1]

[Tagging] R: Proposed features - Voting - Hydropower waterways

Francois, I like your proposal and I apologize because I hadn't time to partecipate to discussion. Anyway, I have a question: in case of a culvert, you would still use tunnel=culvert? Because also a culvert is a (short) flooded tunnel, and consequently tunnel=flooded could be used. Alberto

Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))

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

Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))

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

Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))

> check_date tag is very imprecise. some use it to indicate when they checked > the object on the ground without knowing what was checked. > others use it to check the date of objects under construction in external > sources without verification of the ground. > I had proposed that we use

[Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))

I think we can go on refining hydrant tags, so I formally call a Request For Comments on this page [1]. I remember that someone had pictures of different wrenches: can he/she add them to the table on [1]? [1]

Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions (part 2))

Finally the proposal [1] has been approved. Thank you to all people who worked on this project. As soon as possible we will update fire hydrant wiki page. Then we can go on with part 3... :) [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_2) Best regards

[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) Thank you Best regards Alberto --- Questa e-mail è stata controllata per individuare virus con

Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 2)

> 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 ;) I answered every comment in discussion page. The aim now is to keep the focus on new tags. About

Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 2))

It seems that nobody has anything to comment anymore on hydrants new proposal [1]. Moritz, did you contact individually people who opposed the previous proposal? [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_2) Alberto --- Questa e-mail è stata

[Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 2))

I send a Request For Comments for this revisioned version [1] of the fire hydrant extensions proposal. We tried to listen to all objections to the original proposal. We explicitly ask the people who opposed it, if they have any more concerns. Please leave comments on Discussion Page, because many

Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions)

I've tried to summarize post-vote conclusions here: Fire Hydrant Extensions (part 2) [1] Now, we can use it as it is and apply these changes to hydrant wiki page, or change it, or vote it again. Then we can go on and discuss/vote Fire Hydrant Extensions (part 3) [2]. Finally, if we want, we can

Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions)

Voting ended with 21 "no" and 28 "yes", and at least one that would change "no" to "yes" if we redefine gallons. Now we have to do decide what to do. Is this enough to delcare it approved? Anyway some issues can be easily solved: fire_hydrant:class=* can become fire_hydrant:awwa_class=* gpm can

[Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions)

I really don't understand why so many people oppose this proposal [1] without ever having participated in the discussions that lasted for months. We did many efforts to reach this compromise that seems a good solution for firefighters' needs, and now people are opposing to it whithout

[Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions)

I've fixed page layout without changing anything in the proposal. I request you to vote this proposal [1]. [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions Thank you Best regards Alberto --- Questa e-mail è stata controllata per individuare virus con Avast

Re: [Tagging] Fire hydrants split

> According to the huge number of affected nodes (~300k for > fire_hydrant:position=*). 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. It seems we

[Tagging] Fire hydrants split

I've splitted the proposal in [1] and [2], as requested. Please help me to check them. In Italian mailing list, it has been proposed the tag cap:wrench=*, because often the wrench needed to open the caps is different from the wrench that opens the hydrant itself. I've added this tag to [2] with

Re: [Tagging] Fire hydrants vs suction_point

> I don't like adding more and more tag > but IMHO 1 key = 1 function is much simpler. +1 The volume must be ONLY in water_volume=* and not in implicitly given by another tag. It must br clear enough to be understood by an occasional mapper. More complexity is when a piece of information is

Re: [Tagging] Fire hydrants vs suction_point

> For water wells min and max_suction_head is not suitable. There we > should introduce > suction_head=# -1 this will add another tag >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,

Re: [Tagging] Fire_hydrant: tagging namespace documentation

>> 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 Already done.

Re: [Tagging] Fire_hydrant: tagging namespace documentation

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? [0] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_well Alberto --- Questa e-mail è stata controllata per

Re: [Tagging] Fire_hydrant: tagging namespace documentation

> it is useless to add country=CH to all hydrant in Switzerland or say > that any object of a city is in the city. apps/tools need to improve > geolocation information they provide through existing boundary. +1 > Maybe the key "street" could have a value (only) when a hydrant is > between 2

Re: [Tagging] Fire hydrants vs suction_point

> water_source=groundwater +1 > water_level=6 (in meters) ? > I mean the distance between the ground level and the > water level. E.g. the water is 3 m below ground. Suction head is the right word in hydraulics. > I think the water level will drop as large amounts of water are drawn off, so

Re: [Tagging] Fire hydrants vs suction_point

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

Re: [Tagging] Fire hydrants vs suction_point

If we want to remove fire_hydrant: namespace, what's about transform fire_hydrant:diameter=# in diameter=# ? It is already documented its use with hydrants: [0] And about fire_hydrant:style=*, fire_hydrant:count=# and fire_hydrant:class=* ? I would keep these tags as they are now. [0]

Re: [Tagging] Fire hydrants vs suction_point

Hi Walter. > when you say "hydrant", you meen "emergency=fire_hydrant" ok? Yes. > and the substag fire_hydrant:type will specify the subtypes > (underground, pillar, ...) ok? Currently we think to put the subtype in fire_hydrant=underground/pillar... instead of using

Re: [Tagging] Fire hydrants vs suction_point

@Francois rating:water -1. It is not intuitive. Against simplicity that we are trying to achieve. @Marc flow_rate should be used for the nominal flow capacity. This is enough for firefightening purposes and it is the only data normally declared by water companies. For example [0] specifies

Re: [Tagging] Fire hydrants vs suction_point

Hi, I've been away for a week. I'll try to read all your comments. First of all: Dry riser is a device. Suction point another one. Hydrant another one. Three different things, three different tags. Ok? Then I agree to remove the use of : where possible. The word "capacity" is in most cases

Re: [Tagging] Fire hydrants vs suction_point

> Umm reflective is not a colour. In my understanding, reflective:colour should be the colour of reflective stripes, if present. > What about tagging both as fire_hydrant:type=pillar > and something like > pillar:type=dry_barrel|wet_barrel +1 Best regards Alberto --- Questa e-mail è stata

Re: [Tagging] Fire hydrants vs suction_point

> colour:bonnet colour:cap colour:reflective seems for me to be in the reverse > order the colour of a building is building:colour not colour:building the > same exist with roof:colour light:colour ... +1 Fixed. > survey:date is the date of a survey (someone was there) not a functional >

Re: [Tagging] Fire hydrants vs suction_point

Hi all. I'm a firefighter too. Nice to meet you. In the case of commercial/industrial local water networks fed by pumps, we all agree to use emergency=fire_hydrant. Because externally (at least here in Italy) they are not distinguishable from hydrants fed by public mains and they have the same

Re: [Tagging] Fire hydrants vs suction_point

>My point is suction points and fire hydrant are different but compatible >things, as follow : >emergency=suction_point is a prefered place where to pump water in a river >emergency=fire_hydrant >is a kind of device which may or not be present in places like suction points >but in a large

Re: [Tagging] fire hydrants

> in the section on the AWWA color scheme, i changed "tops" to "bonnet" as > bonnet is the correct technical term for the "top" of a hydrant. do we > want > to add a definition that makes this clear? Sure, add a definition for bonnet and caps, if you can. Thanks to everybody. Alberto ---

Re: [Tagging] fire hydrants

Hello. After two weeks on holiday, I'm back to discuss on fire hydrants proposal. I've updated the page [1] according to last comments about fire_hydrant:couplings_type and fire_hydrant:couplings_size. If you think it's ok, I will go on putting it on vote. Best regards Alberto [1]

Re: [Tagging] fire hydrants

> * Can I or would you add an example subsection with pictures giving at least > the different situations depicted with fire_hydrant:type key ? Of course you can, Francois: any contriubution is welcome. > With fire_hydrant:couplings, you have to guess what this means. > Without reading the

Re: [Tagging] fire hydrants

I've updated the page [1], according to François' suggestions. Please check it. Alberto [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions --- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus

[Tagging] Feature Proposal - RFC - Fire Hydrant Extensions

Definition: additional information for emergency=fire_hydrant I officially send a Request For Comments on Fire Hydrant Extensions [1], so we can go on with the proposal process. Thank you. Alberto [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions --- Questa

Re: [Tagging] fire hydrants

> for flow_capacity, should m3/h be preferred instead of lpm ? Normally, the best unit for fire purposes is lpm (or gpm), because you can easily determine how many minutes it takes to refill e.g. a 4500 litres fire engine. Also fire pumps specs are in lpm or gpm. > fire_hydrant:coupling_type

Re: [Tagging] fire hydrants

I've updated the page [1] with the new tags that we are discussing in this list. Please check the page and update it (for example with valid coupling_type values). The aim is to have all the new tags in one page. And when we will be ready, insert them in the official fire hydrant page. We could

Re: [Tagging] fire hydrants

Ok Robert, I think that if in Austria firemen use letters for diameters, we should allow letters in OSM too. By the way, do you think that in an hydrant all couplings follow the same standard (UNI, or Storz, or...)? I mean in fire_hydrant:coupling_type is a single value enough to describe all

Re: [Tagging] fire hydrants

> in OsmHydrant [1] there is already fire_hydrant:coupling_type with various > values from Storz to Barcelona > (https://taginfo.openstreetmap.org/keys/fire_hydrant:coupling_type). Then > there is fire_hydrant:couplings to complement that, describing the > actual > connectors:

Re: [Tagging] fire hydrants

I've proposed the subtag fire_hydrant:outlets=#;#;# in hydrants discussion page [1]. If nobody opposes this proposal, I will add this subtag to hydrants page. Alberto [1] https://wiki.openstreetmap.org/wiki/Talk:Tag:emergency%3Dfire_hydrant#fire_hydrant:outlets.3D.23.3B.23.3B.23 --- Questa

Re: [Tagging] fire hydrants

I've changed Italian and English hydrants wiki page for a more detailed description on diameter: please check them. And do you think that fire_hydrant:outlets=#;#;# is acceptable? Alberto --- Questa e-mail è stata controllata per individuare virus con Avast antivirus.

Re: [Tagging] fire hydrants

Ok, so there is an error in Italian hydrants wiki page. I will fix it. At this point I would propose a new tag for the number and the diameter of the threaded outlet. For an hydrant with two 45 mm outlets and one 100 mm outlet: fire_hydrant:outlets=45;45;100 Or do you have better proposals?

[Tagging] fire hydrants

Hi. I have a question about this wiki definition: fire_hydrant:diameter=# (optional, in mm, inches or letters. This is the diameter of the water main feeding the hydrant. ) Is this the diameter of the underground pipe or the

Re: [Tagging] Beef fattening stations

I've found this proposal [1] landuse=animal_keeping. It has already 1590 recurrences. Do you think it is applicable? It would be: landuse=animal_keeping animal_keeping=cattle animal_keeping:type=feedlot [1] https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Danimal_keeping Cheers

Re: [Tagging] Beef fattening stations

I've read [1], [2] and [3], and for me produce=cattle is ok. Anyway, I've found also this wiki page [4] that proposes farming_system=feedlot. But there are only 9 recurrences [5] of it, and I think that farmland=feedlot is better. So at the end: landuse=farmland farmland=feedlot produce=cattle

Re: [Tagging] Beef fattening stations

Ok, do you prefer a completely new tag or to add subtags to animal_breeding? In case of a new tag, it could be: amenity=animal_fattening animal_fattening=bovine or what else instead of amenity? In any case we should write a wiki page about this. Cheers Alberto --- Questa e-mail è stata

Re: [Tagging] Beef fattening stations

Animal_breeding was discussed and voted here [1] Martin, even you approved that proposal, you are the second voter! Didn't you remember? :-) It was also discussed on tagging mailing list here [2] 189 tags are not few for a type of structure that almost nobody maps. Man_made=cowshed doesn't

Re: [Tagging] Beef fattening stations

Hi. To be consistent with the approved and already used tags amenity=animal_breeding [1], amenity=animal_shelter [2] and amenity=animal_boarding [3], what do you think about: amenity=animal_breeding animal_breeding:feedlot=cow OR animal_breeding:concentrated_animal_feeding_operation=cow It

Re: [Tagging] surface earth vs ground vs dirt

Well, then we need a more precise definition on the wiki. It is confusing to have "probably very similar to..." and "duplicate of...". You admit that "the meaning of these terms varies widely depending on who you ask and which country you're mapping": this is against the interpretation and

[Tagging] surface earth vs ground vs dirt

Hello. What's about bringing surface=ground, surface=dirt and surface=earth to the unique and most used tag surface=ground, as discussed here [1]? Too few distinctions, too much confusion. And it has been already discussed in this mailing list [2]. So, should we start a votation, or is there a