I use iD Editor, which is the most common editor for volunteers.
In iD, managing perfectly coincident polygons (selecting the ‘underlying’ one without moving the top one) is notoriously difficult and error-prone. Asking mappers to maintain a stack of identical polygons is bad practice.
Regarding your point on multiple emergency:*=yes:
Yes, I am attaching multiple attributes. This is standard OSM practice for multi-functional objects.
Example: A recycling bin (amenity=recycling) has recycling:glass=yes, recycling:paper=yes, etc.
Similarly, a multi-role area has emergency:waiting_area=yes and emergency:staging_area=yes.
If I tried to use multiple emergency=... tags (e.g. emergency=waiting_area AND emergency=staging_area), iD would flag a conflict and force me to keep only one. The namespace avoids this technical limitation
1. On emergency:*:
You wrote: “this means a feature activated during disasters”.
Exactly! That is my point. These are parks/parkings that get “activated” as shelters/staging areas only during a disaster. We agree on this definition.
2. On social_facility:
You claim that “institution” includes temporary inflatables or containers.
Can you please link the Wiki source for this interpretation?
The current Tag:emergency:social_facility definition implies a building or established facility providing services. Tagging an empty grass field as a social_facility stretches the definition beyond recognition.
“A designated (safe) place where people can gather… during an emergency or a fire drill.”
Regarding assembly_point:tsunami: The Wiki explicitly warns about misusing this tag. It states:
“About 5700 of the uses… were introduced by an import in Taiwan… The tag emergency=assembly_point is not well chosen for those.”
So the Wiki itself discourages using assembly_point for district-scale shelters, confirming the need for my proposal.
Also, the Wiki defines the scope as “a designated place… within a building or a public place”.
The context of “fire drill” clearly implies a micro-scale (building exit). It does not support the macro-scale of a neighborhood or district-level Evacuation Zone capable of housing thousands of people for days.
Stretching assembly_point to cover a 50-hectare tent camp is technically incorrect.
Your comparison is flawed. Bus tags describe different physical objects (a stop, a route, a bay).
My proposal describes different roles applied to the same physical object.
A much better analogy, as I mentioned, is recycling bins (amenity=recycling).
A single bin can accept multiple materials. We don’t map three overlapping bins. We map one bin with:
recycling:glass=yes
recycling:paper=yes
Similarly, a single park can have multiple emergency roles:
emergency:waiting_area=yes
emergency:shelter_area=yes
This is not “creating a mess”; it is the standard, clean way to attribute multiple functions to a single geometry in OSM.
Not really. A school sports hall isn’t really providing services before the storms come, the school itself is often closed for summer break. The service (of housing people) only happens when an emergency is declared and the staff turn up to run the shelter. I’m not the biggest fan of the emergency:social_facility tagging, but it is the established way to do this.
(I have no objection to an additional “camp” style tag to help manage expectations or to tag places that have minimal staff.)
It doesn’t discourage it, it documents that it has two uses and comments on the ambiguity.
Whether the best way to resolve that ambiguity is with an additional tag to indicate scope or to migrate the key for the larger scale ones emergency to e.g. disaster_response=assembly_point is a matter for debate. They might even fit the definition of the pre-existing emergency=disaster_help_point although that would require discussion with the community that already uses that tag.
A third similar but not quite the same emergency:waiting_area tag with no attributes in common with existing emergency assembly/help point tagging schemes is just going to make things even more confusing in the future.
I read the Taiwan paragraph as commenting on dedicated vs adapted use, ie they would have to be a emergency:emergency=assembly_point to follow other emergency:*= disaster-time features on normal features. =assembly_point is only “de facto”, but assembly_point:*= has been voted to include various area-wide evacuations. Proposal:Assembly point:purpose - OpenStreetMap Wiki
What I thought is assembly_point= / assembly_point:*==building vs =site vs =local vs =regional (are there =national ?) can be used to distinguish them. However, this is complicated by assembly_point:tsunami= being voted for height, which needs to be refined.
On social_facility vs. Open Ground**
You compared these areas to a school sports hall that is inactive until the storm comes.
However, there is a key difference:
A sports hall, even when closed, already provides a physical service: it has walls and a roof. It is physically a “facility.”
The objects I am mapping are flat open ground (parks, parking lots) with absolutely no infrastructure.
Calling a bare patch of grass a social_facility is semantically confusing.
This brings me to your key point:
“(I have no objection to an additional ‘camp’ style tag to help manage expectations or to tag places that have minimal staff.)”
This is exactly what my proposal does.
Since camp_site is blocked (tourism), and social_facility implies a building/structure, emergency:shelter_area is the logical implementation of the “camp-style” tag you acknowledged is needed for places with no pre-existing infrastructure.
2. On assembly_point and Alternatives
You suggested resolving the ambiguity by using subtags (e.g., indicating scope), migrating keys, or using disaster_help_point.
The “Clean Slate” Reality
To be honest, if we were designing OSM from scratch today, the cleanest solution would indeed be a single “Mega Tag” (e.g., emergency=gathering_point) with specific subtypes for assembly, waiting, and help points. That would be the architecturally perfect solution. However, we have to deal with reality. emergency=assembly_point is used on over 200,000 objects. We cannot re-engineer the entire database or break backward compatibility for data consumers by forcing a migration or changing the tag’s fundamental meaning.
Why a new tag is the only pragmatic choice
Since we cannot “clean up” the past by merging everything into a perfect schema, we must avoid polluting the existing tags further.
Forcing it into assembly_point: Adds noise to a tag that consumers expect to be a specific micro-scale object (fire drill point).
Forcing it into disaster_help_point: This tag implies a coordination/relief hub (“Help”), which is semantically distinct from a passive waiting area.
3. Proposal: A “Disaster Response Comparison” Wiki Page
You mentioned that waiting_area is “similar but not quite the same” as disaster_help_point and assembly_point, and you fear confusion.
You are right, the distinction is subtle but critical for safety:
assembly_point: “Go here immediately to be safe from a specific building hazard (e.g. fire).” (Micro-scale, immediate safety).
waiting_area: “Go here to wait for the emergency to pass OR to be transferred to a long-term shelter.” (District-scale, Temporary Holding/Buffer Zone).
disaster_help_point: “Go here to get water/food/medical aid.” (Distribution node, Active support).
Using help_point for a waiting area is dangerous because it implies supplies that might not be there. My proposal includes creating a dedicated Wiki page comparing these tags side-by-side. This will eliminate the confusion you fear and educate mappers on when to use which, ensuring the data is accurate and safe.
4. Pending Item: Staging Area
Finally, regarding your previous suggestion for emergency:staging_area with rescue=yes.
I already replied that I agree with your counter-proposal. You haven’t confirmed this yet. If we are in agreement on this point, please confirm so I can update the Wiki proposal accordingly.
Given the points above, can we agree to move forward with this structure?
here’s the toolong;didntread guy! ping me in any thread!
TL;DR
@AndreaDp271 proposes new emergency:* role tags to map officially designated civil protection plan areas (mostly large outdoor polygons like parks/parking lots) and related entry points: emergency:waiting_area=yes, emergency:shelter_area=yes, emergency:staging_area_rescue=yes, emergency:logistic_entry_rescue=yes.
He argues existing tags (esp. emergency=assembly_point and emergency:social_facility=shelter) don’t cleanly cover planning-level, area-based zones and rescue logistics, and that tagging the area preserves capacity/space info; signage can be mapped as nodes.
@InsertUser pushes back that the existing scheme can already cover it: “facility” can include grounds, emergency:social_facility isn’t strictly building-only, and adding near-duplicate tags increases confusion. If new tags are needed, they should be more intuitive in English and follow established patterns (e.g. emergency:staging_area=rescue or emergency:staging_area:rescue=yes), plus optional capacity-style attributes.
@Kovoschiz strongly objects on data model/format: says the proposal misunderstands emergency:* usage, overuses =yes flags, mixes sites/signs/roads under the same tagging concept, and that tents vs buildings needs explicit attributes or separate mapped features—not a single yes/no role tag.
@dieterdreist rejects “renderer/app confusion” as a justification: keys define meaning, so consumers shouldn’t interpret values without the key.
@Fizzie-DWG notes you can keep the polygon and add nodes for additional emergency functions, but the thread doesn’t fully converge on whether multi-role tagging on the same polygon is the right approach.
This action
This action was made by an human, the text is reviewed by an human but wrote by an AI
The term facility is really quite broad, the OSM social facility tagging is one of the broader uses of it. In my view it would be entirely possible for OSM’s definition of social_facility=food_bank to be run entirely out of the back of trucks that appear a the appointed times. Parks and parking lots are also facilities in the broad sense.
As stated previously the phrase “shelter area” is not a logical term for this[1]. According to the description you’ve provided it’s a emergency camp site. We[2] could shorten that to emergency=camp or disaster_response=camp, but shelter_area suggest a whole bunch of other things far more strongly.
This tag is already used to mean both small scale single building evacuation points and larger scale natural disaster sites. You even quoted the bit of the wiki that points this out.
No more than the proposed waiting_area suggest that help will come to those that wait when it may in fact never arrive.
This is the sort of thing that should be done before a proposal is written, not after a vote is forced.
My intent was more for emergency:staging_area=rescue which would allow for semicolon separated values.
In the view of a sample size of 1 native English speaker (namely me). If there are native EN-GB speakers with differing perspectives I’d be interested to hear from them. ↩︎
for some definition of “we”, this thread is incredibly draining so I probably won’t be involved much longer ↩︎
I see your point that “facility” can be interpreted very broadly, including mobile services like trucks for a food bank.
My worry is that, in practice, most mappers and data consumers read social facility as something closer to a service site with at least some permanent infrastructure or equipment. For civil protection planning I need to make it very explicit that these are just empty open areas in normal times, with no built elements at all, and only become functional when temporary structures are brought in.
That is why I prefer to keep this information in an emergency:* tag instead of stretching the meaning of social_facility even further.
Your comment that, according to my description, these are essentially emergency camp sites is fair.
To reflect that more clearly in the tagging while staying consistent with the existing emergency:* pattern, I would be happy to rename this to emergency:camp_area=yes instead of emergency:shelter_area=yes.
This keeps the “camp-style” meaning you suggested, avoids confusion with tourism=camp_site, and still clearly indicates that it is an area reserved in civil protection plans for setting up a temporary emergency camp (tents/containers).
It is true that emergency=assembly_point is already being used for both small building evacuation spots and larger disaster sites.
However, in many of those larger-scale cases it was used simply because there was no better tag available at the time, not because it is a perfect semantic match.
My goal with emergency:waiting_area is exactly to give mappers a more precise option for those district‑scale, plan‑defined areas, so that new data can be tagged more accurately without having to reinterpret what “assembly point” means.
You’re right to point out the symmetry, but there is a crucial difference in what each tag guarantees:
disaster_help_point = “Go here for supplies/services”. Even if no staff arrives, it still implies that relief goods (water, food) will be available.
waiting_area = “Go here to wait for instructions/transport”. No pre-established supplies/services are guaranteed; people are simply holding position until rescue coordination services arrive (if they do).
This is why the risk of false expectations is much higher with help_point. I will make this distinction crystal clear in the Wiki documentation.
Agreed, the comparison page should have been created earlier - that’s a fair criticism and a lesson learned.
The original proposal already contained a comparison table between assembly_point and waiting_area (and I had explicitly noted the similarity with disaster_help_point). The dedicated Wiki page I mentioned is meant to be a permanent reference page (not just part of the proposal), covering all three tags in detail with examples, to serve the whole community long-term.
I will prioritize creating this page now, before proceeding to voting.
Perfect, agreed on emergency:staging_area=rescue.
This is cleaner and more extensible (semicolons for multiple roles).
I will update the proposal accordingly. Thanks for the suggestion!
P.S. I will even edit emergency:logistic_entry_rescue=* with emergency:logistic_entry=rescue