[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-gis] Notes on CAP from ESRI Data Modeling Team
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]