MHonArc v2.5.0b2 -->
emergency message
[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:emergency@lists.oasis-open.org>emergency@lists.oasis-open.org
>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]