Proposal talk:Fence attributes

Balustrade

I think balustrade is kind of fence so may be fence:type=balustrade --Kendzi 21:40, 30 November 2011 (UTC)

Tagging

Why "barbed_wire" and "barbed_tape" are without "barrier:" namespace? --Surly 06:07, 29 July 2010 (UTC)

I have a terrible urge to separate fence:type from fence:material. As such, I do not use type=metal, since it overlaps with type=bars (bars are mostly metal anyway). Instead I'm currently using type=grate for any metal fences that can be seen through, while material for them may range from stainless steel to cast iron. Plate (mostly material=steel, but it can be anything from concrete plates to synthetic materials) and plank (mostly material=wood, but OSB and plastic are as good as any) can be used as types, too. I also combine fence=retaining_wall and type=... to describe railings on top of the wall if there are any. Kilkenni (talk) 22:48, 25 January 2014 (UTC)

Progress

I am waiting for the voting to start:). There are already lots of objects with this tag (but also tags like fence_type which should be replaced). --Scai 17:27, 14 August 2010 (BST)

Well, right now I don't have the time to deal with all the discussion that will be necessary for a proposal to be accepted. (I'm busy writing software that will, among other things, actually render fence types!) Do you want me to transfer the proposal to you? According to customary procedure, you'd still need an RFC phase before the vote, though. --Tordanik 20:59, 15 August 2010 (BST)

The proposal is already good enough. No long discussion needed. So let's mark the beginning of the RFC phase and start the two-week countdown! --Surly

Sounds good :). Tordanik, I also don't have much time for this at the moment. So either just start the RFC phase as Surly suggested, or postpone the procedure. --Scai 10:09, 16 August 2010 (BST)

What happened to this proposal? As for me I find it very good. --Jeawrong 15:28, 04 Maj 2013 (BST)

Well, as I said I didn't really have the time for it and no one else wanted to pick it up. Meanwhile, the "competition" didn't bother with proposals and simply created a key page. So fence_type is now used a lot more often. Therefore it may now be the better idea to just merge the missing values into fence_type. --Tordanik 18:54, 4 May 2013 (UTC)

No, you can't integrate a fine-grained tagging scheme into a single key. As the fence_type=* page correctly said for many years: "Currently, this tag mixes function, construction type and material of fences." That means that fence_type is a mess and needs to be replaced, better late then never! It has been a pain for everyone: mappers, application developers, and data consumers. Has that key ever been used for anything? I don't think so. Mappers keep selecting values in the selection box provided by the editor, but nobody can ever use that garbage. --Fkv (talk) 10:22, 7 March 2022 (UTC)

Better key for Organisation?

'type' leads to many things being included and mixed in the values. Better to state what is meant. there is a property key for material - so that should be used for wood/metal/etc. fence:structure might be good for the physical aspect? Warin61 (talk) 01:29, 12 March 2019 (UTC)

Well not only fence:type=* itself. After a year (and indeed 7 years), other keys are still very mixed up. A simple fence=* should be suggested for general/undetermined/unspecified use, instead of either the ancient-style fence_type=* and poor-style fence:type=* -- Kovposch (talk) 11:17, 9 May 2020 (UTC)

fence:material

My question is whether we really need fence:material=*, als for barrier=fance it would be exactly the same as using the existing material=* key?--Lukas458 (talk) 10:50, 9 May 2020 (UTC)

Depends on the intention. The need to specify it's the fence's material exists when multiple "barrier" are represented on 1 object (ie fence on wall etc), and barrier=* is often tagged together with the enclosing area (eg landuse=*, amenity=*, man_made=*). It should be optional. -- Kovposch (talk) 11:14, 9 May 2020 (UTC)

For a fence on a wall, make 2 obects with different layer=*. Also for a fence and an area, separate objects are usually a good idea (you can use a multipolygon if the fence has lots of nodes and you are lazy), as otherwise applications have to guess which attributes (name etc.) belong to the area and which belong to the fence. --Fkv (talk) 10:22, 7 March 2022 (UTC)

Good point. I favor material=* over fence:material=* because I don't see how fence materials are supposed to differ from other materials. Wood is wood, iron is iron. For barbed wire, spikes etc, we can use another tag, which is needed anyway according to the proposal (barrier:barbed_wire/barbed_tape). --Fkv (talk) 10:22, 7 March 2022 (UTC)

Barb Wire

Please don't spread that information over multiple tags. Add one single key such as fence:barb=* (I'm insure about the key name!). Then replace fence:barbed_wire=yes with fence:barb=wire, fence:barbed_tape=yes with fence:barb=tape, fence:material=barbed_wire with fence:material=steel + fence:barb=wire, and fence:material=barbed_wire with ence:material=steel + fence:barb=tape. --Fkv (talk) 10:22, 7 March 2022 (UTC)

Construction

"fence:type is a description of the construction type of the fence." - Then why don't we call it fence:construction=* ? fence:type is a nomen dubium and conflicts with existing, messy usage of that tag. --Fkv (talk) 10:22, 7 March 2022 (UTC)

fence:function

I like that tag. Please add more values in the proposal. E.g. a value for "keep trespassers outside private property", a value "keep prisoners inside", a value for "keep cattle, horses etc. from leaving their pasture", a value for "keep game (deers) inside a hunting district", and a value for "protect people from falling over a brink". For the latter, tagging has been a mess so far, with at least 4 equivalent tagging methods: barrier=fence + fence_type=railing, barrier=railing, barrier=handrail and barrier=guard_rail. --Fkv (talk) 10:22, 7 March 2022 (UTC)

Transition plan

I assume this new key will replace Key:fence_type. What I don't see in the proposal is the planning for the transition to this new label. I feel confusion in the values that are given to the attributes, for example, having fence:type=metal does not make sense to me, since it is going to have a fence:material=metal tag. In the fence:type=*, the fence should not be defined by the type of material and we should not define the fence:material=* by the type, as is the case of chain_link. I think the proposal needs to be polished to be able to vote on it. - Meme (talk) 05:23, 4 November 2020 (UTC)

There is no transition plan because I wrote this proposal in 2010 when fence_type wasn't exactly common yet. As noted in #Progress, I didn't have the time to continue working on the proposal. --Tordanik 20:39, 29 November 2020 (UTC)

Still no transition plan needed. Transition will start automatically when editors and validators nag about fence:type as being "deprecated", and Maproullette adds a so-called challenge. --Fkv (talk) 10:22, 7 March 2022 (UTC)