Hans, this may be relevant to your discussion.
CAP-CP Rules Beta 0.4, which is about to be published to www.CAPAN.ca/CAP-CP, will read as
follows:
|
Description:
CAP-CP requires a
<geocode> value, and encourages the use of optional <polygon> and
<circle> values. When <polygon> or <circle> values are
present in an area block, the combination of <polygon> and
<circle> values is the more accurate representation of the alert area.
This is contrary to what is currently defined in CAP, which recognizes the
area as the combination of the <geocode>, <polygon> and
<circle> values.
|
|
Notes: The area(s) associated with <geocode> are
often much larger than the targeted alert area, resulting in over alerting.
This rule as defined now supports a more accurate representation of the alert
area, while also supporting CAP-CP’s mandatory inclusion of <geocode>
in a CAP-CP message. System implementers that can support the more accurate
location identification that comes with <polygon> and <circle>
are encouraged to do so. Recipients that intend to process a CAP-CP message
may choose to identify the alert area by the <polygon> and
<circle> elements alone knowing that this does not represent anything
less than the full intended alert area.
|
Cheers,
Doug Allport
Executive Director
Canadian Association for Public Alerting and Notification
(CAPAN)
Doug.Allport@CAPAN.ca
(613) 271-1040 Tel
(613) 271-6208 Fax
(613) 294-4425 Blackberry
www.CAPAN.ca
Attendance: Hans Jespersen,
Gary Ham, Rex Brooks
Since we had light
attendance and Gary had to leave the meeting early, we focused on exploring and
enumerating all the potential options for item #15 on the Issues List.
Item #15 is the requirement
to allow multiple representations of a Target Area (for example both Polygon
and LocCode) and to be able to specify precedence (an ordering) which indicates
which representation is most accurate.
Ways to do this include:
1) Specify that the
precedence be the “document order” in the XML text. – We would have to redefine
the schema to remove the current sequence order restriction - [Gary] expressed
concern that certain parsers reply on sequence order for efficiency (i.e SAX vs
DOM parsers)
2) Use an attribute directly
in the tags (i.e. <polygon precedence=”true”> - This would require
parsing all elements to find which are set to “true” which could confusingly be
set twice or more.
3) Use an attribute in
<target area> (i.e. <targetArea most_accurate=”polygon”> - This
would at least always be in same place and if it where not present, or ignored,
it would match today’s behavior.
4) Add a <MostAccurate> tag: ie:
<TargetArea>
<Polygon>
<MostAccurate>
...
</Polygon>
<Circle>
...
</Circle>
</TargetArea>
5) Add explicit
<primary> and <secondary> container elements
<TargetArea>
<PrimaryRepresentation>
<Polygon>
...
</Polygon>
</PrimaryRepresentation>
<SecondaryRepresentation>
<Circle>
...
</Circle>
<SecondaryRepresentation>
</TargetArea>
6) Specify a set universal
order of accuracy: i.e. <Polygon> is always the best representation, then
<LocCode>, then <Circle>, then <BoundingBox>, etc.
[Hans] expressed problems with any universal ordering because there are clear
cases where the order would be different. For example when the target area is a
state then the locCode is exact and the polygon is an approximation. When the
target area is a plume, then the polygon is a best estimate and the locCodes
are a poor approximation.
Additional discussion
points:
[Gary] Expressed a need to
continue to support unions of multiple target areas.
[Gary] Thought that unions
of different representation types should be supported, i.e. the target area is
a <LocCode> plus a <Polygon>.
--
Hans Jespersen
Principal Systems Engineer
Solace Systems Inc.
2051 Landings Drive, Mountain View, CA
94043
Phone: (650) 924-2670
hans.jespersen@solacesystems.com
http://www.solacesystems.com