[RFC][Proposal] Civil Protection Areas - emergency:waiting_area, shelter_area, staging_area_rescue, logistic_entry_rescue

[AndreaDp271]

Hi everyone,

I’m advancing [[Proposal:Civil Protection Areas|this proposal]] from Draft to Proposed status and starting the RFC as per Proposal process - OpenStreetMap Wiki .

Summary

Introduces four new tags in the emergency:* namespace to map officially designated civil protection areas from municipal emergency plans:

• emergency:waiting_area=yes – areas where population gathers post-evacuation
• emergency:shelter_area=yes – temporary shelter/accommodation areas
• emergency:staging_area_rescue=yes – assembly for rescue teams/resources
• emergency:logistic_entry_rescue=yes – access points for emergency logistics

These complement existing tags like emergency=assembly_point (building-scale) by targeting larger areas (parks, squares, districts) managed by civil protection authorities.

Key rationale and differences documented here: Proposal:Civil Protection Areas - OpenStreetMap Wiki

Italian context

Defined in municipal civil protection plans (e.g., Castelfranco Veneto examples already mapped with OSM IDs).

International examples

Added real-world cases:

• Japan: Earthquake evacuation parks → waiting/shelter areas
• USA (Oregon): Tsunami assembly zones → waiting_area
• New Zealand: Civil defence open spaces → staging_area
  (Full list in proposal)

Taginfo shows low/no collisions: Search results | OpenStreetMap Taginfo

Please review, comment on the [[Proposal_talk:Civil_Protection_Areas|talk page]] (create if needed), and share similar designations from your country!

Tags: wiki-proposal rfc emergency civil-protection italy

Thanks!
AndreaDp271

[InsertUser]

The way I have always read it there is no particular need for an emergency:social_facility=shelter to be constrained to a single building. A whole hotel complex could be designated this way if that’s the actual arrangement.

[AndreaDp271]

@insertuser Thanks for the feedback!

You’re right, the wiki doesn’t explicitly constrain emergency:social_facility=shelter to single buildings, and hotel complexes could technically use it.

Core distinction is “facilities” vs open areas without buildings:

“emergency:social_facility=shelter is used for tagging facilities with a secondary function of a shelter… schools, stadiums, or government buildings.”

Aspect	emergency:social_facility=shelter	Proposed emergency:shelter_area=* etc.
Maps	Buildings/amenities with capacity	Open spaces w/o buildings (parks, field)
Normal use	School/hotel + secondary shelter	Public park (zero shelter capacity)
Emergency	Uses existing indoor space	Tents/services deployed by civil protection
Scale	Single complex	Neighborhood zones
Multi-function	Single role	Waiting + shelter + staging possible

Current OSM practice: 2017 Taiwan/Philippines import used it for schools/stadiums; taginfo shows mostly building=* nodes/ways, not empty areas.

Civil protection plans need tags for open areas without facilities that become shelters/waiting zones only when activated. The emergency:*=* namespace fills this gap perfectly.

Does this distinction between “facility shelters” vs “open-space civil protection areas” make sense for your mapping?

[InsertUser]

Facility is really quite a broad term e.g. a school’s “sports facilities” could just be a flat field that’s kept clear with a couple of portable goals or lines painted on the ground. They could even be rented out outside of school hours as a secondary revenue stream.

Tagging things that are usually a single building on broader areas is really common when the situation demands it without inventing a new tag. Despite more than half of the social_facility=group_home elements being recorded as ways only 37% of them have a building tag.

On the other hand where the shelter does re-use a building describing that as a ‘shelter area’ would very counter-intuitive.

The emergency=assembly_point tagging has subtags for various forms of natural disaster. The inclusion of natural disaster types strongly implies that the tag isn’t intended solely for the evacuees from a single building.

[Kovoschiz]

You are misunderstanding what emergency:*= means, and different methods

1. emergency:*= can be used for features that will be activated in disasters, therefore empty spaces for tents are acceptable
2. amenity= + building= is a common simple method, but amenity=school can be used on the grounds for the entire site

At least refer to the sole example Key:emergency:* - OpenStreetMap Wiki
Both schools and parks are facilities. Whether there are buildings and other permanent equipment inside should be found by a spatial join, or a new attribute. Existing features should not be redefined.
There’s no need to make many emergency:*_area=yes and emergency:*_rescue=yes . Again, emergency:*= is a prefix, meaning there should be some =*_area and =*_rescue features first.

• shelter_area →emergency:amenity=social_facility + emergency:social_facility=shelter : As discussed above
• waiting_area → emergency:assembly_point:*= : =assembly_point + assembly_point:*= already exists, and the emergency:*= prefix can be applied
• *_rescue : Unnecessary suffix format that should be discussed as rescue_* here. However instead, eg emergency=base and emergency=depot should be discussed first, to be applied as emergency:base= and emergency:depot= . Initial discussion: Possible new way of mapping emergency service areas & locations

[AndreaDp271]

Unless we want to deprecate the existing tags and create a new, generic ‘emergency_zone’ with dozens of subtags, the current proposal is the most logical way to map official Civil Protection plans without creating ambiguity.

Regarding your points, @InsertUser:

1. The ‘Assembly Point’ Misconception The existence of subtags like assembly_point:earthquake=yes, fire, flood, etc., is, in my view, a clear symptom of a missing tag. Mappers used them because they lacked a specific scheme for Civil Protection areas, but that doesn’t make it the correct tool for the job.

Per the wiki, an assembly point is primarily for immediate evacuation (building-scale). Using it for a waiting area (neighborhood-scale) or a staging area (rescue teams) creates a semantic overload. For example, a rescue vehicle assembly zone should not be tagged as an ‘assembly point’ for citizens; they serve different purposes, and mixing them in the same tag could be confusing for data users.

2. Why ‘Social Facility’ is the wrong bucket emergency:social_facility=shelter was clearly designed for buildings (schools, gyms) providing indoor services. Forcing an empty public park or a parking lot into this tag is a stretch for two reasons:

• A Social Facility implies an existing infrastructure or managed service.

• An emergency:shelter_area (as per my proposal) is a land-use designation for an open space that provides zero shelter until the authorities activate it.

Labeling an empty field as a ‘facility’ just to avoid a new tag makes it impossible for an app or a rescuer to distinguish between “indoor capacity” and “deployable open space.”

3. Filling the Gap We currently have two hyper-specific tags (emergency=assembly_point and social_facility=shelter) that don’t cover the operational reality of Civil Protection (like staging areas for resources). My goal is to provide a precise, additive namespace (Key:emergency:*) that enriches existing features (parks, squares) without ‘hijacking’ their primary identity or forcing them into categories that don’t quite fit.

[AndreaDp271]

I think there is a fundamental misunderstanding about what is being mapped here. We are not mapping ‘empty spaces’ as temporary physical objects, but the permanent official designation of an area within a Civil Protection Plan.

You mentioned that emergency:* is for features activated in disasters. That is exactly my point. A public park or a parking lot exists today as leisure=park or amenity=parking. However, it has a permanent legal and operational status as a ‘Waiting Area’ or ‘Staging Area’ defined by local authorities.

Using the emergency:[function]=yes namespace is the correct way to map this property without claiming that there is a ‘facility’ (like a shelter building) currently operating there. Labeling an empty field as a social_facility=shelter just because it might host tents in the future is misleading: a ‘facility’ implies existing infrastructure. My proposal allows us to enrich the existing feature (the park or the lot) with its official emergency role, which is exactly how Key:emergency:* is intended to be used.

[InsertUser]

@AndreaDp271

Unless we want to deprecate the existing tags and create a new, generic ‘emergency_zone’ with dozens of subtags, the current proposal is the most logical way to map official Civil Protection plans without creating ambiguity.

Not from what I’ve read there or in this thread.

@AndreaDp271

A Social Facility implies an existing infrastructure or managed service.

And an emergency:social_facility implies that something is converted into a social facility in an emergency. Like maybe providing beds for people to sleep on and or bathroom facilities. Management is usually by whoever designated it as an emergency facility and “existing infrastructure” is often locked away in a storage cupboard or in containers in a central depot until needed.

@AndreaDp271

Labeling an empty field as a ‘facility’ just to avoid a new tag makes it impossible for an app or a rescuer to distinguish between “indoor capacity” and “deployable open space.”

The existing emergency tags don’t preclude the usual building or landuse tags nor do they stop people from using typical GIS tools as suggested by @Kovoschiz. Whether or not something is tagged as a building is a poor indication of how many it can hold anyway as a multi-storey hotel will probably be able to hold more than an indoor basketball court where people can’t put beds on fixed seating areas etc etc. If you want to add capacities to emergency use cases you’re probably better off doing a derivative of the existing capacity tagging scheme under the emergency: prefix in typical OSM fashion (this has already been done 300+ times).

@AndreaDp271

My goal is to provide a precise, additive namespace (Key:emergency:*) that enriches existing features (parks, squares) without ‘hijacking’ their primary identity or forcing them into categories that don’t quite fit.

Nothing about the current emergency: prefix ‘hijacks’ a feature’s primary identity. That’s the whole point of it. I’m getting the distinct impression you’re fundamentally misunderstanding the current tagging scheme.

@AndreaDp271

We are not mapping ‘empty spaces’ as temporary physical objects, but the permanent official designation of an area within a Civil Protection Plan.

We have pre-existing tags to indicate the official designation of things according to local rules. Using emergency:designation to record what officialdom call them would probably make more sense.

@AndreaDp271

Labeling an empty field as a social_facility=shelter just because it might host tents in the future is misleading: a ‘facility’ implies existing infrastructure.

You would not be tagging it as social_facility=shelter you’d be tagging it as emergency:social_facility=shelter, if this does not feel right then you could propose something like emergency=camp_site which would make more sense than shelter_area.

[AndreaDp271]

I appreciate the time you are taking to dissect the proposal, but I feel we are going in circles on personal preferences rather than addressing the functional gaps this proposal solves.

1. The ‘Camp Site’ admission

Your suggestion to use emergency=camp_site is revealing. It proves that you agree social_facility is not a good fit for an open field, and that we need a tag that implies “tents/open space” rather than “building”.

However, camp_site implies tourism/leisure. Since these are Civil Protection areas, emergency:shelter_area captures exactly the concept of a “camp site for emergency use” without the tourism implication. Thank you for validating the need for a distinction between indoor facilities and outdoor areas.

2. The Elephant in the Room: Staging Areas (Rescue)

You are focusing heavily on shelters, but you haven’t addressed the other half of the proposal: Staging Areas (emergency:staging_area_rescue).

These are large paved areas (parking lots, squares) designated for the assembly of heavy rescue vehicles, columns, and machinery.

They are NOT social_facilities (no social service provided).

They are NOT camp_sites (no sleeping involved).

They are NOT assembly_points (civilians must stay away).

Under your strict adherence to existing tags, how would you map a parking lot designated for fire trucks and cranes? My proposal offers a clean, namespace-consistent solution (emergency:staging_area_rescue=yes).

3. GIS vs. Human Readability

While specialized GIS users can perform complex spatial joins between emergency tags and building footprints to guess capacity or type, OSM data is also used by lighter applications and human planners. Explicitly tagging the function (waiting_area vs shelter_area) is standard OSM practice (like amenity=school vs amenity=university) and reduces the margin for error during a crisis.

4. Designation vs. Tagging

Using emergency:designation to describe the function is an anti-pattern. We don’t map building=yes + designation=school; we map amenity=school. Similarly, we should map the functional emergency role explicitly.

[Fizzie-DWG (Graeme Fitzpatrick)]

@AndreaDp271

These are large paved areas (parking lots, squares)

But is every parking lot or square so designated?

& where do the rescuers go if “that” spot has been damaged by the earthquake or whatever? Can they just pick another parking lot?

I think I can see what you’re trying to do, but as others have said, it’s not quite right.

(Oh, personal comments only!)

[AndreaDp271]

Hi, @Fizzie-DWG. Those are very practical questions.

1. Is every parking lot designated? No, definitely not. The goal of this proposal is to map only those locations formally designated by local authorities in their Municipal Emergency Plans. These are often marked with specific physical signage (as shown in my proposal examples). We are mapping the ‘official infrastructure’ of the emergency plan, not just any open space.

2. Resilience and ‘On the ground’ areas Regarding your question about damage: these areas are specifically selected by Civil Protection planners because they are open, ‘on the ground’ spaces (parks, large flat parking lots, squares). They are chosen precisely because they lack complex structures that could collapse. Unlike a multi-story parking garage or a building, a flat paved area or a public park remains usable even after a major seismic event. It is the safest ‘Plan A’ available.

3. Why map the plan? While authorities might pick another spot if a road is blocked, OSM should reflect the official designated locations. Just as we map emergency exits or fire hydrants, knowing they might be blocked in a specific scenario, we map these areas because they are the primary reference points for both citizens and rescue coordination during an emergency.

[InsertUser]

@AndreaDp271

However, camp_site implies tourism/leisure. Since these are Civil Protection areas, emergency:shelter_area captures exactly the concept of a “camp site for emergency use” without the tourism implication.

Not really. IMHO it’s the tourism in the tourism=camp_site that implies leisure. I doubt most military camps would accept your average tourist just because they’re also ‘camping’. The occupants of most refugee camps generally aren’t tourists either.

emergency:shelter_area is very vague choice of tag. If I saw it in the data I’d generally assume it was meant to indicate some sort of sheltered bay that didn’t happen to have a harbour in it or a place protected by an existing windbreak or avalanche barrier rather than a place that somebody is meant to bring some form of shelters to at some point. Especially as places shelters are brought to when needed are generally called some variation on a camp.

@AndreaDp271

You are focusing heavily on shelters, but you haven’t addressed the other half of the proposal: Staging Areas (emergency:staging_area_rescue).

It is a very verbose proposal. Addressing the whole thing in one go might require a novella.

Having a tag for pre-determined staging areas seems reasonable if they are known in advance. The tag choice seems overly specific to me. Some of the document linked in support of the proposal appear to be as much about distributing supplies as they are about organising rescues.

@AndreaDp271

Under your strict adherence to existing tags,

I have no strict adherence to existing tags, but if new tags are to be proposed they should fit within the existing tagging landscape as best as possible rather than providing near or exact duplicates without much in the way of reasons why the existing tags are inadequate.

@AndreaDp271

Using emergency:designation to describe the function is an anti-pattern. We don’t map building=yes + designation=school; we map amenity=school. Similarly, we should map the functional emergency role explicitly.

We do map emergency roles explicitly by saying in an emergency it takes on another function. i.e. emergency:<other function>.

In other aspects of OSM designation tags are used where there is a specific legal category for something that has a broader meaning internationally or in the casual speech that was used to design the main tag.

The use of one would not prevent use of the other.

[AndreaDp271]

@InsertUser

Not really. IMHO it’s the tourism in the tourism=camp_site that implies leisure. I doubt most military camps would accept your average tourist just because they’re also ‘camping’. The occupants of most refugee camps generally aren’t tourists either.

While you are semantically correct about the English word “camp”, we must deal with how the OSM database actually works. In the OSM ecosystem, the string camp_site is overwhelmingly tied to the definition at Tag:tourism=camp_site, described as “A place where people can set up tents… usually for tourism.” Military bases use landuse=military and refugee camps often use complex humanitarian schemas. If we use emergency=camp_site, we risk high false positives. Most renderers and apps fuzzy-match the string camp_site to display tent icons for travelers. Using a distinct value like shelter_area ensures that an emergency waiting zone in a city square is never mistaken for a leisure spot by a traveler’s app.

@InsertUser

emergency:shelter_area is very vague choice of tag. If I saw it in the data I’d generally assume it was meant to indicate some sort of sheltered bay that didn’t happen to have a harbour in it or a place protected by an existing windbreak

In OSM, context is key. The emergency:* prefix acts as a semantic namespace. Just as emergency=fire_hydrant isn’t confused with a garden tap, emergency:shelter_area—located in an urban park or parking lot—is extremely unlikely to be misinterpreted as a nautical bay or a windbreak. The Wiki definition will explicitly clarify it as a “Temporary Population Accommodation Area” to remove any linguistic doubt.

@InsertUser

Having a tag for pre-determined staging areas seems reasonable if they are known in advance. The tag choice seems overly specific to me. Some of the document linked in support of the proposal appear to be as much about distributing supplies as they are about organising rescues.

I am glad we agree on the usefulness of mapping Staging Areas. To clarify: they are indeed known in advance, as they are established in official Municipal Emergency Plans and often marked with permanent signs.

The specificity is necessary because, in professional rescue logistics, there is a clear distinction between a hub for heavy machinery/rescue columns (staging_area_rescue) and a hub for the distribution of relief supplies to the population (logistic_entry). Sometimes a site does both, but a rescuer needs to know exactly where to park a crane versus where a citizen goes to get water and blankets.

@InsertUser

I have no strict adherence to existing tags, but if new tags are to be proposed they should fit within the existing tagging landscape as best as possible

I agree. However, there is a “scale gap” in the current landscape. We have assembly_point for immediate, small-scale evacuation (building level) and social_facility=shelter for indoor services (schools/gyms). There is currently no tag for large-scale territorial zones designated for professional rescue logistics or outdoor population reception. My proposal aims to fill this void without duplicating existing tags.

@InsertUser

We do map emergency roles explicitly by saying in an emergency it takes on another function. i.e. emergency:<other function>.

Exactly! This is why I am proposing the emergency:[function]=yes format. It follows the exact logic you mentioned: it takes an existing feature (like a park or a parking lot) and adds its emergency role as an additional property. We are aligned on the method; the goal is simply to define clear, non-ambiguous values for those roles.

[dieterdreist (Martin Koppenhöfer)]

@AndreaDp271

In the OSM ecosystem, the string camp_site is overwhelmingly tied to the definition at Tag:tourism=camp_site, described as “A place where people can set up tents… usually for tourism.” Military bases use landuse=military and refugee camps often use complex humanitarian schemas. If we use emergency=camp_site, we risk high false positives. Most renderers and apps fuzzy-match the string camp_site to display tent icons for travelers

It is foremost the key that adds context in osm. If someone “fuzzy matches” all objects with a specific value without looking at the key, there is a good chance to get it wrong.

[notmyproblem1 (iluvtesla)]

TL;dr guy is here, ping me where you want to get a toolong;didntread summary.

@AndreaDp271 is trying to map official civil-protection designations for large outdoor areas using new emergency:* roles, arguing that existing tags imply buildings, services, or tourism and don’t fit planning-level zones. @InsertUser, @Kovoschiz, and @dieterdreist push back, saying the current emergency: prefix and existing tags already cover this, and that the issue is misuse or misunderstanding rather than a missing tagging concept.

This Action

This action was made by an human, the text is reviewed by an human but wrote by an AI

[InsertUser]

@AndreaDp271

While you are semantically correct about the English word “camp”, we must deal with how the OSM database actually works. In the OSM ecosystem, the string camp_site is overwhelmingly tied to the definition at Tag:tourism=camp_site,

How the OSM data actually works is that there are tags in the form of key=value pairs. If someone is naive enough to ignore the key and process only the value then they’re going to get lots of complaints from users who are annoyed that they’re going to places that no longer exist^[1] because a lifecycle prefix has been completely ignored^[2].

It also seems really weird to me to say that we can’t have camp_site because it might give the impression of an area where tents are erected for a different purpose, but to instead insist on shelter_area which doesn’t really give the impression of temporary structures being constructed at all.

@AndreaDp271

I agree. However, there is a “scale gap” in the current landscape. We have assembly_point for immediate, small-scale evacuation (building level) and social_facility=shelter for indoor services (schools/gyms). There is currently no tag for large-scale territorial zones designated for professional rescue logistics or outdoor population reception. My proposal aims to fill this void without duplicating existing tags.

As has been stated multiple times the fact that some amenities are often indoor doesn’t mean they’re always indoor without additional tags to indicate that.

The emergency=disaster_response proposal suggest a number of possible subtags for future expansion of that tagging scheme for larger scale operations. Similar subtags could probably be used here with the emergency: prefix if we want something with a global outlook that also have similar tagging as permanent facilities that do those things.

@AndreaDp271

The specificity is necessary because, in professional rescue logistics, there is a clear distinction between a hub for heavy machinery/rescue columns (staging_area_rescue) and a hub for the distribution of relief supplies to the population (logistic_entry). Sometimes a site does both, but a rescuer needs to know exactly where to park a crane versus where a citizen goes to get water and blankets.

Which in typical OSM fashion would normally be done with subtags rather than just assuming that these will always be separate functions in every jurisdiction just because they are separate functions in one country.

---

1. or that don’t exist yet. ↩︎

2. they’ll probably also get very confused by all the yes and no values ↩︎

[Kovoschiz]

1. As others mentioned, =camp_site would be viewed in emergency= vs tourism= differently, similar to =phone , =shower , and =drinking_water in amenity= originally. The reason I would avoid =camp_site is aside from the inconvenience from a potential camp_site= attribute, tents vs buildings are structures, not fitting emergency= functions.
2. We have been “focusing heavily on shelters”, because you focused heavily on it to begin with. The emergency:*=* logic requires a normal *=* feature to exist first. Your solution causes inconsistency, and messes them up. It’s suggesting there’s a staging_area_rescue=yes feature used already. You are actually inventing a new use for it.
3. What’s “specialized GIS users”? Overpass is_in , or QGIS is not difficult if someone wants to do it. Turbo’s Wizard might even be possible, if not the many AI now. That’s not working on databases with obscure CLI programs. Again from 1, You are mixing up function and the structural form. building=school is used to show buildings, not defining amenity=school as buildings. Another feature or attribute is needed.
4. The suggestion for something titled “Shelter Area” was emergency:social_facility=shelter + emergency:designation=Shelter Area

Further to 1, there are several cases
A. The site has no or little empty grounds. Only buildings can be used.
B. The site has some grounds, but the department decided to use the buildings only
C. Tents are set up in addition to using the buildings
D. There are some small buildings, and mainly tents will be used
E. No buildings. Must set up tents.

These can’t be distinguished from a single =yes / =no feature. 2 attributes each for tents and buildings are required.

Format-wise, it’s not good to invent many =yes features. Features usually don’t use =yes either.

[AndreaDp271]

Hi everyone!

Looking at the various doubts and feedback you’ve shared, I realized that I left several things for granted and wasn’t clear enough in the first draft. I’ve now extensively updated the proposal to clarify these ‘grey areas’.

Please take a new look at the page. The main updates include:

• Structural Resilience: Clarified why these areas are different from simple assembly points (safe open zones vs. vulnerable buildings).

• Operational Overlay: Specified that we map the emergency function on existing polygons (parks, parking lots) to avoid duplicate geometries.

• Nodes vs. Ways: Clarified that Nodes are used for the physical signposts, while Ways are used for the logistic entry routes to assist with emergency routing.

• Real-world Examples: Added links to real OSM Ways and Nodes and included photos of the signs to show exactly how it works in practice.

Thank you for your patience and for the feedback that helped me improve this. Sorry for the initial lack of clarity!

[AndreaDp271]

You are right about the renderer argument: we shouldn’t tag for the renderer, so I will drop that specific point.

However, I found a major semantic blocker in the Wiki that makes camp_site unsuitable for this proposal.
The documentation for camp_site explicitly states: “This tag should always be associated with tourism=camp_site”.
The entire definition of the term in OSM is built around leisure, pitches, and tourism infrastructure.

Using emergency=camp_site or emergency:camp_site would imply inheriting this “tourism baggage”. A Civil Protection area is completely different:

1. It’s not for leisure: It’s for survival/housing.

2. It’s not always a camp: As mentioned, it can be a container village (SAE), a requisitioned warehouse, or a prefab module area.

If I use camp_site, I force a “tourism” definition onto a “crisis management” feature.
emergency:shelter_area avoids this ambiguity entirely. It clearly defines a function (sheltering people) without implying tents or holidays.

Given this Wiki definition, do you agree that a fresh tag like shelter_area is cleaner?

[AndreaDp271]

@InsertUser

How the OSM data actually works is that there are tags in the form of key=value pairs. If someone is naive enough to ignore the key and process only the value then they’re going to get lots of complaints from users who are annoyed that they’re going to places that no longer exist because a lifecycle prefix has been completely ignored .

It also seems really weird to me to say that we can’t have camp_site because it might give the impression of an area where tents are erected for a different purpose, but to instead insist on shelter_area which doesn’t really give the impression of temporary structures being constructed at all.

I understand the technical argument about ignoring the key (tourism vs emergency) and looking only at the value. However, there is a fundamental semantic blocker in the Wiki documentation itself.
The Wiki page for Key:camp_site explicitly states:

“The tag is intended to describe tourist-focused camps, not other facilities that also use the word ‘camp’ such as refugee or emergency accommodation.”

Using emergency=camp_site or emergency:camp_site would contradict this established definition, mixing leisure infrastructure with crisis management.
Since the Wiki explicitly excludes emergency accommodation from camp_site, we technically need a distinct value. shelter_area fits perfectly because it describes the function (population housing) without carrying the “tourism” baggage or violating the Wiki’s exclusion clause.

@InsertUser

As has been stated multiple times the fact that some amenities are often indoor doesn’t mean they’re always indoor without additional tags to indicate that.

The emergency=disaster_response proposal suggest a number of possible subtags for future expansion of that tagging scheme for larger scale operations. Similar subtags could probably be used here with the emergency: prefix if we want something with a global outlook that also have similar tagging as permanent facilities that do those things.

My proposal uses the emergency:* namespace precisely to act as a structured extension of the emergency key.
Instead of creating a deep, complex hierarchy like emergency=disaster_response + disaster_response:type=staging_area, using emergency:staging_area_rescue=yes provides a flatter, more queryable structure. This follows the modern tagging practice of using namespaces for specific domains.

@InsertUser

Which in typical OSM fashion would normally be done with subtags rather than just assuming that these will always be separate functions in every jurisdiction just because they are separate functions in one country.

I realize my initial explanation might have been imprecise regarding “duplicate areas”. To be clear: these tags are intended to be added to existing OSM features (or to the physical signpost), not to create duplicate abstract geometries.

• emergency:staging_area_rescue=yes: Is added to the Area (e.g., an existing amenity=parking or leisure=pitch). It defines the capacity/space available for the rescue team.

• emergency:logistic_entry_rescue=yes: Is added to the Node (e.g., a gate, a man_made=sign) or the specific Way (access road). It defines the routing destination.

In a disaster scenario, you route the convoy to the logistic_entry (Node/Sign) to ensure they enter the correct gate, rather than routing to the centroid of the staging_area.
I have just updated the Wiki Proposal to explicitly clarify this topological distinction and remove any ambiguity about duplication.