Re: [emergency-gis] Notes on CAP from ESRI Data Modeling Team

[Art Botterell <acb@incident.com>]

Bill -

Thanks for those notes.  A few comments in advance of tomorrow's call:

>1) From a modeling standpoint, any time I see something like "area 
>can have multiple area polygons" it seems overly-simplified to me. 
>There are usually pieces of information about each polygon that we 
>might be interested in...

Your concern makes sense, of course, but I think it might be 
addressed in the larger structure of the CAP message.  For example, 
should the information differ from shape to shape, the appropriate 
response might be to include multiple <info> blocks in the <alert>, 
each <info> including the respective <area>(s).

>  For instance, the current model allows for multiple 
>polygon/radius/geocode values but it does not permit a an "area 
>description" for each of these values.

In cases where that's necessary one could use multiple <area> units, 
each with its own description.

>In practice people may find that they need additional information 
>about each "area", so they might want to just have multiple area 
>objects with their own descriptions and a constraint to have only 
>one polygon/radius/geocode for each "area" object.

We used to impose that constraint, but it led to having a bunch of 
redundant <area> and </area> tags in those cases where the target 
(and described) area is simply the union of several disjoint polygons 
(e.g., NWS forecast "microclimate" zones.)  By removing the 
constraint we tried to allow a more concise representation when 
possible, while retaining the option of offering separate <area> 
elements when that's warranted.

>It might also be useful to have a sequence number or something in 
>the case of multiple geometric representations. As an exmaple, one 
>alert area might describe a stadium, another alert area might 
>involve the location of a specific incident at the entrance to the 
>stadium, another alert area might be the geocode address for the 
>stadium for routing purposes.

Hmmm... seems like if these are distinct areas with different 
significances they'd be in distinct <info> blocks.  Otherwise, the 
target is just the union.  (And I think we don't really want to 
encourage the building of systems that use <geocode> for routing, 
since that pushes the requirement for look-ups from a single sender 
to many, many recipients, thus complicating implementation and 
imperiling interoperability.)  But please say more about how such an 
explicit sequence number might be used.

>Overall I find the class names info and area to be too general and 
>they will not be easy to understand. Maybe even "alert info" and 
>"alert area" would be better.

This is that semantics/syntax thing again, I think.  We've tried to 
avoid confusing the two by not encoding message structure (syntax) 
into element names (semantics).  While currently the <info> and 
<area> complexes only occur within an <alert> structure, if we want 
to preserve the option of reuse we might not want to define them as 
somehow exceptional and unique to the <alert> message context. 
Unless they truly are, of course.

>2) A general caution that although we are using xml we should be 
>careful to check class and property names to make sure they are not 
>SQL Reserved words. This is not critical but it can simplify 
>implementation for the programmers/system builders. It looks to me 
>like the current model has no problems, although it looks like 
>"type" is a PL/SQL reserved word -- that's a minor issue that I 
>would not worry about.

That's a good point, I think.  We'd tried to make things as simple as 
possible... but if we've made them more so, we may need to back up.

>3) I think at a physical level they should handle names with or 
>without spaces. Again, this works fine in xml to have spaces, but 
>many times this data will pass into/out of DBMS systems and most 
>will not permit spaces in the table names and attribute names. I 
>think from a conceptual and general level that spaces are the best 
>way to go, I would just suggest that systems built around this 
>should permit xml datasets with or without spaces in the names to 
>simplify things for implementaters. In either case, the spec should 
>be clear about the rules for spaces in the names. It's not a big 
>burden as long as the rules are well understood.

I don't think we've got any spaces in any of our element names 
currently... but then, I didn't think XML allowed that.  But I may 
have missed your point here... could you please expand on that (using 
spaces if you like ;-)?

Thanks!

- Art


At 6:41 AM -0700 6/16/03, Bill Schroeder wrote:
>Folks the following are comments from our Data Model team in 
>Redlands on the CAP format.
>
>
>
>Concern:
>
>1) From a modeling standpoint, any time I see something like "area 
>can have multiple area polygons" it seems overly-simplified to me. 
>There are usually pieces of information about each polygon that we 
>might be interested in. For instance, the current model allows for 
>multiple polygon/radius/geocode values but it does not permit a an 
>"area description" for each of these values. In practice people may 
>find that they need additional information about each "area", so 
>they might want to just have multiple area objects with their own 
>descriptions and a constraint to have only one 
>polygon/radius/geocode for each "area" object. It might also be 
>useful to have a sequence number or something in the case of 
>multiple geometric representations. As an exmaple, one alert area 
>might describe a stadium, another alert area might involve the 
>location of a specific incident at the entrance to the stadium, 
>another alert area might be the geocode address for the stadium for 
>routing purposes.
>
>
>
>Overall I find the class names info and area to be too general and 
>they will not be easy to understand. Maybe even "alert info" and 
>"alert area" would be better.
>
>
>
>Minor Comment(s)
>
>
>
>2) A general caution that although we are using xml we should be 
>careful to check class and property names to make sure they are not 
>SQL Reserved words. This is not critical but it can simplify 
>implementation for the programmers/system builders. It looks to me 
>like the current model has no problems, although it looks like 
>"type" is a PL/SQL reserved word -- that's a minor issue that I 
>would not worry about.
>
>
>
>3) I think at a physical level they should handle names with or 
>without spaces. Again, this works fine in xml to have spaces, but 
>many times this data will pass into/out of DBMS systems and most 
>will not permit spaces in the table names and attribute names. I 
>think from a conceptual and general level that spaces are the best 
>way to go, I would just suggest that systems built around this 
>should permit xml datasets with or without spaces in the names to 
>simplify things for implementaters. In either case, the spec should 
>be clear about the rules for spaces in the names. It's not a big 
>burden as long as the rules are well understood.
>
>
>
>
>
>
>
>William (Bill) Schroeder
>
>Homeland Security Industry Solutions Mgr.
>
>ESRI
>
>8620 Westwood Center Drive
>
>Vienna, Virginia 22182
>
>703 506-9515
>
>