Re: [atoca] Next milestone

["Mark Wood" <[e-mail]>]

Hi Guys,

I agree that sticking to a polygon description is best, and that the WGS84
protocol as used in CAP is most appropriate. This is because while the USA
does indeed have FIPS codes to tag political polygons as 'geocodes', many
countries do not, will not, or have completely different methods of
geocoding political polygons. 

For example Canada has been creating its own interpretation of CAP, in which
the FIPS codes and SAME codes are not at all the same, but the WGS84 seems
to be universal. I have not so far spoken to any client other than the USA
that will adopt FIPS, but I have not spoken to any that will not use WGS84.

Actually the only component that really needs to translate from FIPS to
WGS84 is the Aggregator/Gateway system. This is because it needs to apply
policy to the proposed message on the basis of sovereignty of the territory
under the polygon. This in turn is politically based, so the gateway needs
to be able to parse a polygon into its underlying political geocodes to
police the applicable policy. If you don't do this, then you are restricted
to producing polygons only within certain geocodes that have allowed the
sender to transmit. Administering this would become very clumsy! 

However assuming  the gateway has done this, any systems upstream (data
input) or downstream (participating networks of any sort), don't need to
have any awareness of 'political' geocodes. Therefore provided that there is
an approved gateway, only WGS84 is actually needed.

Remember that the only operational CAP model at the moment is the USA
version, but that this will very soon change as other counties adopt their
own variation of CAP.  

Mark Wood.



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Art Botterell
Sent: 25 September 2012 19:52
To: Brian Rosen
Cc: [e-mail]
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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/atoca
> 

_______________________________________________
atoca mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/atoca