[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Geospatial issues (was Re: [emergency] CAP-related Comments)
In addition to supporting Carl's comments below, I should point out that both the lat/lon order and digital-degree format questions are addressed in the Implementation Notes, which currently appear as Section 3.3 within the specification document. - Art At 11:56 AM -0600 10/15/03, Carl Reed wrote: >Walid - > >In terms of your identified issues WRT geospatial: > >Issue 1: Well, treat it as it is - no data. Could return an >exception to the sender, but it is possible the sender does not have >either geocode information or the ability to process geometry. > >Issue 2. In an informal correspondence with Art, I spoke a bit about >the use of WGS 84 and EPSG code (in terms of section 3.3.1). In the >mapping and geospatial industry, the de-facto default for expressing >coordinates in WGS 84 is lat/long (y,x). If the EPSG code and >normative database is used, the coordinate order is explicitly >specified by the EPSG database as lat/long. Perhaps we simply need a >note in the document in section 3.3.1. > >Issue 3. Why restrict in any way? As long as it is not mandatory, >one can always insert a <null> for this field. Just need to clarify >this in the document (a sentence or two). I would actually like it >see it as very flexible as there are many normative vocabularies for >geocodes/gazetteer in the world. FYI, in the GIS world, geocode >typically means an address and geocoding is the process of >transforming an address into an (ax,y) coordinate. A >gazetteer takes as input a place name or landmark and returns >metadata and at a minimum a point geometry. I am not suggesting >major changes now - just some clarification in the current document >and perhaps increased flexibility in the future. > >Issue 4: I am not sure this is an issue. If the server provides a >geocode but the client cannot process, is there really an issue? If >the geometry (polygon/circle etc) is known to be WGS 84 and lat/long >a client could still accept this data, process it, and render it on >some device. Now, if the client cannot process either a geocode or >the geometry, well that is different situation. I am not sure we can >solve that one! > >Issue 5: As I mentioned above, if EPSG is used as your normative >reference, then the coordinate order AND coordinate expression are >specified in the EPSG database. There are 2 EPSG codes (database >entries) for WGS 84. The original database entry specified DD MM >SS.SS. The new version of the database (out soon) will also specify >a second entry for WGS 84 that has a coordinate expression of >decimal degrees. This was done to meet the requirements of the OGC >membership. > >Regards > >Carl > > >----- Original Message ----- >From: <mailto:WRamadan@blue292.com>Walid Ramadan >To: <mailto:firstname.lastname@example.org>email@example.com >Sent: Tuesday, October 14, 2003 1:16 PM >Subject: [emergency] CAP-related Comments > >CAP-RELATED COMMENTS >AS OF 10/13/2003 > >All: > >The following is a list of comments/issues that I compiled from a >variety of sources. For the most part, comments were collected from >these sources: > >* Review of the OASIS CAP-Interop monthly archives at >* Comments that I received directly from TC and Sub-Committees' members >on or before 10/13/2003. >* EM TC comments after the internal "format" (or "intent") test. > >As I went through these comments it became apparent that they could be >triaged into several buckets. These buckets are the following: > >a) Geospatial-Related (Issues 1 through 5): Questions and comments >around how CAP supports geospatial information. The result of this could >be anything from adding geo-specific "References" or maybe a section on >"How to Use Geospatial Data". > >b) Transformations (Issues 6 and 7): Questions and comments around how >to map/transform CAP into other formats, like other XML standards, >text-to-speech, ASN-1, etc. While this is mostly for backwards >compatibility with existing applications, standards, products, services, >etc., it can also be hugely beneficial for the future as well. Some >influence should be considered from issues 9 and 28 as well. > >c) Transport (Issues 8 through 11): Questions and comments around how to >properly exchange CAP messages. This is where the inline binary, Web >Service, encryption, authentication, etc. stuff falls into place. Need >to decide if this should be part of the existing specification (means we >have to go back to Working Draft), or should it be addressed in a >separate document that focused just on transport (current focus of TC). >Some influence should be considered from issues 14, 15, and 28 as well. > >d) System-Specific Uses (Issue 12): Questions and comments around how >system specific things should be communicated within CAP. For instance, >where it is "safe" to return a system-specific error code that is not >standard across all uses of CAP? > >e) Implementer's Guide (Issues 13 through 15): These are things that >seem to be most appropriately addressed in the Implementer's Guide that >is to be written per our charter. It is necessary to help implementers >understand how to support CAP and use it in various environments. Some >influence should be considered from issues 9, 10, and 28 as well. > >f) Unsure (Issues 16 through 21): This is a collection of issues that >require discussion to determine their relevance for inclusion in the CAP >standard > >g) Editorial and Ambiguity (Issues 22 through 28): These are places >where the spec just doesn't seem to be clear on what the TC intents. >Also, places where there could be some editorial clarification that >doesn't change the spec. > >Here are the details of these buckets. > >[GEOSPATIAL]---------------------------------------------------- >1. How to treat an <area> with no geospatial or <geocode> elements in a >CAP message? How best to define <geocode>? Should <geocode> be limited >to FIPS, SAME, and zip code? > >2. Spec Document is silent on the format of polygons coordinate pairs: >should it be in long/lat order or lat/long? > >3. Geographic targeting codes: The <geocode> element, which was included >to provide backward compatibility with existing systems (notably EAS and >NOAA Weather Radio, but also many local systems) also adds a bit of >complexity. It seems possible that in an ideal world all areas would be >in pure geospatial terms (<polygon> and <circle>) but that may be a leap >too far ahead of the current state of the art to allow update of the >standard. In the meantime, one suggestion has been to restrict the use >of <geocode> to certain well-known coding schemes... although it's been >argued that doing so could create a barrier to adoption in existing >systems that use their own predefined alerting or response zones. > >4. How to cover cases where the sender doesn't have GIS or <geocode> >data readily available? > >5. The interface spec will have to declare what representation format it >wants for values in degrees. If it wants geographic data supplied in >decimal degrees, then it should state that; if it wants it ><sign>DD.MMmmm, then it should make that clear. Alternatively a separate >solution would have to be designed if multiple representation formats >are permitted. > >[TRANSFORMATIONS]---------------------------------------------------- >6. Protocol is too vague to allow for automated mapping of CAP messages >into other, existing systems. How to address the issue of automatically >translating a CAP interface in the case of specialized pre-existing >alerting and warning systems? > >7. How to support captioning and text-to-audio applications? > >[TRANSPORT]---------------------------------------------------- >8. How to reconcile characteristics of a certain transport network with >the capabilities of interoperability standards such as CAP? A much more >intelligent architecture than currently provided for routing is >necessary. > >9. Compatibility with existing systems. > >10. Application of CAP in broadcasting (one-way communication medium). >CAP must state exactly how one-way communication media should embed URI >referenced data within the alert message. Current CAP specs rely on the >ability of the receiving device to retrieve binary content, which is >impossible over a one-way broadcast link. Proposed solution is to >provide an explicit optional mechanism for including binary content >encoded as text within CAP XML message, accompanied by restrictions on >when that option should be used. > >11. From a standards perspective, what is the correct way to process and >therefore support CAP messages? Is there enough information in the CAP >specifications to tell target implementers how to implement the standard >and share CAP alerts? > >[SYSTEM-SPECIFIC >USES]---------------------------------------------------- >12. Addition of fields to CAP in order to allow the receiving device to >generate an EAS activation based on a CAP message. > >[IMPLEMENTER'S >GUIDE]---------------------------------------------------- >13. Categorization of threats: The SC having tried unsuccessfully to >locate or devise a taxonomy for threats which satisfied them as being >both broad enough and specific enough to be useful in automated >processing in all-hazards applications, the current committee draft has >the <event> element as optional. Some implementers have expressed a >desire for a reliable (i.e., required) way to categorize messages >according to threat. > >14. How to support attachments (audio files, images, etc.)? Must the CAP >message always be in a SOAP message to transmit attachments? Current CAP >spec offers no specifications as to how binary representations of rich >presentation media can be transmitted over broadcast media. > >15. CAP Alert content and the RSS feed format. More generally, the idea >of getting a "short list" of alerts to see before requesting the whole >alert. > >[UNSURE]---------------------------------------------------- >16. Categorization of responses: The committee draft doesn't attempt to >encode responses into categories, but some implementers have expressed a >desire to be able to automatically slot the recommended response ><instruction> into one or more machine-readable (i.e., coded) >categories. Should this be part of the current CAP or future versions? > >17. ISO code royalty: The current spec provides for use of ISO language >codes to identify multilingual versions. ISO has recently asserted an >interest in collecting royalties for use of those codes (among >others)... this is a subject of debate internationally >(<http://xml.coverpages.org/ni2003-09-20-a.html>http://xml.coverpages.org/ni2003-09-20-a.html). >Unless this issue is >resolved very shortly, some disclosure of this issue probably needs to >be included in the specification document. > >18. Name attributes in schema: Anonymous data types seem to cause >troubles with some parsers. It's been suggested that the schema ought to >provide explicit name attributes in <simpleType> declarations. Related >to the same question, should these attributes be declared globally >rather than locally? Looking at the items, they could certainly be >reused in other parts of the spec, and could be imported to other specs >as well. > >19. The existing CAP spec is not really a protocol - it is a format. It >should really be referred to as Common Alerting Format, and potentially >have a sibling standard called Common Alerting Transport - together they >create the Common Alerting Protocol. > >20. Units of Measurement: The OCG has a document (based on ISO) that >provides an XML schema for expressing UoM in a consistent and easily >interpretable (processing) manner. The CAP group might consider using >this OGC recommendation. > >21. "area" Element and Sub-elements: As with Info element and Resource >element, it would be nice to have an optional slot for a URL/URI (such >as to an http request - like an OGC WMS request or a repository of >additional spatial information). What is the purpose of the additional >spatial information? > >[EDITORIAL and >AMBIGUITY]---------------------------------------------------- >22. Having multiple blocks within a single message as opposed to >different messages with single blocks in multiple messages and its >relation to the "rule of primacy." > >23. Improvements can be made to the general schema design. For example, >there is no common format describing "altitude". If such a format is >available, we should define the schema (using the <restriction> and ><pattern> elements) to support it. "string" leaves it wide open. > >24. Use Cases and Examples: They should be in the same section of the >document. More importantly, the examples do not speak to the use cases >listed. > >25. Editorial comments: The Data Dictionary section does not provide for >SHOULD, MAY, MUST guidelines for implementers, which causes ambiguity. >"eventCode" is a good example. > >26. CAP makes heavy use of the word "warning", which seems odd given it >is the Common Alerting Protocol. Should it say alerting instead? What is >the difference between an alert, a warning, and a notification? Document >should be consistent in the use of these terms. Document should also >define those terms in order to clarify their use. > >27. elementFormDefault = "qualified". Document should mention why. > >28. Should CAP be a public warning protocol only or also be used for >targeting messages between entities? In the latter case, what fields >should be designated mandatory in order for the recipients to understand >that the messages was/was not intended for them? The use of text fields >and fields designated as optional represent limiting factors. > >Walid > > >To unsubscribe from this mailing list (and be removed from the >roster of the OASIS TC), go to ><http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]