Klaphek barrier=gate of anders benoemen?

Klaphek heeft een eigen wikipedia pagina.
De hekken zien we veelal bij afrastering van wild of vee, voornamelijk in de houten uitvoering.

Eigenschappen:
Schuin geplaatst, angle.
Scharnieren, hinged.
Enkelzijdig, single.
Materiaal hout, wood
Door zwaartekracht dicht, gravity
Zelf dichtgaand, self closing

Zo was ik vanavond aan het kijken naar buitenlandse varianten.
Met bovenstaande engelse woorden.
Veelal in de scharnier (hinge) verwerkte zwaartekracht (gravity) constructie, meer security emergency gate constructies.

Een voorbeeld dat lijkt op ons model.
link met foto
Hoe benoemd men dat: Gravity assisted gate Excellent gate design. No chance of this being left open in error. Omgeving
Het lijkt er op, dat je ook even moet bukken. Wegens dat men er een plank boven heeft aangebracht. Dit was de enigste, die ik kon vinden.

barrier=gate, met nog meer op zichzelfde staande varianten. barrier=swing_gate
gate:type wiki
single en double, maar ook andere taginfo
Klaphek, als je *=single gebruikt, wat het ook is, dan kan je geen andere value toevoegen om hinged, angle, self_closing, uit te drukken.
Zijn er andere keys, die men ook kan gebruiken om de eigenschappen uit te beelden.
Dacht nog even aan locked=*, maar dan kan het dan ook tegenstrijdig zijn met conditional values?
Heb dan ook nog even bij “door” gekeken of daar functies werden vernoemd.

barrier=swing_gate heeft ook eigen swing_gate:type=* single en double
Eigenschap van een swing_gate is wel dat het ook aan een zijde twee scharnieren heeft.

In een ander topic gaf men het gebruik van description=klaphekje aan.





Dit is dan geen klaphekje, maar een barrier=kissing_gate.

It’s a very interesting door shape.
I think the most important property of this kind of gate is that it closes by itself, either by gravity or some other device like a weight.
So I would call it a ‘restoration gate’. I would also like to give it the key ‘barrier=restoration_gate’.
For reference, I think it’s better for everyone to find and use tags by grouping them by attribute as much as possible, except for barrier, which has a common and distinct attribute, to simplify it.

Persoonlijk ben ik meer fan van barrier=gate en gate:type=*. Anders krijgen we wildgroei aan tags waar een renderer of router niet tegenop kan. Zeker omdat de key barrier ook dingen bevat waar je juist niet doorheen kan, zoals barrier=fence.

5 Likes

Goed punt.
barrier=gate bevat de belangrijkste informatie, namelijk welke soort barrier het is: een hek wat in principe open en dicht kan. Of-ie opzij, omhoog of omlaag klapt, of verzinkt of opvouwt is minder belangrijk dan wie/wat erdoorheen kan.

De extra info in subtags zetten is dan beter, denk ik.
Dus bv barrier=gate, gate=stile.
barrier:type op een barrier bijtaggen vind ik slecht. Tags van een object slaan op het object, dus barrier: is daarin overbodig. En alleen type zegt niet waar je naar kijkt. Het gebruik is dan dat de value van barrier zegt welke hoofdsoort van barrier het is, en dan tag je eventueel /value/=* voor de nadere onderverdeling in bekende soorten met allerlei benamingen, en desgewenst material=, surface=, mechanism=, capacity= , colour= etc. voor allerlei kenmerken.
Voor automatisch dichtvallen zou ik dan een toggle-tag doen, bv autoclose=yes, ik verzin maar wat.

Wil je dan wereldwijd alle barrier=stile aanpassen?

https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dstile

Overigens vraag ik me af of een stile wel een gate is. Definitie van een gate is dat hij open en dicht kan.

https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dgate

gate taginfo, die had ik nog niet bekeken.
Moeilijke waardes.

Met een schuin oog kijk ik naar het gebruik door veiligheidsregio.
Gebruikvriendelijkheid.
De node, staat die op een path of track. Zegt dat iets over de breedte?
Deels, bij een track verwacht je dat een tweesporig voertuig er door heen kan.
Bij path is dat wisselend, er zijn path die eigenlijk ingetekend moeten worden als track.
Dan is er nog de cycleway.

Hoe geef je de correcte informatie mee, dat anderen er wat aan hebben.

Access tagging op de gate node, kan je inzetten om het feitelijke, is het te gebruiken door te taggen. Niet op basis van het art. 461 bordje dat vaak er naast staat. Sommige tekenen extra een wayline in met gate, i.p.v. de fence door te tekenen. Daar zou men technisch de mogelijkheid hebben om de breedte te calculeren. Omslachtig. Anderzijds width voor gate aangeven, hoe betrouwbaar is dat.

Mijn voorkeur gaat dan ook uit om te beginnen met barrier=gate, belangrijk is dan de methodiek keuze. Zo zijn er dan verschillende mogelijkheden.

Wat zou dan een goede Nederlandse keuze zijn, daar ging het mij om.

A ja, da’s een goeie! Misschien is het eerder een entrance.