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.

 

Carl Reed, PhD
CTO and Executive Director Specification 
Program
OGC

 

The OGC: Helping the World to Communicate Geographically

 

---------------------

 

This communication, including attachments, is for the exclusive use of 
addressee and may contain proprietary, confidential or privileged information. 
If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited. If you are not the 
intended recipient, please notify the sender  immediately by return email 
and delete this communication and destroy all copies.

 

"The important thing is not to stop questioning." -- Albert Einstein