hydrants

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

hydrants

Viking
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] https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_3)
[2] https://taginfo.openstreetmap.org/keys/working%3Atest_date
[3] https://taginfo.openstreetmap.org/keys/working_test%3Adate

Best regards,
Alberto




---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

François Lacombe-2
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 the best

François


Le ven. 28 sept. 2018 à 23:06, Viking <[hidden email]> a écrit :
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] https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_3)
[2] https://taginfo.openstreetmap.org/keys/working%3Atest_date
[3] https://taginfo.openstreetmap.org/keys/working_test%3Adate

Best regards,
Alberto




---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

Viking
In reply to this post by Viking
>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 the best
>François

Nice to see you too, Francois :)
Well I proposed working_test:date only because it is already in use for hydrants.
On the other hand, operational_status is used more often, although operational_status:date has only 1 occurence.
Shall we go on discussion page [1]? Even Marc preferred operational status, as reported on [1].

[1] https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_Extensions_(part_3)

Best regards,
Alberto




---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

Philip Barnes
On Mon, 2018-10-01 at 23:29 +0200, Viking wrote:

> > 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 the best
> > François
>
> Nice to see you too, Francois :)
> Well I proposed working_test:date only because it is already in use
> for hydrants.
> On the other hand, operational_status is used more often, although
> operational_status:date has only 1 occurence.
> Shall we go on discussion page [1]? Even Marc preferred operational
> status, as reported on [1]. 
>
How would we verify check date, surely that is a record kept by the
fire brigade?

Phil (trigpoint)

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

Viking
In reply to this post by Viking
> 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 work in areas out of our jurisdiction.
Alberto


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

bkil
Hello,

Just a quick question, would you prefer `fire_hydrant:opening=*` or
`fire_hydrant:opening_direction=*`? The former is much easier to type,
but the latter is more self explanatory.

I see that it is present on signage in many countries.
On Wed, Oct 3, 2018 at 6:11 PM Viking <[hidden email]> wrote:

>
> > 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 work in areas out of our jurisdiction.
> Alberto
>
>
> ---
> Questa e-mail è stata controllata per individuare virus con Avast antivirus.
> https://www.avast.com/antivirus
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

19b350d2-b1b3-4edb-ad96-288ea1238eee
Maybe leverage the existing direction tag (fire_hydrant:opening:direction) ?

https://wiki.openstreetmap.org/wiki/Key:direction 



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

bkil
That sounds like a reasonable idea - I see that it is widely used.
Although it is unfortunate how much bulk it adds.

Instead of
fire_hydrant:opening=cw
fire_hydrant:opening=ccw

You need to type:
fire_hydrant:opening:direction=clockwise
fire_hydrant:opening:direction=anticlockwise

Also, because the primary usage for `direction` usually relates to
heading, you could interpret the tag as an answer to the question "in
what direction does the opening of the fire hydrant face"?

On Sat, Oct 6, 2018 at 10:27 PM OSMDoudou
<[hidden email]> wrote:

>
> Maybe leverage the existing direction tag (fire_hydrant:opening:direction) ?
>
> https://wiki.openstreetmap.org/wiki/Key:direction
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

Rich


On Sun, Oct 07, 2018 at 09:55:03PM +0200, bkil wrote:

> On Sat, Oct 6, 2018 at 10:27 PM OSMDoudou
> <[hidden email]> wrote:
> >
> > Maybe leverage the existing direction tag (fire_hydrant:opening:direction) ?
> >
> > https://wiki.openstreetmap.org/wiki/Key:direction
> >
> That sounds like a reasonable idea - I see that it is widely used.
> Although it is unfortunate how much bulk it adds.
>
> Instead of
> fire_hydrant:opening=cw
> fire_hydrant:opening=ccw
>
> You need to type:
> fire_hydrant:opening:direction=clockwise
> fire_hydrant:opening:direction=anticlockwise
>
> Also, because the primary usage for `direction` usually relates to
> heading, you could interpret the tag as an answer to the question "in
> what direction does the opening of the fire hydrant face"?

What about using the standard engineering terms:

https://en.wikipedia.org/wiki/Screw_thread#Handedness

fire_hydrant:handedness=right
fire_hydrant:handedness=left


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

bkil
Wow, that's another indirection I need to keep in my head (translating
from the circular arrow), but it's a cool idea, none the less. :-)

I'll try to invite other editors who use such tags to better
understand their viewpoint.

On Mon, Oct 8, 2018 at 12:14 AM Rich <[hidden email]> wrote:

>
>
>
> On Sun, Oct 07, 2018 at 09:55:03PM +0200, bkil wrote:
> > On Sat, Oct 6, 2018 at 10:27 PM OSMDoudou
> > <[hidden email]> wrote:
> > >
> > > Maybe leverage the existing direction tag (fire_hydrant:opening:direction) ?
> > >
> > > https://wiki.openstreetmap.org/wiki/Key:direction
> > >
> > That sounds like a reasonable idea - I see that it is widely used.
> > Although it is unfortunate how much bulk it adds.
> >
> > Instead of
> > fire_hydrant:opening=cw
> > fire_hydrant:opening=ccw
> >
> > You need to type:
> > fire_hydrant:opening:direction=clockwise
> > fire_hydrant:opening:direction=anticlockwise
> >
> > Also, because the primary usage for `direction` usually relates to
> > heading, you could interpret the tag as an answer to the question "in
> > what direction does the opening of the fire hydrant face"?
>
> What about using the standard engineering terms:
>
> https://en.wikipedia.org/wiki/Screw_thread#Handedness
>
> fire_hydrant:handedness=right
> fire_hydrant:handedness=left
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

Kevin Kenny-3
In reply to this post by Rich
On Sun, Oct 7, 2018 at 6:14 PM Rich <[hidden email]> wrote:

> > Instead of
> > fire_hydrant:opening=cw
> > fire_hydrant:opening=ccw
> >
> > You need to type:
> > fire_hydrant:opening:direction=clockwise
> > fire_hydrant:opening:direction=anticlockwise
> >
> > Also, because the primary usage for `direction` usually relates to
> > heading, you could interpret the tag as an answer to the question "in
> > what direction does the opening of the fire hydrant face"?
>
> What about using the standard engineering terms:
>
> https://en.wikipedia.org/wiki/Screw_thread#Handedness
>
> fire_hydrant:handedness=right
> fire_hydrant:handedness=left

With a typical hydrant valve, a right-hand screw thread becomes 'turn left to open' and vice versa.

One hopes that the caps and the valve(s) both open in the same direction, but there are lots of strange old hydrants about. Most of the ones near me have markings like

↶ OPEN

or

OPEN ↷

on both the caps and the bonnet.



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

Viking
In reply to this post by Viking
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 time in this project.

Anyway, as a firefighter, I have to say that the opening direction is a marginal tag for firefighting purposes, because you don't need to know this information to choose on a map which hydrant to use to refill the fire engine.
But if you still want to add this information, we need to refine it, for this reason discussion is important.

The use of handedness=right / left is prone to error.
Normally on hydrants it is indicated the direction of opening and usually it is counterclockwise. But technically these hydrants' valves have right-hand threads (right handedness): you turn it clockwise to tighten the valve and close the hydrant.
So if you read on a hydrant the counterclockwise opening direction, you should tag it with handedness=right. This creates confusion to a normal mapper.

direction=clockwise/counterclockwise has similiar problem: you can intend it as the opening direction or as the thread direction (closing direction).

On the other hand, fire_hydrant:opening=cw / ccw is not self-explanatory, because someone can intend it as the number of openings (couplings).

Personally I would not add this tag at all.
But, if you still want to add this information, I think that something like:

opening:direction=clockwise / counterclockwise

As we did for most of the tags in [0], I would not use fire_hydrant: prefix because we want a slim database and because  opening:direction=* is (or can be) used for other objects, as doors, taps, etc.

[0] https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_hydrant
[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_2)

Best regards,
Alberto


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

Paul Allen
On Tue, Oct 9, 2018 at 9:34 PM Viking <[hidden email]> wrote:

As we did for most of the tags in [0], I would not use fire_hydrant: prefix because we want a slim
database and because  opening:direction=* is (or can be) used for other objects, as doors, taps, etc.

There are differing viewpoints on this.

1) Minimize database keys by applying them as widely as possible.  So opening:direction applies to
doors, taps, fire hydrants, etc.  Database designers might think this way, as might most ordinary
mappers and most programmers.

2) Don't re-use keys in this way because you end up with different sets of values that apply in
different situations.  People who program map editors tend to think this way.  Each time you use
opening:direction for a different type of object the programmer has to special-case the set of possible
values based on the associated values in order to populate drop-downs.  If you're mapping a
tap you want the choice of opening:direction to be limited to clockwise and counterclockwise and
not be confused by also seeing inwards and outwards; but for doors you want inwards and outwards
but not clockwise and counterclockwise (unless it's a rotating door).

I can see merits in both viewpoints.  The people who write map editors tend to win these arguments
because most mappers choose from what the editor presents to them. :)

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

François Lacombe-2
The question about the opening direction should be propagated to this draft proposal regarding pipeline valves

I thought about turn_to_close=clockwise / anticlockwise
Whatever the final answer will be, this definitely have to be the same key and values on both fire hydrants and any kind of pipeline valves.

The proposal can change at anytime until RFC.
All the best

François

Le mar. 9 oct. 2018 à 23:13, Paul Allen <[hidden email]> a écrit :
On Tue, Oct 9, 2018 at 9:34 PM Viking <[hidden email]> wrote:

As we did for most of the tags in [0], I would not use fire_hydrant: prefix because we want a slim
database and because  opening:direction=* is (or can be) used for other objects, as doors, taps, etc.

There are differing viewpoints on this.

1) Minimize database keys by applying them as widely as possible.  So opening:direction applies to
doors, taps, fire hydrants, etc.  Database designers might think this way, as might most ordinary
mappers and most programmers.

2) Don't re-use keys in this way because you end up with different sets of values that apply in
different situations.  People who program map editors tend to think this way.  Each time you use
opening:direction for a different type of object the programmer has to special-case the set of possible
values based on the associated values in order to populate drop-downs.  If you're mapping a
tap you want the choice of opening:direction to be limited to clockwise and counterclockwise and
not be confused by also seeing inwards and outwards; but for doors you want inwards and outwards
but not clockwise and counterclockwise (unless it's a rotating door).

I can see merits in both viewpoints.  The people who write map editors tend to win these arguments
because most mappers choose from what the editor presents to them. :)

--
Paul

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

Paul Allen
On Tue, Oct 9, 2018 at 11:31 PM François Lacombe <[hidden email]> wrote:
The question about the opening direction should be propagated to this draft proposal regarding pipeline valves

I thought about turn_to_close=clockwise / anticlockwise
Whatever the final answer will be, this definitely have to be the same key and values on both fire hydrants and any kind of pipeline valves.

Those are both valves operated with rotary motions.  No problem using the same key/values for
both.  Or for any other kind of valve operated with a rotary motion.  The problem comes when, as
somebody suggested, applying it to doors too, so then the editor preset would have to be context
sensitive.  Your choice of key prevents it being applied to doors.

A less-obvious problem is applying it to taps.  The taps in my home are rotary.  But I've
encountered taps operated with levers and taps operated with push buttons.  That is
probably not the case with fire hydrants.  So taps would have to be dealt with by another key,
otherwise the authors of editors would be unhappy.  Not that we're likely to map taps until
nanomapping becomes popular, but somebody suggested it.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

François Lacombe-2
Hi,

Le mer. 10 oct. 2018 à 00:45, Paul Allen <[hidden email]> a écrit :
On Tue, Oct 9, 2018 at 11:31 PM François Lacombe <[hidden email]> wrote:
The question about the opening direction should be propagated to this draft proposal regarding pipeline valves

I thought about turn_to_close=clockwise / anticlockwise
Whatever the final answer will be, this definitely have to be the same key and values on both fire hydrants and any kind of pipeline valves.

Those are both valves operated with rotary motions.  No problem using the same key/values for
both.  Or for any other kind of valve operated with a rotary motion.  The problem comes when, as
somebody suggested, applying it to doors too, so then the editor preset would have to be context
sensitive.  Your choice of key prevents it being applied to doors..
It depends which doors, and mainly depend of the actuator associated with the valve
Here is a door valve and a wheel has to be handled to open or close.

It pretty obvious that when no rotation is needed to open or close any valve, tap or door, then keys like turn_to_close won't be appropriate nor used.
On valves proposal, turn_to_close will only be available in association with certain handle=* values (certainly handle=wheel).
handle=* can also be used on fire hydrant if needed.
 
Not that we're likely to map taps until
nanomapping becomes popular, but somebody suggested it.

handle=* solves the problem.

All the best

François

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

bkil
In reply to this post by François Lacombe-2
Do note that fire hydrant plates depict opening direction, so if we
would need to store direction to close, a mapper would yet again need
to do mental work, that is not error prone and confusing.
On Wed, Oct 10, 2018 at 12:31 AM François Lacombe
<[hidden email]> wrote:

>
> The question about the opening direction should be propagated to this draft proposal regarding pipeline valves
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pipeline_valves_proposal
>
> I thought about turn_to_close=clockwise / anticlockwise
> Whatever the final answer will be, this definitely have to be the same key and values on both fire hydrants and any kind of pipeline valves.
>
> The proposal can change at anytime until RFC.
> All the best
>
> François
>
> Le mar. 9 oct. 2018 à 23:13, Paul Allen <[hidden email]> a écrit :
>>
>> On Tue, Oct 9, 2018 at 9:34 PM Viking <[hidden email]> wrote:
>>>
>>>
>>> As we did for most of the tags in [0], I would not use fire_hydrant: prefix because we want a slim
>>>
>>> database and because  opening:direction=* is (or can be) used for other objects, as doors, taps, etc.
>>
>>
>> There are differing viewpoints on this.
>>
>> 1) Minimize database keys by applying them as widely as possible.  So opening:direction applies to
>> doors, taps, fire hydrants, etc.  Database designers might think this way, as might most ordinary
>> mappers and most programmers.
>>
>> 2) Don't re-use keys in this way because you end up with different sets of values that apply in
>> different situations.  People who program map editors tend to think this way.  Each time you use
>> opening:direction for a different type of object the programmer has to special-case the set of possible
>> values based on the associated values in order to populate drop-downs.  If you're mapping a
>> tap you want the choice of opening:direction to be limited to clockwise and counterclockwise and
>> not be confused by also seeing inwards and outwards; but for doors you want inwards and outwards
>> but not clockwise and counterclockwise (unless it's a rotating door).
>>
>> I can see merits in both viewpoints.  The people who write map editors tend to win these arguments
>> because most mappers choose from what the editor presents to them. :)
>>
>> --
>> Paul
>>
>> _______________________________________________
>> Tagging mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: hydrants

bkil
In reply to this post by Viking
Yes, it was me who added that key to the wiki page, because it was
mentioned in one of our Hungarian documents some years ago and also I
wanted to use it.

I admit to my error in not noticing the latest proposals earlier. I've
just recently joined this list and I've specifically asked this here
in order to correct my error. I volunteer to fix previous tags with
whatever we come up with as a replacement.

In my defense, do note that the proposal process is only one way to
start using new tags:

https://wiki.openstreetmap.org/wiki/Any_tags_you_like
https://wiki.openstreetmap.org/wiki/Just_Map
https://wiki.openstreetmap.org/wiki/Good_Practice#Document_your_custom-tags
https://wiki.openstreetmap.org/wiki/User:Joto/How_to_invent_tags
https://wiki.openstreetmap.org/wiki/Proposal_process
https://wiki.openstreetmap.org/wiki/New_Features

Of course, I agree that if a proposal process is underway in a
specific area, it is much more productive to pool our focus to the
given process instead of doing ad hoc extensions in parallel.

I would definitely tag this property, because it is possible to break
a hydrant with the huge keys that are used to open it if it is rusty
and you are forcing it in the wrong direction. In Hungary, I've seen
both opening directions fairly often, though I don't have exact stats
as of now. Official fire fighters here have their own (closed)
database of hydrant here and the vehicles also store a great amount of
water so OSM is not useful to them in this aspect. Pressure is not
indicated on plates, only diameter, but as that is not correlated
reliable with pressure, they usually do not decide based on that, so
this property is not useful either. I think that opening direction is
the more useful property of the two, though the local community maps
all data from the plates.

I don't have strong preferences for the exact key, but in the value
part, I would like to see something that mirrors the plate that is
depicting either clockwise or counterclockwise. I don't have a strong
preference regarding abbreviation, although I guess it would be more
accessible when typed in fully.

Regards

On Tue, Oct 9, 2018 at 10:34 PM Viking <[hidden email]> wrote:

>
> 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 time in this project.
>
> Anyway, as a firefighter, I have to say that the opening direction is a marginal tag for firefighting purposes, because you don't need to know this information to choose on a map which hydrant to use to refill the fire engine.
> But if you still want to add this information, we need to refine it, for this reason discussion is important.
>
> The use of handedness=right / left is prone to error.
> Normally on hydrants it is indicated the direction of opening and usually it is counterclockwise. But technically these hydrants' valves have right-hand threads (right handedness): you turn it clockwise to tighten the valve and close the hydrant.
> So if you read on a hydrant the counterclockwise opening direction, you should tag it with handedness=right. This creates confusion to a normal mapper.
>
> direction=clockwise/counterclockwise has similiar problem: you can intend it as the opening direction or as the thread direction (closing direction).
>
> On the other hand, fire_hydrant:opening=cw / ccw is not self-explanatory, because someone can intend it as the number of openings (couplings).
>
> Personally I would not add this tag at all.
> But, if you still want to add this information, I think that something like:
>
> opening:direction=clockwise / counterclockwise
>
> As we did for most of the tags in [0], I would not use fire_hydrant: prefix because we want a slim database and because  opening:direction=* is (or can be) used for other objects, as doors, taps, etc.
>
> [0] https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_hydrant
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_2)
>
> Best regards,
> Alberto
>
>
> ---
> Questa e-mail è stata controllata per individuare virus con Avast antivirus.
> https://www.avast.com/antivirus
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

simply documenting tags WAS Re: hydrants

dieterdreist


sent from a phone

On 10. Oct 2018, at 08:07, bkil <[hidden email]> wrote:



I believe this paragraph needs some clarification, currently it reads “When you use tags yourself that aren't on map features, give other mappers a chance to understand (and maybe adopt) them by documenting them in the wiki.”

Yes, it is a good thing to document custom tags, but the question is where in the wiki should you put a tag that is not (yet) established.

Some tags work better than others, sometimes there are already alternative tagging methods established (and you might not be aware of it), simply adding a feature page for a tag which isn’t generally used, wasn’t discussed with the community and may be problematic is not a good idea. 

People also document tags on their user pages, and this is much better as the things are still searchable but there isn’t the risk of mistaking them for well established tags. Another way to make this clear is setting up a proposal page for documentation. A lot of tags have become established simply because there was a proposal and people were adopting it in their mapping (no formal voting).

Map feature pages are for the documentation of established tags, I hope we can agree on this?

IMHO we should clarify that documenting ad hoc tags in the wiki (link above) means either putting this documentation in your user space of the wiki, or in the proposal space.


What do you think?


Cheers,
Martin 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: simply documenting tags WAS Re: hydrants

bkil
I agree that similar to Wikipedia, we shouldn't put random, incorrect
or misleading stuff in the main namespace of the OSM wiki.

However, I view it as a harsh restriction to only allow documenting of
established tags the the main namespace. The main tag wiki pages are
cross linked from taginfo.

In the wiki pages I edit, I usually put less common attributes in
separate sections with extra warnings to avoid mistakes. Also, if you
create respective subpages of each property with the standard template
containing taginfo statistics and status enum, it becomes obvious how
established each property is.

We should of course have a clear and friendly process of handling
clashes - so it should not happen that two users would like to
advocate their two incompatible tagging scheme on the same page,
leading to edit wars. Two separate proposals need to be opened in this
case with strong-consensus voting for both. (However, in the case of
hydrant opening direction for example, I've checked beforehand and
validated that no applicable alternative scheme or proposal exists
other than the one noted and mention on a Hungarian page some years
back.)

The problem of (complicated) proposal pages is that they "rot" easily.
RFC and voting sometimes seems to be stuck. Some downvoted proposals
start to be taken up by mappers some years later (with an unfixed,
partially buggy/broken schema). Surely the correct life cycle of a
proposal should be that if it is dismissed, the proposer should
immediately clone the wiki page, increment a version number, correct
the problems highlighted by the voters and resubmit for RFC/voting.
Unfortunately, most of the volunteers seem to be overwhelmed by this
process and give up usually after the first attempt.

I sometimes take up the task of documenting random established, almost
established or emerging things I encounter in taginfo that I deem
useful for the community (or me). Why should I put these under my own
namespace? It would leave the impression that I "want" to do something
with the outlined tagging or that I want to "own" the tag. However, in
most of these cases, I simply want to be done with it and move on to
another tag or just be mapping instead of submitting proposals for
others. I did submit one (two) recently just to get the hang of it,
but I feel already that it takes up a lot of energy for little
"return". I feel that if I document trending clear-cut tags according
to my best knowledge, someone else can take up from there and improve
it (submit for RFC/Proposal).

This should be the ideal mechanism of the wisdom of the crowds - no
single person should bear an unreasonable burden, unless of course
that person finds enjoyment in this.

Of course this is only my personal view on the issue without much
context - I'm open for other points of view if others would like to
share.
On Wed, Oct 10, 2018 at 9:39 AM Martin Koppenhoefer
<[hidden email]> wrote:

>
>
>
> sent from a phone
>
> On 10. Oct 2018, at 08:07, bkil <[hidden email]> wrote:
>
> https://wiki.openstreetmap.org/wiki/Good_Practice#Document_your_custom-tags
>
>
>
> I believe this paragraph needs some clarification, currently it reads “When you use tags yourself that aren't on map features, give other mappers a chance to understand (and maybe adopt) them by documenting them in the wiki.”
>
> Yes, it is a good thing to document custom tags, but the question is where in the wiki should you put a tag that is not (yet) established.
>
> Some tags work better than others, sometimes there are already alternative tagging methods established (and you might not be aware of it), simply adding a feature page for a tag which isn’t generally used, wasn’t discussed with the community and may be problematic is not a good idea.
>
> People also document tags on their user pages, and this is much better as the things are still searchable but there isn’t the risk of mistaking them for well established tags. Another way to make this clear is setting up a proposal page for documentation. A lot of tags have become established simply because there was a proposal and people were adopting it in their mapping (no formal voting).
>
> Map feature pages are for the documentation of established tags, I hope we can agree on this?
>
> IMHO we should clarify that documenting ad hoc tags in the wiki (link above) means either putting this documentation in your user space of the wiki, or in the proposal space.
>
>
> What do you think?
>
>
> Cheers,
> Martin
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12