Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: EDXL-CAP
    • Labels:

      Description

      alert.info.area: Is there a need for geometric shapes not currently supported (other than polygon/circle)?

        Attachments

          Activity

          Hide
          amancusogoogle Tony Mancuso (Inactive) added a comment -

          Larger issue is do we make everything into GML (like EDXL). Use EDXL GML profile. Will there be people left out. Some people will like the current simplicity. May be time to listen to the argument in favor of GML (it's pulled into NIEM and in EDXL). Time for another look? There will be global feedback; perhaps both approaches (like Canada). See Issue 15.

          Show
          amancusogoogle Tony Mancuso (Inactive) added a comment - Larger issue is do we make everything into GML (like EDXL). Use EDXL GML profile. Will there be people left out. Some people will like the current simplicity. May be time to listen to the argument in favor of GML (it's pulled into NIEM and in EDXL). Time for another look? There will be global feedback; perhaps both approaches (like Canada). See Issue 15.
          Hide
          acb Art Botterell (Inactive) added a comment -

          The question was always whether the relative complexity of GML was justified by whatever was the benefit. Of course GML is a lot more mature now, and familiar to more software implementers, but my personal sense is that the requirement for it in CAP is still more political than practical. I'm not sure the actual issuers of alerts really care about this... very few of them appear to be anywhere near exhausting the flexibility and expressiveness already available in the simplified geometries we have.

          Because this would be a fairly profound change in how geospace is represented in CAP I'd suggest that this be done in CAP 2.0 but perhaps not in 1.3. (As mentioned elsewhere I think there might be a case for doing both a highly compatible 1.3 and a fundamentally new 2.0 more-or-less in parallel.)

          Show
          acb Art Botterell (Inactive) added a comment - The question was always whether the relative complexity of GML was justified by whatever was the benefit. Of course GML is a lot more mature now, and familiar to more software implementers, but my personal sense is that the requirement for it in CAP is still more political than practical. I'm not sure the actual issuers of alerts really care about this... very few of them appear to be anywhere near exhausting the flexibility and expressiveness already available in the simplified geometries we have. Because this would be a fairly profound change in how geospace is represented in CAP I'd suggest that this be done in CAP 2.0 but perhaps not in 1.3. (As mentioned elsewhere I think there might be a case for doing both a highly compatible 1.3 and a fundamentally new 2.0 more-or-less in parallel.)
          Hide
          eliotchristian Eliot Christian (Inactive) added a comment -

          It seems to me that GML is very complex and overkill for the needs of CAP.

          Perhaps in CAP 2.0 consideration should be given to adopting GeoRSS-Simple ( http://www.georss.org/simple ). This provides point, line, polygon, box, and circle.

          Looking at the GeoRSS-Simple example, though, we may need a provision that says beyond a small set of subelements any other subelement tag or value that is not understood (e.g., "floor 2") can be safely ignored.

          I also note that GeoRSS-Simple has elevation in meters. Perhaps this could help to address a long standing complaint that CAP uses feet for ceiling and altitude rather than meters?

          Show
          eliotchristian Eliot Christian (Inactive) added a comment - It seems to me that GML is very complex and overkill for the needs of CAP. Perhaps in CAP 2.0 consideration should be given to adopting GeoRSS-Simple ( http://www.georss.org/simple ). This provides point, line, polygon, box, and circle. Looking at the GeoRSS-Simple example, though, we may need a provision that says beyond a small set of subelements any other subelement tag or value that is not understood (e.g., "floor 2") can be safely ignored. I also note that GeoRSS-Simple has elevation in meters. Perhaps this could help to address a long standing complaint that CAP uses feet for ceiling and altitude rather than meters?
          Hide
          shakusa Steve Hakusa (Inactive) added a comment -

          From https://www.oasis-open.org/apps/org/workgroup/emergency-cap/download.php/53827/Aug11-2014-meeting-notes.doc

          Eliot and Jacob discussed adding donut geometries in alerts. There is a precedence order provided by CAP vs using a donut geometry, in order to alert to a shelter in place for a wide area versus evacuate a smaller inner area. Winding order was raised as a concern and a problem for interoperability. Mike Gerber and Norm discussed polygons that follow a river for a flood warning versus a line or polyline. Eliot and Jacob discussed how points are used in CAP. Eliot described how a circle with a radius of 0 applies to an earthquake alert and how rounding of the lat/lon values is a factor. The group agreed that no further shapes, such as a point, line, or multi-polygon (donut) are needed for area in CAP.

          The motion to mark issue 14 as “no action needed” and close it, was put forward. Eliot moved and it was seconded by Norm. All agreed with the motion and it passed.

          Show
          shakusa Steve Hakusa (Inactive) added a comment - From https://www.oasis-open.org/apps/org/workgroup/emergency-cap/download.php/53827/Aug11-2014-meeting-notes.doc Eliot and Jacob discussed adding donut geometries in alerts. There is a precedence order provided by CAP vs using a donut geometry, in order to alert to a shelter in place for a wide area versus evacuate a smaller inner area. Winding order was raised as a concern and a problem for interoperability. Mike Gerber and Norm discussed polygons that follow a river for a flood warning versus a line or polyline. Eliot and Jacob discussed how points are used in CAP. Eliot described how a circle with a radius of 0 applies to an earthquake alert and how rounding of the lat/lon values is a factor. The group agreed that no further shapes, such as a point, line, or multi-polygon (donut) are needed for area in CAP. The motion to mark issue 14 as “no action needed” and close it, was put forward. Eliot moved and it was seconded by Norm. All agreed with the motion and it passed.

            People

            • Assignee:
              Unassigned
              Reporter:
              amancusogoogle Tony Mancuso (Inactive)
            • Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: