[emergency] RE: Some comments/thoughts on EDXL) DistributionElement, v. 1.0

[Rex Brooks <rexb@starbourne.com>]

Thanks Carl,

Never too late to get straight, even if topolographically there are 
nothing but curves. (Intentional misspelling ;-) )

Ciao,
Rex

At 3:04 PM -0700 1/16/06, Carl Reed OGC Account wrote:
>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


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309