Notes on CAP from ESRI Data Modeling Team

[Bill Schroeder <bschroeder@esri.com>]

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