Ik snap wat je zegt - en het is in feite niet anders als wat ik in een eerdere discussie over BTCmap ook opmerkte:
Ietwat ge-edit om naar de huidige situatie aan te passen, gaat immers over eigenschap van een POI ipv de POI zelf. 
Wat ik aanneem dat speelt voor BTCMap durf ik ook aan te nemen voor LiveOp: het is makkelijker om alle info die je nodig hebt uit één bron te halen, maar strikt genomen heb je (@Peter_Elderson) gelijk dat het er niet in alle gevallen in thuishoort op OSM. Als het geen eigenschap van het object is, klinkt als een mooie scheidingslijn.
Maar, dat gezegd hebbend, deze ligt de interpretatie van deze scheidingslijn wel lastiger en genuanceerder dan ik 'm bij BTCMap vond liggen. Want of de nooddienst het obstakel kan passeren kan wel een eigenschap zijn van het object. Het eerder genoemde SOS toegang is daar een voorbeeld van. Andere toegangsmethoden die door de hulpdiensten gebruikt kunnen worden zijn dat ook (standaardcilinder zoals driehoek of vierkant, brandweercilinder, aanwezigheid van brandweerkluis of andere nood-opener, etc).
Enerzijds is dat niet altijd voor een leek waarneembaar, anderzijds vindt ik het persoonlijk passend om te zorgen dat dit (net als zo veel mogelijk andere tags) “iteratief” kan worden getagt. Dwz: eigenschappen eerst op hoofdlijn/in algemene zin toe te voegen en vervolgens verder te verfijnen.
Dwz: vergelijkbaar met de analogie vanuit sidewalk of cycleway (nav deze discussie): het moet zo simpel kunnen zijn als in eerste instantie algemeen aangeven dát toegang voor de hulpdiensten gefaciliteerd is - om vervolgens voor de liefhebber/expert/geef-het-beestje-een-naam óók de mogelijkheid te bieden om te specificeren hoe dat geregeld is.
Net als iemand kan beginnen met sidewalk=yes/right/left/no om aan te geven dat er een stoep is. Dat is toegankelijk en begrijpelijk voor zelfs een beginnend mapper en kent door z’n eenvoud een beperkte foutgevoeligheid.
Een gevorderder (of meer detail-georiënteerde mapper die van stoepen z’n ding heeft gemaakt), kan het vervolgens zo gek maken als 'ie wil met sidewalk:*:surface=*, sidewalk:*:smoothness=*, sidewalk:*:width=* of est_width=*, sidewalk:*:bicycle=*, sidewalk:*:incline=*, sidewalk:*:kerb=*, sidewalk:*:wheelchair=*, sidewalk:*:tactile_paving=*, sidewalk:*:traffic_sign=* - en weet ik wat niet nog meer - om de nuances in kaart te brengen.
Datzelfde zou wat mij betreft ook moeten gelden voor deze situatie. En dat kan al, door emergency=yes op hoofdlijn te gebruiken, en dan bijv. (als ik het tagging schema van AED’s volg) locked=* voor een verdere verfijning.
Daar sta ik achter, maar dat is dus feitelijk al een verfijning. Stap 1: ja, de paal is wegklap- of wegneembaar voor de nooddiensten. Stap 2 is hoe dat gebeurt.
Qua consistentie zou ik dan pleiten voor locked=* (zie boven), en/of emergency:unlock (en dan met een postfix ipv een underscore, zoals gebruikerlijker lijkt bij tags die op een dieper niveau details toevoegen aan iets wat op hoofdlijn al gespecificeerd is).
Overigens is het gebruik van emergency=yes wel gedocumenteerd en goedgekeurd als ik Key:emergency - OpenStreetMap Wiki goed interpreteer:
Die laatste (de code-optie) kun je overigens ook uitleggen als “niet eigenschap van het object”. Want is het de gebruiker die de code heeft of het object dat de code accepteert? In zekere zin geldt dat eigenlijk ook zo voor een sleutel.
Begrijp me niet verkeerd, ik snap echt waar je vandaan komt, maar vind het grijs genoeg om er in dit geval geen punt van te maken. Zeker omdat we het bijv. voor wegen en andere variaties wel al toestaan - je kunt dit echt allebei de kanten op uitleggen.
Onderaan de streep denk ik dat we er trots op mogen zijn dat OSM in Nederland zo goed, nauwkeurig en actueel is dat het aantrekkelijk is voor hulpdiensten om er gebruik van te maken tov alternatieven en het willen verrijken met dit soort informatie (wat we accepteren voor wegen etc en andere plekken waar toegang geldt, en dan alleen hiervoor evt niet).
Ik zou er dan ook voor willen pleiten dat we vooral kijken wat er wél mogelijk is (zeker in een grensgeval als dit) en ons te veel verliezen in bikeshedding. Idealiter gaan we nog een stap verder en treden we hierover in overleg met LiveOp (of eigenlijk: idealiter zij met ons, zoals SOS Toegang wel deed, maar het kan niet altijd feest zijn ), kunnen we behoefte en juiste implementatie op elkaar afstemmen en documenteren.
Maar tot die tijd, lijkt het mij in ieder geval prima om waar nodig en van toepassing emergency=yes op barrier’s te zetten. De verantwoordelijkheid om dat kloppend te houden ligt dan bij veiligheidsregio’s, maar die nemen ze de facto al.