Re: [atoca] Next milestone

Art Botterell <> Tue, 25 September 2012 18:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02F2721F8827 for <>; Tue, 25 Sep 2012 11:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CdO77NNOrsBT for <>; Tue, 25 Sep 2012 11:15:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 61A9921F861E for <>; Tue, 25 Sep 2012 11:15:00 -0700 (PDT)
Received: by padfb11 with SMTP id fb11so2404071pad.31 for <>; Tue, 25 Sep 2012 11:15:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=/IV8IFccwFtQgI71iU21yK7WsD1qy33Qczf9Ua1SF2M=; b=yOYykeoWIRODbyhMGZl2mCy02FFeDG6f7k0BYLM5yFFlHC4dkww81XJzFWBlJm7Rb5 8xS8Ddwkn2MpEf6VnDaEJ7F8lA6aOcf+M3HVci4fkHZcINhv8OhGlZTF8cXmXZ5ZQmeu FswbjhMoSAjBpO7q+jo9lhh22hnTqZEBhoeNezRE+JtUSj2L6B+MidnM2gteasMAdXFl /YLWx9FocZSMb1025mYEa5SbegDTFfznct/2bvOHCWBn9QfBKNaW4+X31A4bf3aXra+E 6FvHBGDvAPrDt1SJfpIBoyVI7Fcx9Vayh7S+7j0Czh/CFCDJVcQb4Lhoa/gFm/eBW4XH t5MQ==
Received: by with SMTP id qj5mr47741216pbc.132.1348596900161; Tue, 25 Sep 2012 11:15:00 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id wn1sm666935pbc.57.2012. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 11:14:59 -0700 (PDT)
Sender: Art Botterell <>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1283)
From: Art Botterell <>
In-Reply-To: <>
Date: Tue, 25 Sep 2012 11:14:55 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
X-Mailer: Apple Mail (2.1283)
Subject: Re: [atoca] Next milestone
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Sep 2012 18:15:01 -0000

On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote:
> For example, how do you target "Allegheny County, PA, US"?  A text line?  With what syntax?  A polygon?

In CAP the recommended presentation would be a polygon, a line of text that might well read "Allegheny County, PA, US" and optionally a <geocode> value, which in the US would typically be a FIPS-based code conforming to the old Emergency Alert System standard (in this case, "042003").

There are a few subtleties here.  First, most hazard footprints don't align very well with political boundaries, so it's actually considered best practice NOT to address an alert to everyone in a political jurisdiction if better resolution is available, which increasingly often is the case.  (This is probably the biggest challenges in the transition from the legacy EAS and Weather Radio systems in the States and the newer CAP-based IPAWS framework.)

Second, but related to the first... there is at present no strict limit on the number of vertices in a polygon in CAP.  Generally this hasn't been a problem, as both manual and model-derived (e.g., from a hazardous materials "plume model" software) polygons tend to be relatively simple.  However, if one uses a political jurisdiction as the target area and if, as often is the case, that jurisdiction is defined at least in part by a waterway or water body, then at least part of the "true" polygon will be fractal in nature and the number of vertices used to represent it becomes an implementation decision.  

In such cases conversion from GIS geometries developed for other purposes can, at least in theory, produce very lengthy polygon description strings.  Some degree of polygon simplification, manually or by means of a "convex hull" calculation, may be helpful in such situations; fortunately those can be calculated ahead of time.  A common guideline and a requirement of the IPAWS profile in the U.S. is that a polygon be limited to 100 vertices.  Again, this is largely a theoretical concern, and I'm not aware of any case where this has actually been a problem.

And third, of course, there's quite a bit of variety in how polygons get represented as strings.  Latitude first and then longitude, or the reverse "x,y" order?  Commas between the coordinates and spaces between the pairs, or vice versa, or some other delimiters?  All such representations are ultimately equivalent (at least until we drill down to the level of whether we're using the increasingly common GPS-standard WGS84 datum or some model of the precise shape of the Earth.)  But it's important to be clear which format is being used and to remember of convert as necessary, e.g., between CAP and KML.

The CAP spec deprecates the use of geocodes (arbitrary string designators) without also providing the corresponding geometry (polygon), since to do otherwise is to assume that the receiving device knows every possible geocoding scheme it might ever encounter, which in an open global system is probably infeasible.  Indeed, ideally we might have done without geocodes entirely, but back-compatibility with legacy systems (and the comfort of some non-GIS-savvy programmers who understood string-matching but were uncomfortable with things like point-in-polygon algorithms) dictated their inclusion.

And the text areaDescription field is defined merely as "human readable" so it can be as concise or as extensive as circumstances dictate.  However, where multi-lingual alerting is required it tends to be kept short to facilitate translation.

-  Art