First I wished there was a better attribute name other than area "type" to better define what the set name is for elements: "impact", "target, "Incident", etc.

Second, there were concerns with the polygon being a dominant contributor to the file size of a CAP message. This was brought up in the Canadian study/paper on "file size". How would introducing more polygons impact the file size, although there is a growing need to indicate both the incident and target locations?

Having said that, would a typical workflow determine the incident location; where the incident would have been reported first through another protocol such as SITREP and that would lead to a CAP "alert/warning" that references the incident message (i.e. SITREP message) which would hold the area "incident" information? Thus, reducing the CAP message payload.

I would compare/contrast this paradigm with others. For example, NWS plans to add a motion description parameter for storms (and perhaps other weather related events) which includes a lat/lon pair (or pairs) demarking the storm location as well as the speed and direction of movement. This is in addition to the alert area polygon we already include in the CAP message.

I see some similarity to issue 16, however issue 16 does not clearly highlight the need to separate between targeting and area affected, so I think a merge may be desired, but i dont think this is a duplicate