RE: Some comments/thoughts on EDXL) Distribution Element, v. 1.0

First, apologies for not having brought these discussion points up before. Have been busy dealing with OGC standards facilitation activities :-)

Have been browsing Emergency Data Exchange Language (EDXL) Distribution Element, v. 1.0, Committee Draft, 28, December 2005. A couple of (minor?) points:

1. Page 26, line 22. "geo-spatial" should be "geospatial". Common use is no "-".

2. In targetArea section, WGS 84 is referenced. I would encourage an informational note akin to what is in CAP providing a more thorough description and perhaps a reference, such as the definition NGA WGS-84 document. The CAP 1.1 informational section states, "Geographic locations in CAP are defined using WGS 84 (World Geodetic System 1984), equivalent to EPSG (European Petroleum Survey Group) code 4326 (2 dimensions). CAP does not assign responsibilities for coordinate transformations from and to other Spatial Reference Systems."

3. For polygon, there is the statement that a "space delimited series of . . ." and then the example includes commas. I would suggest that the correct phrasing should be "space seperated list of latitude-longitude pairs, with each pair separated by whitespace" or something along those lines. I would discourage commas as ISO, W3C, and the OGC have all determined that space separated/white space is best practice. I know that this is also a bit different that CAP, which is comma delimited. I would propose that this also be changed. Finally, check out georss.org - Simple. The georss encoding proposal is the result of a collaboration between RSS folks, W3C members, OGC members and some input from the IETF.

4. For circle and polygon, the definition of latitude/longitude is ambiguous. CAP 1.1 has an informational section on the semantics of expression. For example, in the EDXL document, there is no guidance as to whether lat/long is expressed as decimal degrees or <degrees, minutes, seconds>. The best semantical definition I have seen for describing the semantics of lat/long usage on a global basis is (and derived from ISO):

Values for latitude and longitude shall be expressed as decimal fractions of degrees. Whole degrees of latitude shall be represented by a decimal number ranging from 0 through 90. Whole degrees of longitude shall be represented by a decimal number ranging from 0 through 180. When a decimal fraction of a degree is specified, it shall be separated from the whole number of degrees by a decimal point (the period character, "."). Decimal fractions of a degree should be expressed to the precision available, with trailing zeroes being used as placeholders if required. A decimal point is optional where the precision is less than one degree. Some effort should be made to preserve the apparent precision when converting from another datum or representation, for example 41 degrees 13 minutes should be represented as 41.22 and not 41.21666, while 41 13' 11" may be represented as 41.2197.

Latitudes north of the equator MAY be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the designating degrees. Latitudes south of the Equator MUST be designated by a minus sign (-) preceding the digits designating degrees. Latitudes on the Equator MUST be designated by a latitude value of 0.

Longitudes east of the prime meridian shall be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the designating degrees. Longitudes west of the prime meridian MUST be designated by a minus sign (-) preceding the digits designating degrees. Longitudes on the prime meridian MUST be designated by a longitude value of 0. A point on the 180th meridian shall be taken as 180 degrees West, and shall include a minus sign.

Sorry, but ambiguity leads to non-interoperability that can lead to increased threat, damage, or loss of life!

5. For Circle, why a radius expressed only in kilometers?? And there is no statement as to the precision for kilometers. Is the nearest Kilometer enough or should accuracy be properly expressed - like down to meters. We need some informational guidance here.

6. For polygon, the document states, "an ordered set of vertices". This is ambigous. Is the ordered set clockwise or counterclockwise? For example, the following definition for a polygon is from the ESRI Shapefile technical manual - and is entirely consistent with ISO 19107 - Geometry.

A polygon consists of one or more rings. A ring is a connected sequence of four or more points that form a closed, non-self-intersecting loop. A polygon may contain multiple outer rings. The order of vertices or orientation for a ring indicates which side of the ring is the interior of the polygon. The neighborhood to the right of an observer walking along the ring in vertex order is the neighborhood inside the polygon. Vertices of rings defining holes in polygons are in a counterclockwise direction. Vertices for a single, ringed polygon are, therefore, always in clockwise order. The rings of a polygon are referred to as its parts.

The ESRI definition is (English wise) much easier to understand than the ISO "A GM_Polygon (Figure 21) is a surface patch that is defined by a set of boundary curves and an underlying surface to which these curves adhere. The default is that the curves are coplanar and the polygon uses planar interpolation in its interior."

:-)

Some might say that the above informational guidance should be in an implementors guide. However, in terms of compliance, international standards best practice, lack of ambiguity, and so forth such guidance MUST be included in the actual standard and not in non-normative supporting documentation.

Carl

From CAP 1.1:

3.3.1. WGS-84 Note

Geographic locations in CAP are defined using WGS 84 (World Geodetic System 1984), equivalent to EPSG (European Petroleum Survey Group) code 4326 (2 dimensions). CAP does not assign responsibilities for coordinate transformations from and to other Spatial Reference Systems.

emergency message