This issue may involve multiple polygons – an area may have area warning; impact; polygons; is this issue talking about naming or purposing them. May be similar to what Jakes want to do; and what Steve wants to do with richer data sets.

The original concept was that an Area was the semantic atom of geography, which might be defined in terms of multiple polygons and/or circles as well as (vexed case!) geocodes. We went through some gyrations to provide for intersections, unions and differences of geometry in a way that would be comprehensible to non-GIS-expert alert authors and implementers

So my immediate reaction... leaving aside the whole event-vs-alert ambiguity discussed elsewhere... is that if there's a need for multiple names there's a need for multiple Areas.

Again, the issue of impact vs. warning area needs a high-level discussion. Do we need two different subclasses of Area? Perhaps. But personally I don't see naming individual polygons as particularly useful. (Although as ever I'm willing to hear it explained!)

+1 to the high-level discussion on impact vs warning area

Related to area naming, in the case of multiple <area> blocks, it would be quite useful to define a single field that succinctly summarized all of the areas.

For example, we frequently see alerts with a long list of <area> blocks that correspond to existing political boundaries (zip codes, counties, warning zones). But there's no place to understand that long list is "the New York metro area" or some such, and we go through quite a bit of gyrations and guessing to extract that.

I can move that to a new issue if that makes more sense.

Isn't that the <areaDesc> field?

Quoting from Art's comment

"if there's a need for multiple names there's a need for multiple Areas."

Indeed, multiple areas with multiple names happens very frequently in practice, just like you say. My comment noted that, in this case, it is still useful to have a single string that summarizes all the separate area blocks.

By the same token, if the multiple areas can be described by a single label, they probably should be a single Area. In other words, I'm thinking we should look to help originators make better use the existing <areaDesc> field before asking them to populate another, potentially redundant element.

And of course having redundancy or semantic overlap among fields is almost always a bad thing in the structured-data context because it raises the problem of what to do if the two values conflict.

From https://www.oasis-open.org/apps/org/workgroup/emergency-cap/download.php/53893/Aug18-2014-meeting-notes.doc

Jacob reviewed the issue and the request for naming individual polygons within an area block. Steve discussed the comments he had submitted and how he is interested in the opposite, something that describes all area blocks. A concern was raised regarding the original submitter, Norm Mueller, and his ability to clarify the request. Jacob noted that there was no contact info available to follow up with him. The group discussed the merits of labeling each polygon and agreed it wasn't necessary. The group also agreed that if the original submitter had further comments to the issue, he could follow up later during any public review.

The motion to resolve issue 10 as “no action needed” and close it in JIRA, was put forward. Doug moved and it was seconded by Steve. All agreed with the motion and it passed.

Note https://issues.oasis-open.org/browse/EMERGENCY-29 separately deals with the comment around defining a single field that succinctly summarized all of the areas.