Re: [atoca] Next milestone

"Carl Reed" <creed@opengeospatial.org> Tue, 25 September 2012 19:31 UTC

Return-Path: <creed@opengeospatial.org>
X-Original-To: atoca@ietfa.amsl.com
Delivered-To: atoca@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043FA21F897D for <atoca@ietfa.amsl.com>; Tue, 25 Sep 2012 12:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.054
X-Spam-Level:
X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SARE_FWDLOOK=1.666, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb-aI7JEecVG for <atoca@ietfa.amsl.com>; Tue, 25 Sep 2012 12:31:13 -0700 (PDT)
Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3170421F8979 for <atoca@ietf.org>; Tue, 25 Sep 2012 12:31:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 471C99416A; Tue, 25 Sep 2012 15:31:12 -0400 (EDT)
X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net
Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGqOJeuZ8orE; Tue, 25 Sep 2012 15:31:11 -0400 (EDT)
Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id 0BC049413D; Tue, 25 Sep 2012 15:31:10 -0400 (EDT)
Message-ID: <E7978A1A74C14CCF94702F4C4816DCAC@OfficeHP>
From: Carl Reed <creed@opengeospatial.org>
To: Art Botterell <acb@incident.com>, Brian Rosen <br@brianrosen.net>
References: <CABkgnnXJQ25CRw4wVGmvk3tBCKUZGNgei4KOVseFBYJfotxb=Q@mail.gmail.com><1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com><A8BDD10D-479A-4D72-B565-439DD6923F71@brianrosen.net> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com>
In-Reply-To: <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com>
Date: Tue, 25 Sep 2012 13:28:44 -0600
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
Cc: atoca@ietf.org
Subject: Re: [atoca] Next milestone
X-BeenThere: atoca@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <atoca.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/atoca>, <mailto:atoca-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/atoca>
List-Post: <mailto:atoca@ietf.org>
List-Help: <mailto:atoca-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/atoca>, <mailto:atoca-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Sep 2012 19:31:14 -0000

Art

GML changed directions? Not sure what you mean. There is now an OASIS GML 
profile for use in OASIS EM standards. Being referenced in HAVE, xAL, and 
EDXL. Perhaps in the next version of CAP? :-)

Cheers

Carl


-----Original Message----- 
From: Art Botterell
Sent: Tuesday, September 25, 2012 12:51 PM
To: Brian Rosen
Cc: atoca@ietf.org
Subject: Re: [atoca] Next milestone

Funny thing, that... we tried to make the CAP geometries align with GML... 
even has a representative from OGC (Carl Reed) on the OASIS committee when 
we were' specifying it... but then GML changed directions and the CAP spec 
wound up different.  Personally I'd suggest using the CAP syntax, for 
consistency, as that can be switched into GML, KML or whatever easily and 
precisely an application requires.

Yes, ultimately any geocode is really just a shorthand for some polygon. 
Different jurisdictions around the world will have different geocoding 
schemes, and it's hard to assume that every receiving device will be 
familiar with them all... but geometry is universal... or at least 
planet-wide.

- Art


On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote:

> I guess that's my point.  Without more spec, we have interoperability 
> issues.  When you have limited CAP deployment, these can be dealt with by 
> prior arrangement.  We probably can't do that.  I would prefer that a 
> polygon be encoded with GML, which is precise, interoperable and an 
> accepted global standard.  That can be wrapped in a PIDF (an IETF 
> standard) or not, but we need something very interoperable.
>
> Forcing polygons may work in a forward looking sense.   I'm probably 
> convincible that a jurisdictional areas aren't needed, but so many of the 
> alert sources I'm interested in supporting are based on jurisdictions.  I 
> guess just telling them they need to come up with a relatively simple 
> polygon is okay.  Since increasingly, device location is GPS (or 
> equivalent) based, we probably need geo always.
>
> Brian
>
>
> On Sep 25, 2012, at 2:14 PM, Art Botterell <acb@incident.com> wrote:
>
>> 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
>> _______________________________________________
>> atoca mailing list
>> atoca@ietf.org
>> https://www.ietf.org/mailman/listinfo/atoca
>

_______________________________________________
atoca mailing list
atoca@ietf.org
https://www.ietf.org/mailman/listinfo/atoca