Proposal:Civil Protection Areas

Civil Protection Areas
Proposal status:	Voting (under way)
Proposed by:	AndreaDp271
Tagging:	emergency:*=yes
Applies to:
Definition:	A tagging scheme to map officially designated areas for population and rescue management within civil protection and emergency plans.
Statistics:
Rendered as:	https://andreadp271.github.io/civil_protection_areas_osm/
Draft started:	2025-10-08
RFC start:	2026-01-27
Vote start:	2026-03-09
Vote end:	2026-03-23

Proposal

This proposal introduces a consistent tagging scheme to map officially designated civil protection areas. These are locations identified in advance by authorities (e.g., in Municipal Emergency Plans) to manage the population and rescue operations during a disaster.

The scheme uses the emergency=* namespace to allow mapping multiple emergency functions on the same feature without conflicting with its primary peacetime use (e.g., a park or a parking lot).

• emergency:waiting_area=* – areas where the population temporarily gathers after evacuation.
• emergency:camp_area=* – areas for shelter or temporary accommodation (tents/containers).
• emergency:staging_area=rescue – areas for the assembly of rescue teams and resources.
• emergency:logistic_entry=rescue – points of access for emergency resources.

Rationale

Civil protection areas are formally designated locations used by authorities to manage emergencies. These sites are not chosen "on the fly" during an event; they are identified in advance within Municipal Emergency Plans and are often marked with permanent physical signage.

A core principle of these areas is their structural resilience: they are "on-the-ground" open spaces (such as parks, squares, surface parking lots, or athletic fields) specifically selected because they lack complex structures that could collapse. Furthermore, they are established as safe zones, located far from flood-prone rivers, landslide risks, or high-rise buildings that could pose a threat during a disaster.

Currently, there is a "scale gap" in the tagging landscape. Users often mistakenly map these areas using emergency=assembly_point (intended for building-scale evacuation) or social_facility=shelter (intended for indoor facilities with beds/roofs). This proposal provides specific tags for these large-scale, outdoor, deployable emergency zones.

This proposal is already implemented in a working viewer: Civil Protection Areas Viewer

How to map

These tags act as an Operational Overlay. They describe an official designation that takes effect during an emergency, while the physical area continues to serve its primary purpose in everyday life.

Why add tags to existing areas instead of creating new emergency polygons?

• No Geometry Duplication: Creating separate emergency area polygons over existing parks/parking lots creates overlapping geometries that confuse data validators and spatial queries
• Single Source of Truth: The physical area (park, pitch, parking lot) is mapped once with its primary peacetime tag, then augmented with emergency=* roles
• Established OSM Practice: Similar to tourism=picnic_site on a leisure=park or military=trench on terrain - the base feature + functional overlay.
• Multi-role Support: One polygon can hold multiple emergency functions without duplication
• Data Consumer Friendly: Routing apps and emergency planners can easily query all emergency roles within this park

1. Mapping the Functional Area (Overlay)

The emergency tag should be added to the existing polygon that represents the physical area.

• Public park → waiting area: leisure=park + emergency:waiting_area=yes
• Sports field → camp site: leisure=pitch + emergency:camp_area=yes
• Parking lot → staging area: amenity=parking + emergency:staging_area=rescue

2. Mapping the Physical Signage (Node)

Physical signs are mapped as nodes at the exact signpost location:

• man_made=sign
• emergency:waiting_area=yes (or relevant function)
• operator=* (Municipality)
• ref=* (sign code)

3. Multi-functional Areas

One polygon, multiple roles:

• leisure=park
• emergency:waiting_area=yes
• emergency:camp_area=yes

No overlapping geometries needed.

4. Mapping Logistic Access and Routes

emergency:logistic_entry=rescue applies to:

• Roads (Way): Designated emergency vehicle segments
• Signs (Node): Access point signage
• Purpose: Enables routing software to identify heavy vehicle paths

Tagging

Tag	Value	Elements	Description	Notes
emergency:waiting_area=*	yes		Area where the population temporarily gathers after evacuation, prior to transfer to shelters.	Often marked as "Safe Waiting Area" (e.g., "Area di Attesa" in Italy).
emergency:camp_area=*	yes		Open-air area designated for temporary shelter or accommodation (tents/containers).	Distinguished from indoor shelters by being a deployable outdoor space.
emergency:staging_area=rescue			Strategic area for the assembly of rescue teams, heavy machinery, and resources.	Requires structural capacity for heavy vehicles.
emergency:logistic_entry=rescue			Access route or point for emergency resources, vehicles, and logistical operations.	Applied to road segments (Ways) or signposts (Nodes) to enable emergency routing.

Examples

The following examples demonstrate how to map the "Operational Overlay" on existing real-world features (Castelfranco Veneto, Italy).

Function	Peacetime Context	Mapping Strategy	Image	Real-world Links	Tags
Waiting Area (Population)	A public park / playground.	1. The Area: Add overlay to park polygon.		1471930944 1471930944	leisure=park emergency:waiting_area=yes
		2. The Sign: Node at sign location.		12394706936 12394706936	man_made=sign emergency:waiting_area=yes ref=A
Shelter Area (Tents/Containers)	Sports fields and open green space.	1. The Area: Add overlay to pitch polygon.		152673547 152673547	leisure=pitch emergency:camp_area=yes
		2. The Sign: Node at sign location.		12394692557 12394692557	man_made=sign emergency:camp_area=yes ref=R
Staging Area (Rescue Teams)	A school complex with large external spaces.	1. The Area: Add overlay to school polygon.		152656016 152656016	landuse=education emergency:staging_area=rescue
		2. The Sign: Node at sign location.		12394720473 12394720473	man_made=sign emergency:staging_area=rescue ref=S

Why use the emergency:* namespace?

The use of the emergency=* namespace (e.g., emergency:waiting_area=yes) is a deliberate choice to ensure data precision and reflect operational reality.

• Dormant vs. Active Status: These tags represent a legal designation that remains "dormant" during peace time and is activated only during a crisis. The namespace allows this potential function to be recorded without overriding the primary peacetime use.
• Semantic Clarity: The prefix acts as a semantic filter. It ensures that terms like "shelter area" are interpreted strictly within the Civil Protection context, preventing confusion with nautical or leisure terms.
• Global Consistency: This structure follows established international patterns documented in Key:emergency:*, successfully used in countries like Japan, the Philippines, and Taiwan.

Differences with existing tags

Comparison Tables

Gathering Points

Tag	Scale	Context	What's Available	Expected Duration	Primary Function
emergency=assembly_point	Micro (single building/complex)	Fire drill, building evacuation	Roll-call by staff, no supplies	Minutes to hours	Immediate safety from building hazard
emergency:waiting_area=*	Macro (district/neighborhood)	Civil protection plan, formal designation	Holding position, coordination info; no guaranteed supplies	Hours to days	Wait for instructions/transport
emergency=disaster_help_point	Variable (community level)	Disaster coordination point	Information, alerts, drinking water, first aid, shelter (when activated)	During disaster event	Receive relief services

Shelter Comparison

Tag	Scale	Physicality	What's Available	Expected Duration	Primary Function
emergency:camp_area=*	Macro (district/municipal)	Open-air deployable spaces (parks, fields)	Temporary tents/containers (deployed on-site)	Days to weeks	Emergency accommodation
emergency:social_facility=shelter	Macro (district/municipal)	Existing indoor infrastructure	Beds, toilets, kitchen	Days to weeks	Permanent shelter building

Detailed Differences

Differences with emergency=assembly_point

• Scale and context: emergency=assembly_point refers to a single building or complex, whereas civil protection areas (emergency:waiting_area=*, emergency:camp_area=*, etc.) can cover an entire neighborhood, district, or municipal zone.
• Planning and Officiality: While assembly points are often used for immediate fire drills or building evacuations, these areas are formally identified in advance by experts within Municipal Emergency Plans and are often marked with specific permanent signage.
• Structural Resilience and Safety: Assembly points are often located in immediate proximity to buildings (e.g., a sidewalk or courtyard), posing risks from falling debris or glass. The proposed areas are chosen for being "on-the-ground" open spaces specifically selected for their lack of complex structures that could collapse during a seismic event.
• Environmental Selection: Unlike assembly points, these areas are strategically located as safe zones far from high-rise buildings, flood-prone rivers, or landslide risks.
• Management of people: At an assembly point, internal staff performs roll-calls; in civil protection areas, personnel from the Civil Protection Department or volunteers manage the population, providing assistance, information, and coordination.
• Services available: Assembly points usually have no additional services, while waiting or shelter areas may include tents, first aid, water, food, and psychological support.
• Duration: Assembly points are typically used for a few minutes or hours; civil protection areas may be active for several hours or days, until transfer to shelters or the end of the emergency.

Summary: While emergency=assembly_point is intended for specific buildings or small locations, the proposed tags map larger areas with distinct operational functions, complementing the existing tag rather than replacing it.

Differences with emergency=disaster_help_point

The emergency=disaster_help_point marks designated contact points during disasters where affected people can receive basic relief services:

• Information and situation updates
  
• Alert services
  
• Drinking water
  
• First aid
  
• Temporary shelter information
  

Key differences with emergency:waiting_area=*:

• Active vs Passive Role:
  • emergency=disaster_help_point = Active service distribution - people go there expecting to receive something concrete (water, bandages, information)
    
  • emergency:waiting_area=* = Passive holding position - people go there to be counted and wait for orders
    

• Expectations Management:
  • emergency=disaster_help_point creates expectation of immediate material relief → dangerous if supplies don't materialize
    
  • emergency:waiting_area=* creates expectation of being in the right place → safe even if no transport arrives
    

• Pre-designation vs Activation:
  • emergency=disaster_help_point often ordinary locations (churches, schools) that activate during crisis
    
  • emergency:waiting_area=* = permanently designated zones in municipal emergency plans with specific signage
    

• Scale and Flow:
  • emergency=disaster_help_point serves local communities for coordination
    
  • emergency:waiting_area=* manages mass population displacement at neighborhood/district level
    

Summary: Use emergency=disaster_help_point when you want supplies/services; use emergency:waiting_area=* when you want people to hold position until further instructions.

Differences with emergency:social_facility=shelter

The existing tag emergency:social_facility=shelter is intended only for a single building, typically used as a shelter in emergencies (e.g., school, community center, or other facility).

The main differences with the proposed emergency:camp_area=* tag are:

• Physicality (Indoor vs Outdoor): emergency:social_facility=shelter implies existing indoor infrastructure (beds, toilets, roofs) provided by a social service. In contrast, emergency:camp_area=* refers to open-air deployable spaces (parks, fields, squares) that only become shelters when Civil Protection deploys tents or containers.
• Vulnerability: Buildings used as social facilities (like schools) may still be vulnerable to structural damage. emergency:camp_area=* focuses on flat, "on-the-ground" areas that remain accessible and safe even if surrounding buildings are compromised.

Summary: While emergency:social_facility=shelter describes a specific building, emergency:camp_area=* enables mapping of larger designated areas prepared for temporary population accommodation during emergencies.

Differences with tourism=camp_site

Although an area for tents might resemble a campsite, using tourism=camp_site for civil protection areas is considered an anti-pattern:

• Purpose: A campsite is for leisure and tourism. An emergency:camp_area=* is an operational zone for public safety.
• Data Consumption: Using the "camp_site" string in the main tag risks creating "false positives" in consumer apps (e.g., tourists being directed to an emergency area during peace time).
• Namespace Security: The emergency=* prefix provides a clear semantic namespace, ensuring that data users (rescue teams, planners) can distinguish between a public park and a designated area for emergency population accommodation.

Real-world international examples

In addition to the Italian civil protection areas, similar concepts exist in many countries, where authorities designate specific areas that are only used in case of emergencies while serving normal functions (parks, school yards, parking lots, etc.) in everyday life. These real-world practices closely match the functions represented by the proposed tags.

emergency:waiting_area=*

United States (Pacific coast, Oregon)

Tsunami evacuation guides for the Cascadia Subduction Zone describe evacuation routes leading to predefined assembly areas located on higher ground, often in parks, school yards or parking lots that are designated in advance as safe gathering points during an alert. For example, see the Oregon Department of Land Conservation and Development guide Preparing for a Cascadia Subduction Zone Tsunami (https://www.oregon.gov/lcd/NH/Documents/cascadia_subduction_zone_tsunami_guide.pdf) and the Clatsop County Tsunami Evacuation Plan StoryMap (https://storymaps.arcgis.com/stories/90bd871c0b984496902d0339247565e2). These places correspond to emergency:waiting_area=*, as they are where people gather and wait for further instructions after leaving the hazard zone.

New Zealand and Pacific coastal communities

Campus and community tsunami plans specify tsunami evacuation assembly areas (e.g. sports fields, school courtyards, open squares) where evacuees must assemble and remain until authorities decide whether they can return home or must be transferred to shelters. An example is the Laucala Campus Tsunami Evacuation Plan of the University of the South Pacific (https://www.usp.ac.fj/wp-content/uploads/sites/72/2021/08/LAUCALA_CAMPUS_TSUNAMI_EVACUATION_PLAN_.pdf) and regional tsunami manuals by ITIC/NOAA (e.g. Tsunami Evacuations: A Planning Guide for Local Government: https://www.weather.gov/media/itic-car/tempp/373019eng_lowres.pdf). Such predefined assembly areas are functionally equivalent to emergency:waiting_area=*.

United States (social-care and residential facilities)

Emergency plans for group homes, care facilities or similar institutions usually define an external evacuation assembly area where residents and staff must gather and be accounted for after evacuation, distinct from simple exits or sidewalks. Examples can be found in model Emergency Preparedness Plans (e.g. NIGC Model EPP: https://www.nigc.gov/?wpdmdl=13208&ind=13209) and state guidance such as the New Jersey Department of Human Services Emergency Preparedness document (https://nj.gov/humanservices/ddd/assets/documents/providers/eprp-for-providers.pdf). These designated gathering points fit the concept of emergency:waiting_area=* as waiting/coordination areas for evacuees.

emergency:camp_area=*

Japan

Urban emergency-planning guidelines and research on emergency shelters and open spaces in Japanese cities distinguish large parks and open spaces designated as emergency shelter open spaces or temporary shelters, with minimum area, accessibility criteria and distance requirements from residential blocks. One example is the paper Instructions for planning emergency shelters and open spaces in urban areas (https://pmc.ncbi.nlm.nih.gov/articles/PMC7443315/), which analyses shelter open-space planning in several Japanese cities. These open spaces are intended to host evacuees with tents and basic services in case of disasters and correspond to emergency:camp_area=*.

China

The same international guidance discusses Chinese cities where parks and squares are formally planned as emergency shelter open spaces for earthquakes, including storage of emergency materials and preplanned layouts for temporary accommodation. Again, see the above study on emergency shelters and open spaces (https://pmc.ncbi.nlm.nih.gov/articles/PMC7443315/), which includes case studies from China. These designated open spaces, used only during emergencies while serving as ordinary parks in normal times, match the intended use of emergency:camp_area=*.

United States and Europe

Evacuation and sheltering manuals differentiate between short-term assembly areas and longer-term shelter locations where evacuees can receive accommodation and services (gyms, community centres, but also prepared open spaces). For instance, see Planning Considerations: Evacuation and Shelter-in-Place – Guidance for State, Local, Tribal and Territorial Partners and local planning documents such as the Orange County Housing Opportunities Manual which addresses use of sites for emergency sheltering (https://ocds.ocpublicworks.com/sites/ocpwocds/files/import/data/files/43715.pdf). The latter correspond to larger areas that can host tents, first aid, water, food and basic support, which aligns with emergency:camp_area=* rather than a single building tag.

emergency:staging_area=rescue

Australia

Operational manuals of emergency services define the Staging Area as a designated location where response teams, vehicles and equipment assemble before being deployed, often using large parking lots or sports fields that are activated only during incidents. For example, the Australian Capital Territory Emergency Services Agency procedure 2.3 Establishment Of Staging Area (https://esa.act.gov.au/sites/default/files/2020-01/2.3-Establishment-Of-Staging-Area.pdf) describes requirements for such areas. This concept is directly mapped by emergency:staging_area=rescue, representing areas used for assembling rescue resources prior to deployment.

Canada

Municipal Emergency Response Plans specify staging areas where resources are concentrated and coordinated, typically choosing large open spaces such as arenas, sports complexes or parking areas that can safely host emergency vehicles and personnel. An example is the Town of Midland Emergency Response Plan (https://www.midland.ca/media/yqlghxla/emergency-response-plan.pdf), which lists and defines staging areas in the municipal territory. These planned sites correspond to emergency:staging_area=rescue as designated rescue staging locations.

United States

Logistics documents describing Logistics Staging Areas (LSA) present them as central hubs where teams, vehicles and materials are gathered and organized before distribution to affected areas. See for instance Logistics Staging Areas (LSA) and State Points of Distribution by Missouri State Emergency Management Agency (http://sema.dps.mo.gov/docs/programs/LRMF/SPODS.pdf). Such LSAs are a clear real-world example of emergency:staging_area=rescue for mapping the operational staging function.

emergency:logistic_entry=rescue

United States (Logistics Staging Areas and Points of Distribution)

Guidance on Logistics Staging Areas and State Points of Distribution emphasises controlled access routes and gates reserved for convoys of emergency vehicles and supply trucks, separate from regular traffic, to ensure safe and orderly flows. The Missouri SEMA guidance on LSAs and SPODs (http://sema.dps.mo.gov/docs/programs/LRMF/SPODS.pdf) explicitly addresses traffic management and access control for these logistics hubs. These specific access points match emergency:logistic_entry=rescue, identifying entrances used primarily for emergency logistics.

United States (evacuation and sheltering guidance)

Evacuation and sheltering planning documents mention dedicated entrances for buses, emergency vehicles and supply deliveries at reception centres, shelters and distribution points, often with separate entry and exit paths for safety and traffic management. For example, Planning Considerations: Evacuation and Shelter-in-Place discusses access and traffic control at shelters and reception facilities. Mapping those logistic gates and controlled access points is precisely the goal of emergency:logistic_entry=rescue.

Tag Info

emergency:waiting_area=*

emergency:camp_area=*

emergency:staging_area=rescue

emergency:logistic_entry=rescue

Features/Pages affected

• Tag:emergency=assembly_point
• Tag:emergency:social_facility=shelter

External discussions

• Italian proposal and discussion: User:AndreaDp271/Protezione Civile Aree
• Community Forum RFC: https://community.openstreetmap.org/t/rfc-proposal-civil-protection-areas-emergency-waiting-area-shelter-area-staging-area-rescue-logistic-entry-rescue

External links

Areas viewer https://andreadp271.github.io/civil_protection_areas_osm/

Comments

Please comment on the discussion page or the Community Forum:

• (RFC) https://community.openstreetmap.org/t/rfc-proposal-civil-protection-areas-emergency-waiting-area-shelter-area-staging-area-rescue-logistic-entry-rescue

Voting

Instructions for voting

• Log in to the wiki if you are not already logged in.
• Scroll back down and click "Edit source" next to the title "Voting". Copy and paste the appropriate code from this table on its own line at the bottom of the text area:

To get this output	you type	Description
I approve this proposal.	{{vote|yes}} --~~~~	Feel free to also explain why you support the proposal!
I oppose this proposal. reason	{{vote|no}} reason --~~~~	Replace reason with your reason(s) for voting no.
I have comments but abstain from voting on this proposal. comments	{{vote|abstain}} comments --~~~~	If you don't want to vote yes or no but do have something to say. Replace comments with your comments.

Note: The ~~~~ automatically inserts your name and the current date.
For more types of votes you can cast, see Template:Vote. See also how vote outcome is processed.

• I approve this proposal. --Ciupava (talk) 22:41, 17 March 2026 (UTC)
• I approve this proposal. --User:AboutVenia (talk) 10:44, 16 March 2026 (UTC)
• I approve this proposal. --Ilbuome (talk) 09:39, 16 March 2026 (UTC)
• I approve this proposal. --SColchester (talk) 10:25, 12 March 2026 (UTC)
• I approve this proposal. --Alessandro Mongardini (talk) 06:41, 10 March 2026 (UTC)
• I approve this proposal. I had troubles in the past mapping these areas --Martinligabue (talk) 13:13, 9 March 2026 (UTC)
• I approve this proposal. --Antonino Faro (talk) 13:42, 9 March 2026 (UTC)
• I approve this proposal. --Giopera (talk) 14:00, 9 March 2026 (UTC)
• I approve this proposal. --Zando 14:41, 9 March 2026 (UTC)
• I approve this proposal. --DF45 (talk) 15:40, 9 March 2026 (UTC)Very usefull in case of large scale disaster where HQ does not have the time to find these informations on all local emergency plans and also if rescue Teams come from foreign countries.
• I oppose this proposal. Has not solved all problems satisfactorily as debated from multiple users. Inventing many emergency:*=* is unscalable, disorganized, messy, and chaotic. man_made=sign + emergency:*=* is obviously wrong, as the sign itself isn't such a facility. -- Kovposch (talk) 17:01, 9 March 2026 (UTC)
• I oppose this proposal. See comment above --Nospam2005 (talk) 21:58, 9 March 2026 (UTC)
• I approve this proposal. I approve, but the tags for signs could be better (reg_ref or similar for type since the sign could also have another ref, and *_area=yes on a node might be misleading) --Gicorada (talk) 12:20, 10 March 2026 (UTC)
• I approve this proposal. --EneaSuper (talk) 14:46, 10 March 2026 (UTC)
• I approve this proposal. --Mfortini (talk) 16:56, 10 March 2026 (UTC)
• I approve this proposal. --George Sears (talk) 12:09, 11 March 2026 (UTC)
• I approve this proposal. --Adiatmad (talk) 04:20, 12 March 2026 (UTC)
• I approve this proposal. --.notmyproblem1 (talk) 10:28, 12 March 2026 (UTC)
• I oppose this proposal. Most of the issues raised haven't actually been resolved --Fizzie41 (talk) 11:16, 12 March 2026 (UTC)
• I oppose this proposal. emergency:waiting_area=yes used for both signs and actual areas makes no sense. It could be emergency:waiting_area_sign=yes Mateusz Konieczny (talk) 06:15, 20 March 2026 (UTC)
• I oppose this proposal. (1) Re-using the same tags for signs and facilities is very inconvenient for data consumers, as several people have mentioned. (2) Unimportant, but the example for New Zealand and Pacific coastal communities is a bit misleading, it mentions a single rare situation. The more common approach to tsunami evacuation can't be modelled with the proposed tags --Kylenz 01:56, 15 March 2026 (UTC)
• I oppose this proposal. I agree with the choice to use multiple emergency:*=* to allow to map an area with multiple roles, if the proposal had included only areas I would vote positively. However the choice to use exactly the same tag for both the area and the sign is problematic for data consumers (the first solutions that come at the top of my mind would be either to create new values for sign=* or to change values to the area tags, for example emergency:waiting_area=sign). Also, it's not clear to me what you mean with "sign code" for ref=*: if it's an ID that identifies the area, then it should be placed on the area. Otherwise, it needs a better description. --Danysan (talk) 23:02, 15 March 2026 (UTC)
• I oppose this proposal. I agree with Kovposch that the proposed scheme is messy and not scalable. I also think these features should be mapped separately, even when this creates duplicate geometries. The "One feature, one OSM element" principle outweighs the arguments in favour of tagging these features on other existing objects. 501ghost (talk) 02:22, 16 March 2026 (UTC)
• I approve this proposal. --Jacopo (talk) 11:57, 16 March 2026 (UTC)
• I approve this proposal. --GiulyR98 (talk) 10:02, 17 March 2026 (UTC)
• I approve this proposal. --Nicola yubo (talk) 11:39, 17 March 2026 (UTC)
• I approve this proposal. --GiovanniPen 12:32, 17 March 2026 (UTC)
• I approve this proposal. ---Max1234-ITA
• I approve this proposal. ---philter